Форсированный сброс кэша

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

Вообще говоря, для того, чтобы сообщить об обновлении файла в таком случае, нужно изменить его адрес – т. е. заявить обновленный файл под другим URL, что и будет гарантировать его обновление в локальном кэше. Однако это можно сделать двумя способами. Во‑первых, мы можем в конце файла обновить GET‑строку запроса, например, используя номер версии

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 достаточно велик.

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

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

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