HTTP-директива Cache-Control stale-while-revalidate позволяет браузерам немедленно отдавать кэшированный контент, одновременно асинхронно перепроверяя его в фоновом режиме. Эта функция является основным методом повышения производительности сайта за счет сокращения времени, которое пользователи тратят на ожидание загрузки свежего контента с сервера. Установив этот заголовок, вы поручаете браузеру отображать существующую, кэшированную версию страницы или ресурса, если она все еще находится в пределах окна устаревания, в то время как браузер одновременно проверяет на сервере наличие более новой версии.
Почему вам стоит использовать stale-while-revalidate?
Производительность веб-сайта во многом зависит от минимизации задержек для повторных посетителей. В типичной учетной записи пользователь может посещать целевую страницу несколько раз в день. Если ваши заголовки кэша слишком строгие, браузер постоянно запрашивает у сервера подтверждение, что замедляет работу. Использование stale-while-revalidate эффективно балансирует потребность в свежих данных со скоростью локального кэширования. Это обеспечивает быстродействие пользовательского интерфейса за счет отсутствия необходимости ждать ответа сети во время фазы первоначального рендеринга ресурса.
Эта директива особенно полезна для ресурсов, которые не требуют абсолютной точности до миллисекунды. Например, рассмотрите страницу с ценами на продукты или ленту блога, которая обновляется несколько раз в день. Используя эту директиву, вы позволяете браузеру немедленно показать кэшированный контент. Если этот контент старше вашего указанного max-age, но находится в пределах окна stale-while-revalidate, браузер получает обновление в фоновом режиме. Пользователь видит страницу мгновенно, а при следующем посещении видит новые данные.
Каков синтаксис директивы?
Директива реализуется через HTTP-заголовок Cache-Control. Вы задаете max-age, чтобы сообщить браузеру, как долго контент считается свежим, а затем добавляете параметр stale-while-revalidate. Например, типичная конфигурация выглядит следующим образом: Cache-Control: max-age=60, stale-while-revalidate=3600. Эта конфигурация говорит браузеру, что ресурс свежий в течение 60 секунд. Если запрос происходит через 60 секунд, но до 3600 секунд, браузер отдает устаревший контент и инициирует фоновую загрузку.
- max-age: Устанавливает продолжительность времени, в течение которого контент считается свежим.
- stale-while-revalidate: Устанавливает временное окно после истечения max-age, в течение которого браузер может использовать устаревший контент при получении обновления.
- Приватный или Публичный: Эти заголовки можно комбинировать с директивами private или public для управления тем, где хранится контент, например, в кэше браузера или в общем кэше CDN.
Как настроить сервер для этого заголовка
Чтобы внедрить это на своем сервере, вам нужно изменить заголовки ответа, отправляемые клиенту. Если вы используете Nginx, вы отрегулируете файл конфигурации в блоке location для ваших статических ресурсов или эндпоинтов API. Пример строки будет выглядеть так: add_header Cache-Control ‘public, max-age=86400, stale-while-revalidate=86400’;. Этот подход гарантирует, что ваш сервер четко передает стратегию кэширования каждому браузеру, запрашивающему ваши ресурсы, что приводит к более стабильному взаимодействию для ваших конечных пользователей.
Для разработчиков, использующих Apache, вы можете использовать модуль mod_headers для достижения того же результата. Вы добавите в файл .htaccess строку вроде: Header set Cache-Control ‘max-age=604800, stale-while-revalidate=86400’. После развертывания этих изменений рекомендуется проверить заголовки ответа в инструментах разработчика браузера. Откройте вкладку Network, обновите страницу и выберите ресурс, чтобы убедиться, что значение Cache-Control соответствует предполагаемой конфигурации.
Сравнение стратегий кэширования
| Стратегия | Мгновенная скорость | Свежесть |
|---|---|---|
| Стандартный кэш | Высокая | Низкая |
| No-Cache | Низкая | Высокая |
| Stale-While-Revalidate | Высокая | Высокая |
Как Alien Road применяет stale-while-revalidate
В Alien Road мы часто анализируем показатели производительности клиентов при создании или оптимизации веб-интерфейсов. В типичном проекте мы сначала изучаем текущее время отклика сервера и характер предоставляемого контента. Если мы определяем, что сайт зависит от статических ресурсов или часто используемых данных, которые медленно меняются, мы рекомендуем внедрить эту директиву. Мы гарантируем, что внедрение не противоречит требованиям безопасности, особенно для страниц, содержащих конфиденциальные пользовательские данные.
Наш процесс включает в себя проверку существующих конфигураций заголовков и тестирование времени загрузки в разных браузерах. Затем мы настраиваем интервалы max-age и stale-while-revalidate в зависимости от конкретной частоты обновления контента. Например, новостному сайту могут потребоваться более короткие интервалы, в то время как страница портфолио компании может выиграть от более длинных. Мы документируем эти настройки, чтобы команда клиента понимала, почему определенные ресурсы выглядят кэшированными и как фоновые обновления влияют на общий пользовательский опыт.
Какие ресурсы лучше всего подходят для этого подхода?
Не каждый ресурс на вашем веб-сайте подходит для stale-while-revalidate. Вам следует расставить приоритеты для ресурсов, которые не критичны для немедленной безопасности, или тех, где допустима небольшая задержка обновления контента. Изображения, файлы CSS, бандлы JavaScript и полустатические ответы API являются идеальными кандидатами. Используя эту директиву для этих файлов, вы снижаете нагрузку на ваш исходный сервер и гарантируете, что посетители получат максимально возможное время рендеринга.
- Файлы CSS и JavaScript: Они редко меняются настолько кардинально, чтобы требовать мгновенных обновлений.
- Изображения продуктов: Их хранение с длинным окном перепроверки значительно экономит полосу пропускания.
- Ленты данных JSON: Неконфиденциальные данные, которые периодически обновляются, хорошо работают с фоновой перепроверкой.
Распространенные ошибки, которых следует избегать
Частая ошибка — установка слишком длинного окна перепроверки для контента, требующего высокой точности. Если пользователь ожидает увидеть биржевую цену в реальном времени или критическое оповещение, предоставление устаревшего контента может быть контрпродуктивным. Всегда оценивайте бизнес-влияние предоставления информации, которой уже несколько минут или часов. Кроме того, избегайте применения этого к токенам аутентификации или токенам CSRF, так как они всегда должны быть свежими для предотвращения уязвимостей безопасности при отправке форм или действиях с аккаунтом.
С чего начать на этой неделе
Начните с определения пяти наиболее часто запрашиваемых статических ресурсов на вашем веб-сайте. Используйте инструменты разработчика браузера, чтобы проверить текущий заголовок Cache-Control для каждого из них. Если вы видите max-age без компонента stale-while-revalidate, рассчитайте подходящее окно перепроверки на основе того, как часто меняется этот конкретный файл. Примените изменения к конфигурации вашего сервера сначала в среде staging, чтобы убедиться, что поведение браузера соответствует вашим ожиданиям, прежде чем развертывать на вашем действующем производственном сайте.
Часто задаваемые вопросы
Работает ли это во всех браузерах?
Большинство современных браузеров поддерживают директиву stale-while-revalidate. Поскольку она является частью стандартной спецификации Cache-Control, браузеры, которые не распознают этот параметр, просто проигнорируют его и будут следовать стандартным инструкциям max-age. Это делает ее безопасным прогрессивным улучшением, которое можно добавить к вашей существующей стратегии кэширования, не нарушая работу для старых браузеров, которые могут не поддерживать процесс фоновой перепроверки.
Могу ли я использовать это с CDN?
Да, многие современные сети доставки контента поддерживают stale-while-revalidate. Когда CDN получает этот заголовок от вашего исходного сервера, она может кэшировать контент и самостоятельно обрабатывать процесс фоновой перепроверки. Это очень эффективно для снижения трафика источника. Проверьте документацию вашего провайдера CDN, чтобы подтвердить, поддерживают ли они эту директиву и требуются ли какие-либо специальные шаги конфигурации для ее включения на уровне периметра.
Что произойдет, если фоновое обновление не удастся?
Если запрос на фоновую перепроверку не удается, браузер обычно продолжает использовать устаревшую версию контента, которая уже есть в его кэше. Пользовательский опыт остается непрерывным, так как браузер не показывает посетителю ошибку. В следующий раз, когда пользователь запросит ресурс, браузер может попытаться повторить процесс перепроверки, в зависимости от внутренней логики браузера и состояния кэша.
Лучше ли это, чем валидация ETag?
Эти два метода служат разным целям. Валидация ETag требует кругового рейса на сервер для проверки изменения контента, что все равно создает некоторую задержку. Директива stale-while-revalidate полностью устраняет эту задержку, сразу показывая кэшированный контент. Вы можете использовать их вместе, чтобы гарантировать, что даже при перепроверке кэша браузер загружает полный объем данных только в том случае, если контент действительно изменился, что позволяет сэкономить еще больше полосы пропускания.
Читайте также: Веб-дизайн и разработка · Веб-дизайн