Кэширование

http://webo.in/a.css?v23

или дату последнего изменения

http://webo.in/a.css?20081010

Оба этих способа изменяют адрес ресурса (в данном случае, это файл стилей), поэтому браузер обязан его запросить.

Во-вторых, мы можем номер версии добавить в сам файл

http://webo.in/a.v23.css

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

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

Таким образом, вместо файла a.v23.css будет отдаваться a.css. Если текущая конфигурация позволяет использовать последний вариант, то стоит остановиться на нем. Иначе сброс кэша придется осуществлять через обновления GET-параметров исходного файла.

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

В каком-то смысле это будет экономия "на спичках", так как эффект будет заметен только при посещении сайта другим пользователем той же локальной сети, к примеру. Но тем не менее эффект есть, и процент запросов с заголовком X-Forwarded-For достаточно велик.

Кэширование в IE: pre-check, post-check

При разработке веб-сайта частота изменения страниц сильно колеблется. Некоторые страницы будут меняться ежедневно, некоторые останутся одними и теми же с самого момента своего создания. Для того чтобы позволить сайту регулировать частоту, с которой браузер должен запрашивать http-сервер об изменениях в ресурсе, в Internet Explorer 5 было введено 2 расширения http-заголовка Cache-Control: pre-check и post-check. К сожалению, другие браузеры не поддержали инициативу, поэтому эти директивы на данный момент действительны только для IE.

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

Спецификация

Расширения post-check и pre-check для Cache-Control определены следующим образом:

• post-check

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

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

Рассматриваем подробнее

Рис. 3.1. Диаграмма работы pre-check и post-check

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

• Если еще не закончился интервал времени post-check, то просто отобразим страницу из кэша.
• Если с момента последнего запроса страницы прошло время, лежащее между интервалами post-check и pre-check, то отобразим страницу из кэша. При этом в фоновом режиме запросим http-сервер на предмет того, изменялась ли страница с момента последнего запроса браузером. Если страница изменялась, то запросим ее и сохраним в кэше. При этом в браузере ничего не поменяется: у него будет более старая версия, полученная изначально из кэша, однако ее загрузка произойдет максимально быстро.
• Если уже истекло время, отмеченное интервалом pre-check, то при запросе страницы пользователем сначала спросим у http-сервера, изменилась ли страница со времени ее последней загрузки браузером. Если страницы изменилась, загрузим ее и отобразим обновленную версию. Если страница не изменилась, то ее кэш и расширения Cache-Control в любом случае будут обновлены.

Заметим, что кнопка "Обновить" (включая клавишу F5) не запускает данный механизм, потому что "Обновить" всегда отправляет на сервер запрос If-Modified-Since. Однако с помощью описанной выше логики будут открываться все ссылки.

Пример использования

В следующем примере сервер уведомляет Internet Explorer, что содержание документа не будет меняться в течение 1 часа ( pre-check=3600 ) и что его можно загружать прямо из локального кэша. В случае же изменения страницы, если пользователь запросит ее по истечении 15 минут, Internet Explorer должен отобразить локальный кэш, но при этом в фоновом режиме проверить, является ли сохраненная копия страницы актуальной, и по необходимости загрузить ее с сервера.

Cache-Control: post-check=900,pre-check=3600

Использование описанных параметров для тонкой настройки общения сервера с IE может оказаться весьма полезным для высоконагруженных проектов, ориентированных на пользователей Internet Explorer. Это позволит как существенно уменьшить число запросов к серверу и сэкономить его ресурсы, так и поддерживать актуальность кэшируемых документов.

Last-Modified и ETag

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

Last-Modified

Дополнительно к заголовку Cache-Control, который предупреждает браузер, что последний может не запрашивать исходный документ с сервера некоторое время, будет полезно проверять версию ресурса каждый раз при запросе. Например, нам нужно, чтобы браузер пользователя проверял файлы стилей не реже, чем раз в день, но при этом сами файлы могут меняться достаточно редко (например, несколько раз в месяц). Для решения такой задачи и была придумана пара заголовков Last-Modified и If-Modified-Since.

Как это работает? Дополнительно к периоду кэширования сервер может также отправить заголовок Last-Modified, который будет обозначать время последнего изменения файла на сервере. Если у браузера есть уже такой файл в локальном кэше, то он может отправить на сервер If-Modified-Since с соответствующим временем. В случае, если файл не менялся со времени последнего посещения, сервер ответит статус-кодом 304 и не будет пересылать содержимое файла.

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

ETag

ETag (англ. Entity Tags — теги сущностей) — механизм, который используют браузеры и веб-серверы, чтобы определить, является ли объект, находящийся в кэше браузера, таким же, как соответствующий объект на сервере. Теги сущностей являются почти полной аналогией Last-Modified заголовка за исключением того, что в качестве тега может быть передана произвольная строка. Сервер указывает ETag для компонента, используя http-заголовок ETag:

http/1.1 200 OK
Last-Modified: Tue, 12 Dec 2008 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 19145