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

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

Но, как выяснилось, это только начало!

Недавно компания Google заявила, что начинает использовать скорость загрузки страницы в своих вычислениях её ранга. Для измерений используется широко известное дополнение к Firebug - YSlow. По их словам, улучшение оценки YSlow может помочь сократить стоимость полосы пропускания (особенно для сайтов с большим трафиком), улучшить отношение пользователей к ресурсу и повлиять на коэффициент конверсии CR.

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

Загрузка по правилу Паретто.

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

В общих чертах можно сказать, что ≤20% загрузки страницы связано с HTML документом, а оставшиеся ≥80% тратятся на загрузку изображений, стилей, скриптов и так далее. Правило 80/20 гласит, что если мы ищем способ улучшить производительность сайта, то лучше взглянуть на то, что составляет 80%, чем пытаться изменить что-то в 20%. Другими словами, нет сомнения, что оптимизация сервера и базы данных очень важна, но проще всего ускорить сайт, если обратить внимание на картинки, скрипты и тому прочее.

Основываясь на принципе 80/20, YSlow проверяет факторы, которые влияют на 80%, и возвращает оценку того, насколько хороша или плоха производительность вашего сайта..

Обычное значение оценки YSlow.

Сайты с низкими характеристиками производительности получают D или хуже. Вот несколько примеров:

Веб-сайт - оценка (YSlow):

• Boing Boing - E (55)
• Dribbble - D (66)
• The New York Times - E (52)
• Daring Fireball - C (74)
• Zeldman.com - D (60)

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

УстановитеFirebug/YSlow, и взгляните на ваш сайт. Как он оценивается? И как мы можем улучшить оценку YSlow нашего сайта? И еще более важный вопрос, что мы можем сделать как разработчики и дизайнеры для того, чтобы быть уверенными, что сайты клиентов имеют отличную производительность?

3 основных концепции:

YSlow содержит 14 правил, а Google Page Speed содержит 26. Все эти правила и техники важны, но для упрощения сконцентрируемся на 3 основных концепциях, применяемых нами при разработке сайтов:

1. Делаем меньше запросов к файлам.
2. Загружаем файлы одновременно.
3. Держим все в кэше настолько долго, насколько это возможно.

Резюме: меньше запросов к файлам - меньше времени загрузки сайта.

Давайте посмотрим, каким образом можно уменьшить количество загружаемых стилей, скриптов и изображений:

Минимизация

Что если вместо написания множества тэгов <script> объединить их в один файл, удалив лишние символы? Суть минимизации в том, что мы можем взять все наши JavaScript или CSS файлы и соединить их в один файл, сохраняя правильный порядок. Сразу уменьшается количество загрузок файлов (что приводит к увеличению оценки YSlow). Но есть еще один положительный фактор: не изменяются оригинальные файлы, просто создается новый, комбинированный файл налету. Таким образом, у разработчика остается возможность вносить изменения в сайт клиента с помощью редактирования индивидуальных файлов, а после этого создается новый комбинированный файл.

Это очень важный аспект концепции: веб-студия должна быть уверена, что сайт, переданный клиенту можно поддерживать при полном ее отсутствии. Когда бы ни писался код, он должен быть легко доступен клиенту или будущим разработчикам для чтения и редактирования.

При использовании нашего программного подхода все оригинальные фалы остаются в действии и могут быть редактированы по отдельности. Такой подход позволяет сохранять высокий уровень поддержки.

CSS-спрайты

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

Обычно, создание и сопровождение спрайта CSS является настоящей головной болью. Но не для нас! Применяемые нами решения сами делают всю тяжелую работу. С помощью одной настройки можно комбинировать изображения и корректировать соответствующие стили CSS.

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

Одновременная загрузка файлов - CSS наверх, JavaScript вниз.

Резюме: загружайте одновременно столько файлов, сколько сможете.

Браузеры по умолчанию могут загружать параллельно несколько файлов (~2 в старых браузерах, ~6 в новых). Однако, пока браузер загружает скрипт, он не будет загружать никакие другие файлы.

Размещая файлы CSS наверху и JavaScript внизу мы даем возможность браузеру загрузить и показать контент пользователю гораздо быстрее, без блокирования.

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

jQuery с сайта Google

Используя библиотеку jQuery рекомендуется ссылаться на Google CDN (content delivery network - сеть распространения контента). Если пользователь уже посещал вэб сайт, который ссылался на библиотеку jQuery в Google CDN, то она уже загружена в кэш пользователя. В этом случае мы экономим 24KB объема страницы. Если библиотеки еще нет в кэше, то используется преимущество CDN: быстрая загрузка с сервера, который географически находится ближе и параллельная загрузка со второго хоста.

Google, кстати, размещает обширный  фреймворк JavaScript в дополнение к jQuery.

Держим все в кэше настолько долго, насколько возможно.

Резюме: Если вы что-нибудь загрузили и оно не изменялось, не нужно загружать это снова.

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

Обычно устанавливается срок хранения для изображений, скриптов и стилей на 30 дней от текущей даты. Так же приводятся указания для Apache удалить ETag, идентификатор, который часто усложняет процесс кэширования. Эти установки можно делать и в конфигурационных файлах Apache, но модифицирование  файла .htaccess обычно проще.

Вот далеко не полный список причин ускорения и методов воздействия на подобные проблемы.
А от себя добавлю - теперь экономия на спичках - это еще и большой минус в поисковой оптимизации. Будьте бдительны и не ведитесь на "недорогие поделки" от дилетантов!

По мотивам материалов с сайта www.weightshift.com