Уменьшение количества запросов

4.1.2. Объединение JavaScript-файлов

Для JavaScript-файлов весь описанный механизм повторяется, за исключением небольших деталей.

Получаем код

Во-первых, получать код мы будем уже немного другим методом, и для нас будет несущественен атрибут media:

$regex =
"!<script[^>]+type\\s*=\\s*(\"text/javascript\"|'text/javascript'
|text/javascript)([^>]*)>(.*?</script>)!is";
preg_match_all($regex, $this->head, $matches, PREG_SET_ORDER);
if (!empty($matches)) {
foreach($matches as $match) {
$file = array();
$file['tag'] = 'script';
$file['source'] = $match[0];
/* вырезаем из найденного куска HTML-кода обрамляющие теги,
чтобы идентифицировать внутренние скрипты */
$file['content'] = preg_replace("/(<script[^>]*>
[\t\s\r\n]*|[\t\s\r\n]*<\/script>)/i", "", $match[0]);
$file['file'] = '';
preg_match_all("@(type|src)\s*=\s*(?:\"([^\"]+)\"|'([^']+)'
|([\s]+))@i", $match[0], $variants, PREG_SET_ORDER);
if(is_array($variants)) {
foreach($variants AS $variant_type) {
$variant_type[1] = strtolower($variant_type[1]);
$variant_type[2] = !isset($variant_type[2]) ?
(!isset($variant_type[3]) ? $variant_type[4] :
$variant_type[3]) : $variant_type[2];
switch ($variant_type[1]) {
case "src":
$file['file'] =
trim($this->strip_querystring($variant_type[2]));
$file['file_raw'] = $variant_type[2];
break;
default:
$file[$variant_type[1]] = $variant_type[2];
break;
}
}
}
$this->initial_files[] = $file;
}
}

Объединяем

Тут нас ждет еще одно отличие: разные куски JavaScript-кода лучше объединять через точку с запятой с переводом строки. Ибо предыдущая часть кода может не оканчиваться на точку с запятой, потому мы обязаны как-то отделить ее от последующей.

Далее в ходе объединения было установлено, что файлы библиотек для визуального форматирования кода (в силу своей сложности) мало приспособлены к объединению с другими файлами. Поэтому рекомендуется при объединении избегать следующих файлов: tinymce.js и fckeditor.js. Во всем остальном механизм абсолютно тот же самый, что и для CSS-файлов (за исключением отсутствия необходимости разрешить @import и необходимости заменять пути для фоновых изображений и ресурсов).

Минимизируем

