В какой момент вы выполняете оптимизацию переднего плана?

Question

Я говорю о таких вещах, как кэширование страниц / таблиц стилей, минимизация JavaScript и т. Д.

Половина из меня считает, что лучше делать эти вещи как можно раньше, еще находясь в разработке, поэтому я могу сознательно осознавать более реалистичные проблемы скорости и реагирования, а также взаимодействовать с чем-то, что больше похоже на то, что будет развернуто в производстве , но другая половина моего мозга думает, что имеет больше смысла ничего не делать до запуска, так что я постоянно работаю с необработанными данными, которые не были оптимизированы в процессе разработки.

Есть ли общепринятая или общепринятая мудрость в этом вопросе?

Answer 1

Я делаю все оптимизации в конце. Таким образом, я знаю, что когда что-то не работает, это потому, что код неправильный. Я пытался оптимизировать вещи слишком рано, и понял, что потратил впустую час, потому что я что-то кэшировал и т. Д.

Answer 2

Поймите, что пользователь тратит большую часть своего времени на ожидание загрузки внешних объектов. Ваше приложение может генерировать html за 0,1 секунды, но пользователь тратит не менее 2 секунд на ожидание загрузки всех изображений и т. Д. Получение этих времен загрузки для небольшого числа положительно увеличит пользовательский опыт.

Уже многое можно сделать, включив GZIP и используя уменьшенные библиотеки javascript. Вам следует скачать и установить YSlow и настроить свой веб-сервер с соответствующими заголовками кэширования. Одно это может сэкономить сотни миллисекунд времени загрузки.

Последний шаг - оптимизировать количество изображений с помощью CSS-спрайтов. Другие шаги могут включать минимизацию css и javascript, но это даст меньше всего методов, которые я уже упоминал.

Подводя итог, можно сказать, что большая часть этого может быть сделана путем правильной настройки вашего веб-сервера, однако спрайты должны выполняться во время разработки.

Answer 3

Преждевременная оптимизация - корень всего зла:)

Особенно на ранних стадиях разработки и даже более того, когда оптимизации будут мешать вашей способности отлаживать код или понимать ход программы.

Тем не менее, важно, по крайней мере, планировать определенные оптимизации на этапе проектирования, чтобы вы не загнали себя в угол, где эти оптимизации уже не легко реализовать (некоторые виды внутреннего кэширования являются хорошим примером) .

Answer 4

Я фанат создания сайта, а затем использую профилировщик пользовательского опыта, такой как YSlow , чтобы выполнить оптимизацию в самом конце.

http://developer.yahoo.com/yslow/

Я должен добавить, что какой-то профилировщик необходим. В противном случае вы оптимизируете данные без данных до / после, что не совсем научно (не говоря уже о том, что вы не сможете количественно оценить, насколько много улучшений вы сделали).

Answer 5

После кодирования в течение нескольких лет у вас есть достаточно четкое представление о том, какими будут шейки производительности.

БД Запросы JS / Jquery функции ХФУ изображений JavaScripts

Заранее выявляя узкие места, в то время как вы создаете / изменяете каждую часть приложения, которая имеет дело с этими узкими местами, вы можете тратить время на настройку, зная, что, затрачивая время на кодирование, вы повышаете производительность в конце. 1005 *

Также делает нас менее ленивыми, всегда создавая оптимальный код и изучая, что это такое в реальной жизни.

Answer 6

Я думаю, что это может быть тот, где трудно получить четкий ответ, поскольку разные проекты будут иметь разные требования, в зависимости от того, сколько работы они выполняют на стороне клиента.

Эмпирическое правило будет, вероятно, позже, а не раньше. Только потому, что многие типичные приемные методы оптимизации (по крайней мере, те вещи, которые мне известны), как правило, довольно легко реализовать. Я имею в виду удаление пробелов и изменение заголовков http и так далее. Поэтому я бы предпочел сосредоточиться на работе, которая напрямую решает проблему, которую решает ваш проект; как только это будет эффективно решено, переходите к вещам, таким как оптимизация времени отклика внешнего интерфейса.

Answer 7

Я согласен с другой половиной вашего мозга, которая говорит: «делай то, что должен, а потом делай это быстрее». Но для всего, что вы делаете, вы должны знать и помнить, как это можно сделать быстрее.

Основная проблема, которую я вижу в этом подходе, заключается в том, что в конце легче игнорировать тот факт, что вам нужно оптимизировать, особенно если все кажется «достаточно хорошим». Другая проблема заключается в том, что если у вас нет опыта в вопросах оптимизации, вы действительно можете «закодировать себя в углу», и в этом случае все становится действительно ужасно.

Answer 8

Я согласен с вашей предпосылкой, что вы должны проводить как можно больше оптимизации на ранних стадиях. Это не только улучшит время разработки (подумайте: экономия 1/2 секунды на обновление добавится, когда вы управляете спамом + r!), Но и сохранит ваш фокус в конце - в то время, когда вы воздействуете код, который вы реализовали - о важных вещах. Сократите все, что вы не будете изменять сразу же.