Руководство по HTTP-кэшированию Распространенные ошибки в...

Руководство по HTTP-кэшированию

Распространенные ошибки в конфигурации и подводные камни

— `no-cache` vs. `no-store`:

— `no-cache`: Сохраняет ответ, но требует повторной проверки (revalidation) у исходного сервера перед повторным использованием.

— `no-store`: Радикальный вариант. Запрещает любому кэшу (браузерному, CDN) сохранять ответ. Важно отметить, что использование no-store для HTML-документа делает его недоступным для кэша навигации вперед/назад (BFCache).

— `s-maxage` vs. `max-age`:

— `max-age`: Применяется ко всем кэшам (браузерным и общим).

— `s-maxage`: Применяется только к общим кэшам (например, CDN) и для них переопределяет max-age. Это позволяет установить короткий TTL для браузера и длинный TTL для CDN.

— Заголовок `Vary`:

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

— Опасно: Использование Vary: User-Agent или Vary: Cookie фрагментирует кэш на бесчисленное множество вариантов, что катастрофически снижает процент попаданий в кэш (hit rates).

Основные сценарии кэширования

— Статические ресурсы с фингерпринтингом (JS, CSS):

Cache-Control: public, max-age=31536000, immutable

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

— HTML-документы (например, блоги, статьи):

Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=300, stale-if-error=3600

ETag: "[unique-identifier]"

Короткий TTL для браузера, длинный TTL для CDN (требует очистки кэша по событию из вашей CMS при обновлении). Директивы stale-* улучшают пользовательский опыт (UX) и отказоустойчивость.

— Персонализированные страницы / страницы для залогиненных пользователей:

Cache-Control: private, no-cache

ETag: "[unique-identifier]"

Разрешает хранение в браузере, но требует повторной проверки при каждом переходе. Директива private предотвращает совместное использование в CDN.

— API:

Cache-Control: public, s-maxage=30, stale-while-revalidate=30, stale-if-error=300

Короткое значение s-maxage переносит нагрузку на CDN, а stale-while-revalidate поддерживает низкую задержку во время обновлений.

Реалии работы с CDN и отладка

— Настройки CDN по умолчанию: По умолчанию Cloudflare не кэширует HTML. Эту функцию необходимо включить с помощью Page Rules или Workers.

— Фрагментация кэша: CDN кэшируют на основе полного URL. Параметры отслеживания (?utm_source, ?fbclid) создают отдельные записи в кэше, если они не нормализованы в конфигурации CDN.

— Отладочные заголовки: Проверяйте поведение кэша по заголовкам ответа от CDN, а не только от исходного сервера:

— cf-cache-status (Cloudflare: HIT, MISS, EXPIRED, BYPASS)

— X-Cache (Распространенный заголовок прокси: HIT, MISS)

— Cache-Status (Новый стандарт)

— Age: Время в секундах, которое объект находится в общем кэше.

— DevTools: Ответ 304 Not Modified — это *успешное* срабатывание кэша, указывающее на валидный условный запрос, который сэкономил трафик.

Избегайте тестирования с включенной опцией "Disable cache" или использования "жесткой" перезагрузки (Ctrl+Shift+R), так как это не отражает поведение обычного пользователя.

https://www.jonoalderson.com/performance/http-caching/

@MikeBlazerX

Но самое "мясо" — в @MikeBlazerPRO