Для минимизации JavaScript-кода лучше всего использовать уже имеющиеся на рынке решения: JSMin (http://www.crockford.com/ javascript/jsmin.html, который портирован в том числе и на PHP) или YUI Compressor (http://developer.yahoo.com/yui/compressor/). Про последний уже было написано чуть выше (параметры для запуска те же самые). В случае с JSMin все тоже довольно просто: нам нужно загрузить последнюю версию (http://code.google.com/p/jsmin-php/), подключить ее и просто вызвать минимизацию заданного файла:

require 'jsmin-1.1.1.php';
echo JSMin::minify(file_get_contents('example.js'));

Стоит также упомянуть, что классический JSMin не поддерживает условную компиляцию для IE. Поэтому тут нужно воспользоваться модифицированным решением (например, из исходных кодов Web Optimizer).

4.1.3. Заключение

Объединение текстовых файлов способно значительно ускорить загрузку вашего сайта, не причиняя вреда качеству разработки (вы можете разрабатывать отдельно и в автоматическом режиме выкладывать на сайт уже готовые версии файлов). Как показывают данные с webo.in, на произвольном сайте в Рунете используется 2,7 файлов стилей (средний размер — 5,5 Кб) и 5 JavaScript-файлов (средний размер — 15 Кб). Простое их объединение позволит выиграть 0,5-1 с при загрузке страницы. А минимизация (вместе с gzip-сжатием, уменьшающим размер на 85%) — еще 60 Кб, что составит 0,6 с при скорости подключения 100 Кб/с.

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

4.2. Алгоритм разбора и сбора CSS Sprites

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

4.2.1. Обзор технологии

CSS Sprites, на самом деле, — всего лишь расширенное использование технологии background, заложенной еще в спецификации CSS1. Все, до чего додумалось прогрессивное человечество за эти годы, — это множественный фон у элементов (как он будет совместим с концепцией CSS Sprites, еще придется проверить). Основные свойства, которые мы используем для задания фонового изображения:

Кроме заявленных свойств также есть еще несколько (например, background-color), но они к спрайтам имеют посредственное отношение. Однако стоит добавить к нашим объектам, с помощью которых мы будем формировать карты изображений, размеры (в относительных или абсолютных единицах) и отступы (padding). Это позволит точнее разделить изображения по группам и корректно расположить их в финальном комбинированном изображении.

4.2.2. Прикладные тонкости

Естественно, рассматривая набор возможных эффектов при использовании фоновых изображений, стоит отметить следующие:

Все описанные примеры можно более четко структурировать по следующим группам:

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

4.2.3. Практическое решение: CSS Tidy

Далее речь пойдет уже об инструменте Auto Sprites (http://sprites.in/), который был положен в основу разработки Web Optimizer (http://www.web-optimizer.ru/). После описанных выше умозаключений оставались чисто технические вопросы: как все это закодировать и как отладить полученное решение.

Для начала нам нужно разобрать все дерево CSS-правил, потом отобрать из них относящиеся к фоновым изображениям и линейным размерам объектов, а уже потом произвести над ними требуемые действия. Идеально для этой задачи подходит CSS Tidy (http://csstidy.sourceforge.net/), который был замечательно испробован, протестирован и улучшен после интеграции на сотнях реальных сайтов. CSS Tidy представляет собой набор PHP-библиотек, которые могут быть включены в произвольный проект для каких-либо действий над заданным набором стилевых правил.

Ниже приводится простой алгоритм выделения из массива CSS-правил нужных нам свойств фона на языке PHP:

/* $this — объект класса css_sprites */
/* сначала создадим новый объект CSS Tidy, используя заданный
$css_code*/
$this->css = new csstidy();
$this->css->parse($css_code);
/* определим CSS-свойство для элементов без фона, */
/* чтобы не переопределить его в ходе преобразований */
$this->none = 'none!important';
/* далее мы переберем весь массив на предмет сначала
@media-конструкций*/
foreach ($this->css->css as $import => $token) {
/* создадим для каждого заданного @media свой массив правил */
$this->media[$import] = array();
/* а затем и самих CSS-селекторов */
foreach ($token as $tags => $rule) {
/* получим для каждого набора селекторов массив CSS-свойств и их
значений */
foreach ($rule as $key => $value) {
/* выделим из всех свойств только относящиеся к фону */
if (preg_match("/background/", $key)) {
/* переопределим "выключенный" фон, чтобы не затронуть */
/* в ходе преобразований */
if ($key == 'background'  $value == 'none') {
$this->css->css[$import][$tags]['background'] =
$this->none;
}
/* теперь для каждого отдельного CSS-селектора */
foreach (split(",", $tags) as $tag) {
/* создаем отдельный объект */
if (!empty($this->media[$import][$tag])) {
$this->media[$import][$tag] = array();
}
if ($key == 'background') {
/* получаем массив фоновых свойств из CSS-свойства background */
$background = $this->css->optimise-
>dissolve_short_bg($value);
foreach ($background as $bg => $property) {
/* пропускаем свойства, заданные по умолчанию */
if (
/* в частности, для background-position */
!($bg == 'background-position' 
($property == '0 0 !important' ||
$property == 'top left !important' ||
$property == '0 0' ||
$property == 'top left')) 
/* для background-origin */
!($bg == 'background-origin' 
($property == 'padding !important' |
$property == 'padding')) 
/* для background-color */
!($bg == 'background-color' 
($property == 'transparent !important' ||
$property == 'transparent')) 
/* для background-clip */
!($bg == 'background-clip' 
($property == 'border !important' ||
$property == 'border')) 
/* для background-attachement */
!($bg == 'background-attachment' 
($property == 'scroll !important' ||
$property =='scroll')) 
/* для background-size */
!($bg == 'background-size' 
($property == 'auto !important' ||
$property == 'auto')) 
/* и для background-repeat */
!($bg == 'background-repeat' 
($property == 'repeat !important' ||
$property == 'repeat'))) {
/* Переопределяем background-image, если оно не задано */
if ($bg == 'background-image' 
($property == 'none !important' ||
$property == 'none')) {
$property = $this->none;
}
/* и дополняем background-position, вместо left выставляем
left center, вместо right — right center,
и ряд других исправлений */
if ($bg == 'background-position') {
$property =
$this->compute_background_position
($property);
}
/* В конце выставляем полученные значения для массива правил,
определяющих исходные фоновые картинки */
$this->media[$import][$tag][$bg] = $property;
}
}
/* Если у нас задано детальное CSS-свойство, то просто его на-
значаем */
} else {
/* Дополняем background-position, вместо left выставляем left
center,
а вместо right — right center,
также меняем местами bottom right и некоторые другие случаи */
if ($key == 'background-position') {
$value =
$this->compute_background_position($value);
}
/* и выставляем "исправленные" свойства для массива CSS-правил,
пропуская свойства по умолчанию */
if ($key != 'background-position' || $value != '0 0') {
$this->media[$import][$tag][$key] = $value;
}
}
}
}
/* завершаем цикл перебора исходных CSS-правил */
}
}
}

4.2.4. Практическое решение: сборка изображений

Дальше начинается самое интересное: как нам вышеописанные группы "склеивать"? Для этого используется следующий алгоритм:

При расчете позиции картинки в конечном спрайте может помочь следующая схема:

В силу громоздкости решения (в нем более 1500 строк кода) в полном объеме в данной книге оно не приводится, однако все описанные шаги уже применены в Web Optimizer (http://www.web-optimizer.ru/) (веб-приложении для автоматизации клиентской оптимизации). Одна из финальных версий алгоритма работает для инструмента Auto Sprites (http://sprites.in/), а с исходным текстом можно ознакомиться в SVN (http://code.googLe.eom/p/ web-optimizator/source/browse/trunk/Libs/ php/css.sprites.php).

Эту логику можно применить на любом этапе веб-разработки (как при начальном создании дизайна, так и при пострелизной оптимизации сайта). Библиотека для автоматического создания спрайтов распространяется по лицензии MIT (она позволяет использовать продукт где угодно и как угодно, но обязательно должна присутствовать ссылка на первоисточник, даже если используется не вся библиотека, а только ее существенная часть).

4.3. CSS Sprites и data:URI, или Microsoft и весь остальной мир

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

Если говорить об ускорении этой стадии, то здесь одной из основных технологий будет именно технология CSS Sprites, которая уже отлично себя зарекомендовала в этом качестве. Однако у нее вместе с очевидными плюсами (значительное уменьшение запросов к серверу, кроссбраузер-ность) есть и несколько минусов. В частности:

4.3.1. data:URI

Есть ли выход из этого положения? Да, есть. Это технология data:URI, которая позволяет включать фоновые изображения прямо в CSS-файл в base64-виде. Плюсы данного подхода очевидны: не нужно "склеивать" несколько картинок в один файл, есть возможность объединять различные оси и анимированные с обычными изображениями, полностью отделить содержание (семантику документа) от его представления (оформления и дизайна), и т. д.

Но есть и ложка дегтя: IE вплоть до версии 7 не поддерживает data:URI. IE8 — уже да, но все остальные IE — нет. Что делать?

4.3.2. mhtml

Нам на помощь приходит технология mhtml (MIME HTML), которую поддерживает по умолчанию только IE (почти в полной мере) и Opera (начиная с версии 9.0). Она позволяет включать base64-данные в CSS-файл в виде комментариев. В этом случае сам файл выступает в двух ипостасях: как таблица стилей и как хранилище фоновых картинок.

Если мы объединим эту технологию с data:URI, то все будет хорошо. Правда?

4.3.3. Проблема 1: долгая предзагрузка

В случае включения фоновых картинок прямо в CSS-файл последний заметно увеличивается в размере (даже при использовании gzip-сжатия). Это значительно увеличивает время предзагрузки (если фоновых картинок больше 10—15 Кб), и пользователь дольше видит белый экран. Опять все плохо. Как быть?

Возможным выходом из сложившейся ситуации может стать подключение CSS-файла с фоновыми картинками по комбинированному событию window.onload, что вынесет загрузку элементов дизайна в ту область, где она изначально находилась: на стадию полной загрузки страницы или даже в пост-загрузку. В данном случае мы получаем полную аналогию метода CSS Sprites, только без заявленных выше неудобств.

4.3.4. Проблема 2: выключенный JavaScript

Описанный выше прием позволит облегчить загрузку только пользователей с включенным (или поддерживаемым) JavaScript (их порядка 9899%). Однако в ряде проектов это может быть недостаточно. Для оставшихся пользователей мы можем через <noscript> подключить нужный нам файл (и конкретно для них замедлить предзагрузку) или поместить вызов этого файла перед </body> (что в ряде случаев может быть аналогично подключению стилей в <head> ).

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

4.3.5. Проблема 3: Safari и window.onload

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

На данный момент для Safari мы можем безболезненно загружать дополнительные файлы стилей только по полному событию window.onload.

4.3.6. Проблема 4: Microsoft, IE7 и Windows Vista

В результате проведенных исследований удалось установить, что в связи с проблемами безопасности в Vista mhtml-технология для отображения фоновых изображений не поддерживается. В этом случае единственным выходом будет подключение конкретно для этого браузера (через JavaScript) общего файла (с использованием CSS Sprites). Для пользователей IE7@Vista с отключенным JavaScript у нас нет другой альтернативы, чем загружать файл только с CSS Sprites.

Более подробно о создании автоматического решения, позволяющего решить все описанные проблемы, рассказывается в следующем разделе

4.4. Автоматизация кроссбраузерного решения для data:URI

Многим профессиональным веб-разработчикам известны приемы оптимизации сайтов. Одним из способов оптимизации является применение CSS Sprites. Этим же разработчикам известно, какие существуют трудности с формированием, сборкой и пересборкой стандартных спрайтов. При использовании стандартных спрайтов полностью автоматизировать сборку для всех случаев проблематично, из-за специфики свойств background в CSS. Иногда камнем преткновения является свойство repeat фоновой картинки.

4.4.1. Data:URI CSS

Существует альтернативный вариант генерации CSS-спрайтов — на основе схемы data:URI. Данный подход интересен тем, что максимально минимизируется количество обращений к серверу, и самое важное — можно полностью автоматизировать процесс сборки и перегенерации спрайтов. Для полной автоматизации процесса оптимизации работы сайтов и сборки CSS-спрайтов на основе data:URI схемы была разработана специальная библиотека.

Мучения со стандартным подходом применения CSS-спрайтов, а именно, трудности модернизации и, в некоторых случаях, сложности оптимальной компоновки заставили искать альтернативный вариант оптимизации загрузки изображений. Далее речь пойдет об использовании комбинированного метода: data:URI + mhtml. Более детально процесс создания изображений в этом формате описан в пятой главе книги "Разгони свой сайт".

В ходе дискуссий и умозаключений были определены слабые и сильные стороны этого подхода. Одним из значительных его недостатков является сложность сборки конечного CSS. Однако при использовании data:URI существует возможность автоматизации процесса. Соответственно, было принято решение создать программное обеспечение для автоматической сборки data:URI спрайтов.

Новый подход генерации CSS-спрайтов на основе data:URI решили назвать Data URI Sprites — DURIS.ru. Название немного необычное — но зато уникальное и хорошо запоминается.

4.4.2. Что это?

В первую очередь это полностью автоматический анализ и сборка CSS-спрайтов на основе data:URI.

Некоторые характеристики работы DURIS:

4.4.3. Зачем это надо?

Современный подход создания CSS-спрайтов:

4.4.4. IE и другие

В ходе разработки реализации data:URI спрайтов были проанализированы наиболее часто встречающие варианты CSS-правил. Также был учтен всеми любимый браузер IE. Кому еще не известно: IE не поддерживает до версии 8 технологию data:URI. Однако для него существует альтернативный вариант реализации спрайтов — на основе mhtml-технологии. Другими словами, на данный момент мы имеем полный спектр решений для всех современных браузеров (99% процентов всех используемых браузеров). Но, как всегда, "ложку дегтя" подкидывает Microsoft. Во время тестирования найдена ошибка mhtml-технологии в Vista IE7 — а именно, браузер IE7 в ОС Vista при кэшировании mhtml-файла отказывается показывать изображения (это связано с малодокументированными проблемами безопасности при использовании mhtml в Vista IE7). Если сделать файл некэшируемым, то все работает, как и должно работать, но в случае с кэшированием фоновые изображения не отображаются.

В общем, Microsoft все же сделал так, чтобы "цепь разорвалась". На текущий момент для браузера IE7 в ОС Vista реализация DURIS работает не совсем так, как задумывалось изначально. В подключение стилей внедрен алгоритм проверки IE7 Vista и в случае обнаружения такового фоновые картинки подключаются стандартным путем. Статистика показывает, что пользователей, которые используют IE7 под Vista, около 5% процентов. В любом случае, мы уже знаем, что в IE8 нормально реализована data^RI-технология.

4.4.5. Основные достоинства

Выделим два наиболее важных достоинства использования современного подхода генерации CSS-спрайтов.

4.4.6. Что имеем

На сегодняшний день мы имеем стабильную бета-версию DURIS, которая отрабатывает все передаваемые ей CSS-файлы. Отрабатываются также специфические правила, такие как filter:AlphaImageLoader, !important. Ядро DURIS разработано на языке Java и является самодостаточным (т. е. не зависит от сайта). Предполагается, что после получения релиз-кандидата исходный код ядра будет выложен в открытый доступ под OpenSource-лицензией. Ядро работает с командной строки наподобие того, как работает YUI Compressor. Это позволит удобно интегрировать автоматическую генерацию CSS-спрайтов в свои проекты. Кто программирует на Java, при желании сможет напрямую вызывать методы ядра DURIS.

4.4.7. Итого

Разработанный метод/алгоритм автоматической генерации CSS-спрай-тов основе data:URI уникален в своем роде и не имеет мировых аналогов. На сайте выложен FAQ (http://duris.ru/faq/), в котором детально описано, что и как работает. Если что не понятно — задаем вопросы в комментариях.

В роли главного разработчика данного решения выступил Руслан Си-ницкий (aka sirus, http://fullajax/#:developers).

4.4.8. Будущее

При появлении поддержки в IE8 схемы data:URI (стоит все же помнить об ограничении в 32 Кб, http://msdn.microsoft.com/en-us/library/cc848897%28VS.85%29.aspx) разработанный подход становится довольно перспективным, теперь все современные браузеры поддерживают такие спрайты.

Детально ознакомиться с принципами генерации и подключения data:URI CSS-спрайтов можно в разделе FAQ (http://duris.ru/faq/). Если у вас возникли вопросы или предложения по работе сайта или алгоритма в целом, вы можете оставить свои пожелания на этом сайте в форме обратной связи.

Стоит также понимать, что наиболее эффективные методы клиентской оптимизации будут использовать комбинированные решения (как, например, это реализовано в Web Optimizer). Часть фоновых изображений, которые сложно или нерационально "склеивать" в CSS Sprites и которые невелики по размеру, мы можем включить прямо в CSS-файл. Размер его при этом увеличится незначительно.

Большие же изображения (больше 24 Кб) мы не можем включать из принципов кроссбраузерности, они могут формировать CSS Sprites и этим не только уменьшать общее время загрузки, но и формировать наиболее оптимальную визуальную скорость загрузки сайта у конечного пользователя. При этом часть картинок (включенных через комбинированный data:URI) появится сразу же, а часть (включенных через CSS Sprites) — через некоторое время, так как они будут представлены отдельными файлами.

4.5. Автоматизация кэширования

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

4.5.1. Кэширование на клиентском уровне

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

Статические ресурсы без сжатия

Форсирование кэширования для статических ресурсов может выполняться без сжатия. В данном случае мы ничем не рискуем, выставляя не только максимальное время кэширования, но и предлагая кэшировать ресурсы на локальных прокси-серверах (директива Cache-Control: public ). Для PHP у нас получится следующий код (в Expires прописана дата на 10 лет вперед относительно текущего времени на сервере):

<?php
header("Cache-Control: public, max-age=315360000");
header("Expires: Mon, 01 Jul 2019 00:00:00");
?>

В случае выставления директив для Apache:

<FilesMatch \.(bmp|png|gif|jpe?g|ico|swf|flv|pdf|tiff)$>
Header append Cache-Control public
ExpiresActive On
ExpiresDefault "access plus 10 years"
<FilesMatch>

И в случае nginx:

location ?* ^.+\.(bmp|gif|jpg|jpeg|png|swf|tiff|swf|flv)$ {
expires 10y;
header set Cache-Control public;
}

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

Статические ресурсы со сжатием

Все отличие от предыдущего случая заключается в том, что разрешить локальным прокси-серверам кэшировать такие ресурсы (обычно это CSS-, JavaScript- или ICO-файлы) нельзя. Даже больше: нам нужно запретить кэширование сжатых версий файлов, чтобы избежать выдачи сжатого файла тем пользователям, которые сжатия не поддерживают. Код для PHP:

<?php
header("Cache-Control: private, max-age=315360000");
header("Expires: Mon, 01 Jul 2019 00:00:00");
?>

Для Apache:

<FilesMatch \.(css|js|ico)$>
Header append Cache-Control private
ExpiresActive On
ExpiresDefault "access plus 10 years"
</FilesMatch>

И для nginx:

location ~* ^.+\.(css|js|ico)$ {
expires 10y;
header set Cache-Control private;
}

Очевидно, что в некоторых случаях директивы можно объединить с предыдущим случаем.

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

Запрет кэширования динамических ресурсов

Обычно для произвольного сайта (информация на котором часто меняется) кэширование HTML-документов запрещено. Это связано с быстрым устареванием предоставляемой информации (здесь стоит отметить, что правила для отображения и взаимодействия информации — стили и скрипты — устаревают намного медленнее, чем сама информация).

Для того чтобы запретить кэширование во всех браузерах HTML-документов, нужно написать с помощью PHP (в Expires прописано текущее время на сервере):

header("Expires: Wed, 01 July 2009 00:00:00");
header("Cache-Control: no-store, no-cache, must-revalidate,
private");
header("Pragma: no-cache");

Для Apache:

<FilesMatch \.(php|phtml|shtml|html|xml|htm)$>
ExpiresActive Off
Header append Cache-Control "no-store, no-cache,
must-revalidate, private"
Header append Pragma "no-cache"
</FilesMatch>

Для nginx:

location ?* ^.+\.(php|phtml|shtml|html|xml|htm)$ {
expires 0;
header set Cache-Control "no-store, no-cache, must-revalidate,
private";
header set Pragma "no-cache";
}

4.5.2. Условное кэширование

Для динамических ресурсов очень часто оказывается, что обеспечить какой-либо срок кэширования невозможно: содержимое документа постоянно изменяется или полностью зависит от пользовательских действий. Если рассмотреть статические файлы, то и для них бывает весьма полезно настроить проверку изменения ресурса с течением времени. Например, установить срок действия кэша на месяц, а чтобы не увеличивать объем передаваемых данных, через месяц проверять, изменился ли запрашиваемый объект или нет.

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

Существует два способа обеспечить условное кэширование: при помощи заголовков Last-Modified + If-Modified-Since и ETag + If-None-Match. Первый заголовок в паре относится к ответу со стороны сервера, второй — к запросу со стороны клиента, который уже получил соответствующий ответ сервера и теперь желает проверить, изменилось ли что-нибудь с той поры.

При помощи пары Last-Modified мы можем установить соответствие ресурса только по времени его изменения. ETag (англ. Entity Tag, метка сущности) предполагает более широкую сферу применения: мы можем для ресурса назначить уникальную строку, зависящую не только от времени изменения, но и от других параметров (например, передается данный файл в сжатом виде или нет).

Для отдельных серверов (которые не работают как кластер) более уместной будет настройка именно даты изменения файла. Для более сложных систем необходимо настраивать именно ETag-заголовки, чтобы гарантировать уникальность файла среди множества различных машин.

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

/* получаем содержимое документа, например, из закэшированного
файла */
$content = @file_get_contents($file);
/* вычисляем уникальную метку, зависящую от содержания */
$hash = md5($content);
/* проверяем соответствие вычисленной и переданной с клиента
меток */
if ((isset($_SERVER['HTTP_IF_NONE_MATCH']) 
stripslashes($_SERVER['HTTP_IF_NONE_MATCH']) == '"' . $hash .
'"') ||
(isset($_SERVER['HTTP_IF_MATCH']) 
stripslashes($_SERVER['HTTP_IF_MATCH']) == '"' . $hash . '"')) {
/* в случае совпадения меток передаем 304-ответ */
header ("HTTP/1.0 304 Not Modified");
/* и не передаем содержимое документа */
header ("Content-Length: 0");
exit();
}
/* во всех остальных случаях выставляем заголовок ETag */
header("ETag: \"" . $hash . "\"");
/* и отдаем полностью содержимое документа */
echo $content;

4.5.3. Сброс кэша

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

Строка запроса

На самом деле эта проблема обходится достаточно просто, и в книге "Разгони свой сайт" уже было приведено несколько способов обеспечения этого механизма. Наиболее простой путь заключается в том, что мы можем добавлять специальный GET-параметр (или просто строку запроса) к нашему ресурсу. При этом его URL меняется для браузера (но для сервера остается тем же самым), что фактически решает поставленную задачу.

Рассмотрим следующий вызов CSS-файла:

<link rel="stylesheet" href="/css/main.css?20090701" type="text/css"/>

В строке запроса (части адреса, идущей после ?) мы видим метку времени (20090701). Не обязательно вводить здесь именно время, это может быть также и номер ревизии из системы хранения версий, и любая другая метка, которая бы однозначно могла указывать на изменение файла: разные метки должны соответствовать разным файлам.

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

<?php
/* получаем метку времени, равную времени изменения файла */
$timestamp = filemtime($file);
/* выводим ссылку на файл в HTML-документе */
echo '<link rel="stylesheet" href="/css/main.css?". $timestamp .
"' type="text/css"/>';
?>

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

Физическое имя файла

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

RewriteRule ~(.*)(\.v[0-9]+)?\.(css|js)$ $1.$2 [QSA,L]

Какой оно несет смысл? А тот, что при указании в HTML-документе ссылки на файл

main.layout.v123456.css

сервер отдаст физический файл

main.layout.css

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

<?php
/* получаем метку времени, равную времени изменения файла */
$timestamp = filemtime($file);
/* выводим ссылку на файл в HTML-документе */
echo '<link rel="stylesheet" href="/css/main.css.v". $timestamp .
"' type="text/css"/>';
?>

Однако, как и в предыдущем случае, мы все равно обращаемся к файловой системе.

Создание хэша

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

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

$hash = '';
foreach ($this->initial_files as $file) {
$hash .= $file['file_raw'];
}
$new_file_name = md5($hash);

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

Использование разделенной памяти

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

<?php
/* удаляем (ставим время истечения равным 1 с) из APC запись
относительно */
/* текущего файла, при изменении каких-либо включенных в него
файлов */
if ($changed) {
apc_store($new_file_name, apc_fetch($new_file_name), 1);
}
…
/* при выдаче закэшированного файла проверяем, нужно ли
его пересобирать */
$mtime = apc_fetch($new_file_name);
if (!$mtime) {
…
/* если нужно, то при создании файла записываем текущее время
в APC */
$mtime = $_SERVER['REQUEST_TIME'];
echo '<link rel="stylesheet" href="/css/main.css?". $mtime .
"' type="text/css"/>';
apc_store($new_file_name, $mtime);
} else {
/* если нет, то у нас уже получено время изменения файла,
которое можно использовать для метки кэша */
echo '<link rel="stylesheet" href="/css/main.css?". $mtime .
"' type="text/css"/>';
}
?>

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

Таким образом, кэширование на клиентском уровне может ускорить загрузку последующих страниц (или посещений) вашего сайта на 500-1000% (в 5-10 раз), а правильное управление кэшированием гарантирует вам, что информация,получаемая пользователями, всегда будет актуальной.

4.5.4. Кэширование на серверном уровне

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

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

На виртуальных хостингах (когда ресурсы одного сервера могут делить десятки или сотни различных сайтов) для относительно простого сайта (который не предполагает значительного взаимодействия с пользователем) стоит рассмотреть возможность создания кэша готовых HTML-страниц. Что это такое?

Отдаем закэшированный документ

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

Для более детального примера давайте рассмотрим следующий код, отвечающий за простейшее серверное кэширование, из Web Optimizer:

/* проверяем, можем ли отдать закэшированный документ */
if (!empty($this->cache_me)) {
/* переводим адрес документа в реальное имя файла */
$this->uri = $this->convert_request_uri();
$file = $this->options['page']['cachedir'] . '/' . $this->uri;
/* проверяем, существует ли файл и достаточно ли он актуальный */
if (is_file($file) 
$_SERVER['REQUEST_TIME'] - filemtime($file) <
$this->options['page']['cache_timeout']) {
$content = @file_get_contents($file);
/* проверяем, сжат ли файл */
if (!empty($this->options['page']['gzip']) 
substr($content, 0, 8) ==
"\x1f\x8b\x08\x00\x00\x00\x00\x00") {
/* если сжат, то выставляем соответствующие заголовки */
$this->set_gzip_header();
}
/* отдает закэшированное содержимое */
echo $content;
/* и закрываем PHP-процес */
die();
}
}

Переменная $cache_me может формироваться на основе множества параметров (в том числе части URL, которые нужно или не нужно кэширо-вать, пользовательские агенты и роботы, для которых можно отдавать кэ-шированные версии страниц, и т. д.). Стоит также отметить, что просто создать файл с именем, равным текущему URL страницы, невозможно: в нем встречаются недопустимые символы (/, ?), которые нужно трансформировать при сохранении на файловой системе.

Создаем закэшированный документ

Но мы рассмотрели процесс выдачи закэшированного документа, а каким образом он появляется на жестком диске? Процедура сохранения файла немного проще и может быть записана следующим образом (код из Web Optimizer):

/* определяем, нужно ли нам сохранять закэшированную версию
документа */
if (!empty($this->cache_me)) {
/* формируем имя файла */
$file = $options['cachedir'] . '/' . $this->uri;
/* проверяем, есть ли такой файл и не устарел ли он */
if (!is_file($file) ||
$_SERVER['REQUEST_TIME'] - filemtime($file) >
$options['cache_timeout']) {
/* записываем новое содержимое в файл */
$fp = @fopen($file, "a");
if ($fp) {
/* блокируем файл от конкурентных попыток записи */
@flock($fp, LOCK_EX);
/* удаляем содержимое и перемещаемся на начало файла */
@ftruncate($fp, 0);
@fseek($fp, 0);
@fwrite($fp, $this->content);
@fclose($fp);
}
}
}

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

4.5.5. Кэширование XHR-запросов

Данный раздел написан после прочтения заметки Steve Souders "F5 and XHR deep dive", посвященной вопросам кэширования XHR-ресурсов.

Оказывается, что любые данные, полученные при помощи AJAX, никогда не будут обновлены в IE прежде истечения срока действия кэша, даже если вы форсируете обновление ( Ctrl+F5 ). Единственный путь обновить эти данные — это вручную удалить их из кэша.

Если вы нажимаете Перезагрузку (F5), IE перезапросит все ресурсы (даже с неистекшим сроком действия кэша), за исключением XHR. Это может вызвать большое недоумение среди разработчиков при тестировании, но меня заинтересовало, какие еще проблемы существуют в этом направлении. Будет ли поведение аналогичным во всех остальных основных браузерах? Что произойдет, если срок давности кэша будет в прошлом или заголовок Expires вообще не будет выставлен? Будет ли какой-либо эффект от добавления Cache-Control max-age (который переписывает заголовок Expires)?

Проводим тестирование

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

Ниже в таблице приведены результаты тестирования этой страницы в основных браузерах. Также там записано, перезапрашивался ли XHR-ре-сурс или был прочитан из кэша, а если перезапрашивался, то с каким кодом HTTP-статуса.

Ниже приведены соображения на тему того, что происходит при нажатии F5.

Выводы

Ниже резюмированы рекомендации для веб-разработчиков при работе с XHR-ресурсами.