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

Зачем нужно кэширование

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

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

Обновление кэша

Механизм кэширования позволяет значительно сократить количество передаваемых данных и время загрузки сайта. По данным Yahoo, до 80% трафика сайта может быть «срезано» за счет грамотного кэширования. Поэтому кэширование, как относительно простую технологию, внедряют везде: в браузерах, в прокси-серверах провайдеров интернета, на серверах хостинг-провайдеров и т. д. Но есть и обратная сторона.

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

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

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

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

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

Что же делать?

Сброс кэша

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

• Изменение физического имени файла. Например, main.css называется main2015.css. В этом случае файл будет перезапрошен в любом случае: для всех агентов это новый файл. Стоит отметить, что на сервере может быть настроен внутренний редирект: специальная метка в названии файла может игнорироваться, и сервер будет выдавать другой физический файл. Например, при запросе main.v2015.css сервер отправит содержимое файла main.css. Соответственно, изменяя метку в шаблонах сайта можно добиться гарантированного сброса кэша у всех пользователей.
• Изменение GET-строки после имени файла. Например, main.css вызвать как main.css В этом случае, URL веб-ресурса изменится и (почти) все агенты будут вынуждены перезапросить файл. Есть редкие исключения (для прокси-серверов), которые игнорируют GET-строку для статических файлов. Но для веб-сайта малой или средней посещаемости это несущественно.

Практика веб-разработки

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

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

Айри и сброс кэша

Для работы с кэшем сайта в Айри предусмотрено несколько возможностей:

1. Жесткий сброс кэша страниц сайта или всего кэша сайта (включая кэш страниц, кэш высокой доступности и кэш файлов) прямо в Личном кабинете Айри напротив имени сайта.
2. Отключение кэширования статических файлов. Это задается в настройках сайта в Личном кабинете Айри. В этом случае, никакие статические файлы не сохраняются на серверах Айри, а запрашиваются напрямую с хостинга.
3. Использование поддомена для разработки. Специальный поддомен сайта может быть использован для прямого обращения к хостингу, минуя кэширование и защиту Айри. Это позволяет разрабатывать новую версию сайта без необходимости частого сброса кэша.
4. «Волшебная» кнопка Айри. На некоторое время сайт можно отключить от проксирования (оставив только DNS-хостинг доменной зоны). За это в Личном кабинете Айри отвечает иконка Айри напротив имени сайта. Цветное изображение означает проксирование сайта, черно-белое изображение — отключение проксирования.