Как кэш решает, можно ли использовать ответ

HTTP-кэш хранит представление ресурса вместе с метаданными. Если ответ еще свежий, браузер может использовать его без обращения к origin. Истекший ответ обычно требует валидации или новой загрузки; конкретный результат зависит от Cache-Control, Expires, ETag и Last-Modified.

Сначала проверьте.

Cache-Control: max-age=... задает срок свежести в секундах. Директивы вроде no-cache обычно требуют валидации перед повторным использованием, а no-store запрещает сохранять ответ в кэше. Эти значения управляют поведением HTTP-кэша, но не очищают историю посещений и не приказывают пользователю перезагрузить вкладку.

Как найти причину старой версии

В DevTools включите Network и посмотрите status, Size, Age и cache headers. Сравните URL и версию файла, затем проверьте CDN или reverse proxy: несколько кэшей могут стоять по пути к origin. Если HTML меняется чаще, чем CSS или изображение, настройте разные сроки и используйте версионирование имен файлов.

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

Браузер обычно использует private cache, привязанный к профилю пользователя; shared cache работает на общем proxy/CDN и требует других правил хранения. Не разрешайте shared-кэшу сохранять персональный ответ, если содержание зависит от учетной записи. Учитывайте также Vary, который влияет на выбор варианта ответа.

При условной проверке браузер может отправить ETag и получить ответ 304 без повторной передачи тела. Это экономит трафик, если валидатор соответствует текущей версии ресурса.

Кэш не равен резервной копии

Кэш ускоряет повторную доставку и может быть удален или вытеснен браузером. Он не заменяет хранилище исходных файлов. Для деталей протокола смотрите HTTP/1.1, HTTP/2, TLS и CDN. Использованы RFC 9111 и документация MDN, проверенные 8 октября 2026 года; настройки браузера посетителей не менялись.