Холодная загрузка и возврат на страницу
Один и тот же URL может открываться через ссылку, перезагрузку и кнопку Back. На экране появится знакомая статья, но работа браузера будет различаться. Если объединить все эти случаи, изменение состава посещений способно выглядеть как изменение скорости кода. В этом уроке научимся описывать путь перехода независимо от адреса страницы.
Используем advanced/history-lab: два небольших документа и журнал событий. Исходники подготовлены для самостоятельной ручной сессии и не исполнялись автором. Полученные читателем времена не должны смешиваться с синтетическим CSV прошлого урока. Практический результат — матрица навигаций, в которой каждое наблюдение имеет понятную техническую область.
Тип навигации не определяет кеш
Свойство PerformanceNavigationTiming.type описывает способ создания навигационной записи. navigate включает обычные переходы, reload относится к перезагрузке, back_forward — к обходу истории. Эти значения объясняют действие браузера, но сами не сообщают, был ли файл получен по сети или использован из HTTP-кеша. Их определения приведены в MDN: navigation type.
Следующий фрагмент показывает запись текущего документа:
const navigation = performance.getEntriesByType("navigation")[0];
console.table({
type: navigation?.type ?? "unknown",
responseStart: navigation?.responseStart ?? null,
responseEnd: navigation?.responseEnd ?? null,
transferSize: navigation?.transferSize ?? null
});
Поля времени относятся к соответствующей навигационной записи. Здесь не вычисляется полный пользовательский результат. Если записи нет, используется неизвестное состояние, а не выдуманный тип. Данные доставки необходимо сопоставлять с Network и фактическими ответами; назначение интерфейса описано в MDN: PerformanceNavigationTiming.
Обычный переход navigate способен использовать уже сохранённый CSS. Перезагрузка reload также не является универсальным синонимом полного обхода кеша. А холодное условие относится к наличию пригодных ответов и настройкам инструмента. Поэтому в протоколе нужны две разные колонки: действие навигации и состояние доставки ресурсов.
Три состояния одного адреса
Сначала откройте first.html обычным переходом при выбранном условии кеша. Затем выполните перезагрузку. Наконец, перейдите по ссылке к second.html и вернитесь кнопкой Back браузера. Перед каждым действием запишите сценарий, а после — сведения о типе и событиях. Это инструкция читателю, а не отчёт уже выполненных действий.
У перезагрузки появляется новая работа документа, но часть ресурсов может доставляться повторно из сохранённых ответов. У возврата по истории возможны разные пути: новый документ или восстановление ранее сохранённого состояния. Наличие значения back_forward само по себе не доказывает bfcache. Такое различие объясняется в руководстве по back/forward cache.
Восстановление страницы определяют по pageshow.persisted. Если значение истинно, событие относится к восстановленному документу. Его прежняя навигационная запись не превращается автоматически в новую запись текущего возврата. Поэтому нельзя взять первоначальное время документа и объявить его временем восстановления. Семантика события приведена в MDN: pageshow.
В журнале стенда рядом с событием выводятся исходный тип навигации и boot. Последний представляет время инициализации программы. При сохранённом документе эта переменная остаётся частью прежнего состояния. Если создаётся новый документ, программа запускается заново. Это дополнительное наблюдение за исходниками, а не замена признака persisted.
Что означает холодное условие
В уроке об HTTP-кеше уже разобраны свежесть, проверка и версии ресурсов. Здесь применим их к сравнению. Холодный режим исследует доставку без подходящей готовой копии. Повторный режим исследует использование или проверку сохранённых ответов. У обоих режимов должен быть отдельно назван способ перехода.
Для контролируемого лабораторного сравнения читатель может использовать Disable cache при открытых DevTools. Но запись «кеш отключён» не отменяет остальные механизмы браузера и не описывает обычное посещение аудитории. В частности, восстановление готового документа представляет другую задачу. Не считайте любую быструю кнопку Back свидетельством успешно настроенного Cache-Control.
Проверьте фактические ответы для HTML, CSS и изображения. В одном сценарии HTML может потребовать сетевой проверки, а стиль остаться свежим. Значит, состояние страницы нельзя всегда выразить одним словом «warm». В подробном расследовании полезно назвать ресурсы, которые определяют выбранный путь, и оставить их состояния рядом с общей категорией.
Если инструменты или сервер изменяют политику между попытками, сравнение нужно начать с уточнения условий. Наш простой статический сервер не создаёт production-контракт кеширования. Его заголовки читатель изучает самостоятельно. Исходники старого speed-lab не меняются ради нового эксперимента, чтобы прежняя учебная последовательность сохраняла свой смысл.
Построим матрицу сценариев
Пустая форма находится в advanced/notes/manual-matrix.md. Для этого урока расширьте её тремя признаками: заявленное действие, фактический тип новой навигации и pageshow.persisted. Последний записывается по событию, а не угадывается по субъективной быстроте. Результат поможет отличить задуманную сессию от того, что действительно сделал браузер.
Рассмотрим структуру без заполненных времён:
| Действие читателя | Что проверить | Что пока нельзя утверждать |
|---|---|---|
| Переход по ссылке | navigation.type и ответы ресурсов | Что вся доставка холодная |
| Обычный reload | Новый документ и фактический кеш | Что все байты пришли по сети |
| Back после второй страницы | pageshow.persisted и состояние | Что восстановление гарантировано |
| Ссылка обратно на first.html | Обычный переход к тому же URL | Что это эквивалент кнопки Back |
Ссылка на прежний адрес делает переход, а кнопка Back проходит историю. Даже если обе приводят к одинаковому тексту, они выражают разные действия пользователя. В стенде специально есть такая ссылка на второй странице, чтобы можно было сравнить смысл сценария без изменения содержания.
Возврат и метрики жизненного цикла
Локальный наблюдатель из урока 13 заканчивает первый сегмент при скрытии и не переинициализируется после bfcache. Это ограничение становится видимым именно здесь. Его старый LCP-кандидат нельзя приписать возвращению к статье. Чтобы наблюдать несколько сегментов правильно, потребуется другой договор и реализация метрик, учитывающая восстановление.
Также не объединяйте момент смены вкладки с новой навигацией. Документ может оставаться открытым, пока человек переключается между приложениями. Это изменение видимости, но не обязательное создание новой страницы. Если будущий отчёт считает такие события отдельными посещениями, правило должно быть названо заранее и одинаково применяться к обеим версиям.
Для статистического сравнения полезно сначала сопоставить одинаковые группы переходов, а затем показать их доли. Рост возвратов по истории может улучшить опыт постоянных читателей и одновременно изменить распределение оставшихся обычных загрузок. Нужны оба наблюдения: состав аудитории и техническая цепочка внутри сценария. Одно не следует автоматически из другого.
Завершите урок четырьмя отдельными строками своей матрицы. Укажите, какие ресурсы получались заново и где восстановился прежний документ. Если восстановление не произошло, это тоже полноценный результат при сохранённых условиях. Следующий урок исследует именно bfcache: как проверить состояние после возвращения и избежать ненужной повторной инициализации интерфейса.