HTTP-кеш в измерении повторной загрузки

Одна и та же статья может загружаться по-разному при первом и повторном посещении. Браузер способен использовать сохранённые ответы, проверить их актуальность или получить тело заново. Если состояние HTTP-кеша не записано, изменение результата легко приписать новой версии кода, хотя исходники остались прежними.

В этом уроке исследуем кеш как условие эксперимента speed-lab. Настройка настоящего CDN уже рассматривается в уроке о CDN и кеше, а автономное сохранение — в курсе PWA. Здесь не повторяем эти системы. Локальный сервер подготовлен только для ручного прогона, не запускался автором и не предназначен для хостинга.

Хранение и свежесть ответа

Сохранённый ответ может считаться свежим в пределах заданных правил. Тогда для обычного повторного использования браузеру не обязательно получать тело заново. Когда нужна проверка актуальности, возможен условный запрос с валидатором. Поэтому наличие файла в кеше и отсутствие сетевого обращения — разные утверждения. Сначала исследуем политику и выбранное действие пользователя.

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

Для стабильного ресурса может быть назначен большой срок свежести. Но тогда изменение содержимого по прежнему URL способно оставить читателю старую копию. Решение состоит в договоре версии: неизменный URL означает неизменные данные, а новый ресурс получает новый адрес. Политика доставки и процесс изменения исходников должны соответствовать друг другу.

У speed-lab файлы .v1. считаются учебной версией. Если читатель меняет их содержимое для эксперимента, нужно создать .v2. и обновить ссылки либо временно использовать другой подход к кешу в локальной копии. Само имя не является автоматически вычисленным хешем; версию поддерживает автор примера. Не редактируйте уже закешированный immutable-файл и не ждите гарантированной немедленной доставки новых байтов.

Два типа ресурсов стенда

Локальный сервер выдаёт HTML и изменяемые модули с no-cache, а собственные изображения и CSS с .v1. — с длинным сроком. Это намеренно ограниченная демонстрация. Она не устанавливает готовую политику безопасности или кеширования пользовательских данных для настоящего сайта.

Изменяемый документ:
Cache-Control: no-cache

Версионный учебный asset:
Cache-Control: public, max-age=31536000, immutable

Число 31536000 — выбранный срок в секундах для примера политики, а не измеренная задержка. immutable выражает неизменность представления в период свежести; он не превращает меняющийся файл в надёжную версию. Если новый CSS опубликован по старому адресу, ошибка находится в договоре обновления, даже когда браузер корректно использует прежний ответ.

Условная доставка может использовать Last-Modified или ETag. В нашем простом сервере применяется обычное поведение SimpleHTTPRequestHandler с датой изменения файла; собственный ETag не добавлен. Ответ 304 возможен при подходящем условном запросе, но не обещается для каждого reload. Нужны фактические Headers и действие пользователя.

Протокол холодного и повторного перехода

Сначала проведите холодный сценарий. В DevTools включите Disable cache и выполните обычный переход. Запишите список ресурсов, переданные байты и LCP выбранного элемента. Затем отдельной группой исследуйте повторный переход с доступным кешем. Не усредняйте эти группы и не заменяйте вторую hard reload без пояснения.

Отключение кеша при открытых DevTools является режимом инструмента. Когда панель закрыта, условие может измениться. Перед каждым набором повторов проверяйте фактический переключатель. Очистка данных, обычный reload, переход в новой вкладке и возврат по истории также способны запускать разные пути; название действия входит в протокол.

Сравним выдуманные учебные строки. Версия A при холодной доставке имеет LCP 3100 миллисекунд и 240 КиБ передачи; повторная доставка той же версии показывает 1800 миллисекунд и 35 КиБ. Эти числа придуманы и не получены из стенда. Они не доказывают оптимизацию исходников: менялось состояние кеша, а сама версия оставалась прежней.

Чтобы исследовать candidate, сопоставляйте холодную A с холодной B, а повторную A с повторной B. При этом сохраняйте устройство, viewport и действия. Полные прототипы объединяют несколько изменений, поэтому для причинного вывода дополнительно понадобится сравнение одной независимой переменной. Кеш не отменяет правило первого урока, а добавляет ещё одно важное условие.

Как читать ответ в Network

Для нужного ресурса исследуйте статус, Cache-Control, дату или валидатор и колонку Size. Ответ из memory cache, disk cache и сетевой 304 относятся к разным путям. У 304 не передаётся обычное тело ресурса, но сетевой обмен и проверка всё равно происходят. Поэтому выражение «файл не скачан» не означает полного отсутствия ожидания.

Размер передачи также не равен размеру декодированного представления. CSS может приходить с компрессией, изображение иметь большой растровый размер после обработки, а повторная запись показать ноль сетевых байтов. Сравнивайте одноимённые величины, иначе таблица создаст мнимое улучшение. Для вопроса о канале полезны переданные данные, для обработки — другой набор наблюдений.

Проверьте согласованность версии: документ ссылается на нужный CSS и картинку, а содержимое отвечает этой версии. Если новая разметка требует нового свойства, но используется старый стиль, повторная загрузка может показывать функционально другой результат. Быстрое получение неправильного интерфейса не соответствует цели. В нашем стенде такие проблемы изучаются локально, не изменяя сайт ProfessorWeb.

Граница с другими видами хранения

Service worker и Cache API способны перехватить запрос и использовать собственный ответ. Тогда одного Cache-Control может быть недостаточно для объяснения фактической доставки. В speed-lab worker не зарегистрирован, чтобы ограничить переменные. Если читатель переносит пример на origin с прежним worker, сначала нужно исследовать это состояние и записать его.

Возврат по истории способен использовать ещё один механизм сохранения состояния страницы. Его нельзя объявлять обычной повторной загрузкой HTML из HTTP-кеша. Удержание готового документа и проверка ответа имеют разную временную цепочку. Когда результат кажется неожиданно мгновенным, уточните путь перехода, прежде чем искать чудесный эффект новой настройки.

Сохраните два отдельных протокола и объяснение каждого полученного ответа. Уменьшение повторной передачи может быть полезно, но решение должно также обеспечивать обновление нужных ресурсов. Теперь у нас есть данные о загрузке, устойчивости, взаимодействии и кеше; последний урок объединит их в бюджет, который помогает принимать конкретные изменения без потери функции страницы.

Оглавление курса