| Россия, Сочи, РГПУ им. А.И.Герцена, 1997 |
Инспектор
Вы можете этот курс.
Опубликован: 16.02.2009 | Уровень: специалист | Доступ: платный
Лекция 4:
Уменьшение числа запросов
Аннотация: Уменьшение числа запросов - одна из основных целей клиентской оптимизации. В этой лекции рассказано о механизмах объединения HTML и CSS файлов, а также JavaScript файлов. Кроме того, здесь приводится краткий обзор таких техник, как CSS Sprites и data:URI, а также методов экстремальной оптимизации.
Ключевые слова: ПО, cookie, домен, net, файл, css, дизайн, объединение, HTML, фрейм, браузер, контент, логотип, Размещение, отображение, Internet, head, CMS, группа, экранирование, производительность, сервер, операции, AJAX, DOM, сборка, элементы управления, дерево, пользователь, затраты, загрузка, выход, ядро, список, функция, compressor, архив, сайт, PHP, скрипт, кэширование, image map, графическая карта, ссылка, цвет фона, пункт, минимум, границы блока, размер файла, пространство, текстовые файлы, RFC, URI, синтаксис, base64, представление, распознавание, заголовки, URL, альтернатива, Data, оптимизация, предел, кодирование, позиционирование, параметр, идентификатор, w3c, super, приложение, WAV, очередь, место, координаты, меню, спрайт, контейнер, тег, поток, массив, BODY, script, динамическая, ресурс, компонент, процент, исключение, главная страница, сеанс
Объединение HTML- и CSS-файлов
Число запросов является наиболее узким местом при загрузке страницы. По последним исследованиям, порядка 40% времени загрузки уходит только на установление новых соединений с сервером. В этом свете любые методы, позволяющие уменьшить число запросов, выглядят весьма перспективно. Однако каждый такой метод, начиная с простого объединения стилей или скриптов и заканчивая data:URI , достаточно сложен в технологическом плане, поэтому в ряде случаев может просто не окупать затраченного времени.
Зачастую cookie выставляются на весь домен или даже на все поддомены, что означает их отправку браузером даже при запросе каждой картинки с вашего домена. В результате 400-байтный ответ с картинкой превратится в 1000 байтов или даже больше, в зависимости от добавленных заголовков cookie. Если на странице у вас много некэшируемых объектов и большие cookie на домен, то стоит рассмотреть возможность вынесения статичных ресурсов на другой домен (например, так поступил Яндекс, расположив статические файлы на домене yandex.net) и убедиться, что cookie там никогда не появятся.
В силу накладных расходов на передачу каждого объекта один большой файл загрузится быстрее, чем два более мелких, каждый в два раза меньше первого. Стоит потратить время на то, чтобы привести все вызываемые JavaScript-файлы к одному или двум, равно как и CSS-файлы. Если на вашем сайте их используется больше, попробуйте сделать специальные скрипты для публикации файлов на "боевом" сервере или уменьшите их количество. Если на странице в большом объеме располагаются десятки небольших GIF-файлов (для оформления границ или фона элементов), стоит рассмотреть ее преобразование в более простой CSS-дизайн (который не потребует такого большого числа картинок) и(Или) объединение в несколько больших ресурсных файлов.
Для объединения HTML-файлов существует достаточно простое правило по сведению числа фреймов на странице к минимуму (в идеале их вообще не должно быть, ибо каждый фрейм влечет создание нового документа в дереве страницы, что достаточно ресурсоемко). Поэтому давайте рассмотрим, что можно сделать с файлами стилей.
CSS-файлы в начале страницы
При заботе о производительности веб-страниц мы всегда хотим, чтобы страницы могли быть отрисованы постепенно, чтобы браузер мог отобразить любой контент сразу же, как он у него появится. Это особенно важно для страниц, на которых много текстового содержания, и для пользователей с медленным подключением. Важность визуального оповещения пользователя о текущем состоянии загрузки страницы каким-нибудь индикатором прогресса детально изучена и задокументирована. Однако в любом случае всегда лучше, если в роли индикатора прогресса выступает сама страница. Когда браузер загружает HTML-файл постепенно — сначала заголовок, потом навигацию, логотип наверху и т. д. — все это служит отличным индикатором загрузки для пользователя. Также это улучшает общее впечатление от сайта.
Размещение CSS в конце страницы не позволяет начать постепенное отображение многим браузерам, в числе которых находится и Internet Explorer. Браузер не начинает визуализировать страницу, чтобы не пришлось перерисовывать элементы, у которых во время загрузки изменится стиль. Firefox начинает сразу отрисовывать страницу, в процессе загрузки, возможно, перерисовывая некоторые элементы по мере изменения их свойств, но это является причиной появления нестилизованного контента и рекурсивного его обновления.
Спецификация HTML 4 устанавливает, что таблицы стилей должны быть включены в head документа: "В отличие от <a >, <link > может появляться только в секции <head >, зато там он может встречаться сколько угодно раз". Ни одна из альтернатив — белый экран или показ нестилизованного контента — не стоит этого риска (хотя разработчики Firefox и Opera думают несколько иначе). Оптимальным решением является следование спецификации и включение CSS в head -секцию документа.
При проектировании небольших сайтов либо несложных дизайнов это правило является основным для максимизации производительности. Однако далее в этой главе мы рассмотрим и альтернативную его трактовку.
Объединение CSS-файлов
Зачастую на странице подключается несколько файлов стилей: это может быть связано как с модульной структурой построения CSS, так и с поддержкой различных устройств просмотра веб-страниц. Давайте рассмотрим последний случай: у нас есть два вызова CSS-файлов на странице, например:
<link type="text/css" rel="stylesheet" href="screen.css" media="screen" /> <link type="text/css" rel="stylesheet" href="print.css" media="print" />
где первый используется для отображения страницы на экране монитора, а второй — для предварительного просмотра и печати.
Проблема в том, что браузер не отображает любую часть страницы (это не касается Opera: у нее время отображения страницы без полной загрузке файлов стилей задано по умолчанию в настройках, посмотреть их можно следующим образом:
'preferences' (ctrl-f12) -> 'advanced' -> 'browsing' -> 'loading' или 'инструменты' -> 'настройки' -> 'дополнительно' -> 'перемещение' -> 'загрузка'),
пока не загрузит все файлы стилей — в том числе и те из них, которые не предназначены для устройства, с помощью которого производится отображение страницы. Другими словами, браузер не покажет страницу, пока не загрузит и файл стилей для принтера, хотя он совсем и не требуется для визуализации страницы. Это неправильно с точки зрения производительности, но это так (Safari, на самом деле, ведет себя как раз "правильно ": ненужные файлы не задерживают загрузку, но это связано с особенностью модели визуализации; об этом более подробно рассказывается ниже).
Практическое решение
Решение выглядит весьма тривиально: мы можем в общем CSS-файле объявить правила для любого устройства через @media. Например, все стили для принтера могут быть записаны в следующем виде:
@media print {
стилевые правила для принтера
}в конце основного файла стилей. Таким образом, будет загружаться всегда только один файл. Данное решение может быть легко автоматизировано, и некоторые CMS уже применяют этот подход (в частности, Drupal).
Если у нас CSS-файлы разбиты на модули, то нужно пересмотреть их структуру таким образом, чтобы на каждую страницу приходилось не более двух файлов (небольшие файлы — порядка 5 Кб — можно объединить в один для целого раздела). Для главной страницы я рекомендую всегда ограничиться только одним файлом либо вообще включать его в HTML-код (как сделано, например, для главной страницы Яндекса).
Два слова об условных комментариях
Очень часто верстка страниц производится таким образом, что у нас появляется основной файл стилей и несколько дополнительных, рассчитанных на конкретные браузеры (речь идет в основном об Internet Explorer, однако иногда требуются какие-то специальные правила для Firefox, Opera или Safari). В этом случае файлы подключают через так называемые "условные комментарии", которые выглядят как обычные HTML-комментарии для всех браузеров, кроме Internet Explorer (у остальных браузеров есть свои способы загрузить какой-то файл стилей только для них).
Финальная конструкция выглядит примерно следующим образом:
<link type="text/css" rel="stylesheet" href="main.css" media="screen" /> <!-—[if lt IE 7]><link type="text/css" rel="stylesheet" href="ie6.css" media="screen" /><!endif-->
Для всех браузеров используется main.css, а для IE6 и ниже — ie6.css. Однако Internet Explorer этих версий не запрашивает файлы стилей параллельно, поэтому при загрузке страницы произойдет ненужная задержка, связанная с доставкой еще одного файла.
Чтобы избежать ее (особенно в случае небольшого количества стилей конкретно для IE), можно использовать CSS-хаки уже в исходном CSS-файле. Например, если нам нужно определить правило только для IE7, мы можем написать так:
*+html body {
margin: 0 auto;
}
для IE6:
* html body {
margin: 0 auto;
}и для IE5.5- (эта группа браузеров не распознает экранирование символов, поэтому сможет применить только первое правило из двух, второе правило отработает для IE6, переопределив первое):
* html body {
margin: 0;
marg\in: 0 auto;
}CSS-хаки позволяют совершенно свободно использовать всего один файл стилей для гарантии кроссбраузерности верстки. При этом производительность страницы будет максимальной (исключая, конечно, случай включения всех CSS-правил в исходный HTML-документ — это будет работать еще быстрее, однако чревато некоторыми сложностями; подробнее о них в конце этой главы).
Объединение JavaScript-файлов
Все внешние JavaScript-файлы с сайта можно слить в один большой, загружаемый только один раз и навсегда. Это очень удобно: браузер не делает тысячу запросов на сервер для отображения одной страницы, скорость загрузки резко повышается. А пользователи так же счастливы, как и разработчики.
Как всегда, в бочке меда есть ложка дегтя: в объединенный файл попадает много того, что при первом запросе можно было бы и не загружать. Чаще всего для борьбы с этим предлагают ненужные части убирать вручную. Однако каждый раз делать одни и те же операции после изменения модулей очень надоедает. Ниже приведено описание простейшего алгоритма разрешения этой проблемы путем описания зависимостей между модулями.
Конструктивные предложения
Для начала стоит разобрать используемый фреймворк на составные части. JSON— отдельно, AJAX— отдельно, работа с DOM— отдельно, формы— отдельно. После этого задача "выкидывания ненужного" превращается в задачу "собери только нужное". Несомненный плюс— результат сборки стал гораздо меньше. Несомненный минус— если что-то из "нужного " забыто, все перестает работать.
Информацию о зависимостях между составными частями можно хранить в удобном для автоматического использования виде. (Формы используют функции DOM, JSON— AJAX и так далее.) На этом шаге забыть что-то нужное становится заметно труднее, а сборка превращается из увлекательной головоломки в рутинную и автоматизируемую операцию.
Также можно хранить информацию о том, какие именно модули нужны сайту в целом. Используется ли AJAX? Есть ли формы? Может быть, какие-то необычные элементы управления?
Да, естественно, все это можно и нужно автоматизировать.
