Опубликовано: 21 октября 2024 г., Последнее обновление: 9 сентября 2025 г.
Chrome вносит изменения, разрешающие использование кэша "назад/вперед" (bfcache) для страниц, использующих Cache-Control: no-store если это безопасно. Узнайте, что это значит для разработчиков.
Фон
Установка Cache-Control: no-store в качестве HTTP-заголовка сигнализирует о том, что страница не должна сохраняться в HTTP-кэше. Это следует использовать для страниц, содержащих конфиденциальные данные — например, для страниц, на которых пользователь авторизован, — но директива no-store часто используется для страниц без конфиденциальных данных.
В bfcache вместо удаления страницы при переходе пользователя на другую страницу, мы откладываем удаление и приостанавливаем выполнение JavaScript. Если пользователь вскоре вернется на страницу, мы снова сделаем ее видимой и возобновим выполнение JavaScript. Это приводит к практически мгновенной навигации по странице для пользователя.
While it is not required by the HTML spec, browsers typically take Cache-Control: no-store as a signal to avoid placing the page in bfcache. This is the largest reason the bfcache is not used , for about 17% of history navigations on mobile and 7% of history navigations on desktop. This means these pages don't benefit from the quick restores and must fully reload the page, including any network calls, JavaScript execution, and rendering.
Часто Cache-Control: no-store устанавливается для предотвращения проблем с кэшированием при изменении сайта, но эта причина менее актуальна при использовании bfcache, поскольку страница восстанавливается полностью, как если бы она оставалась открытой с самого начала.
Как Chrome меняет это поведение
Chrome объявил о намерении изменить это поведение, но подходит к этому изменению с осторожностью. Мы проводим эксперименты, начиная с Chrome 116, постепенно увеличивая процент загрузок страниц, и ожидается, что он достигнет 100% в марте и апреле 2025 года.
Конфиденциальные данные
Хотя наш анализ показывает, что большинство переходов назад или вперед не содержат конфиденциальных данных и, следовательно, должны попадать в bfcache, существуют случаи, когда страницы не следует помещать в bfcache. Например, после выхода из системы не должно быть возможности получить доступ к странице, на которой вы авторизованы, путем перехода назад или вперед.
Чтобы этого избежать, Chrome будет удалять страницу из bfcache при изменении файлов cookie или других методов авторизации .
Кроме того, использование следующих API для страниц, использующих Cache-Control: no-store , по-прежнему будет делать эти страницы непригодными для bfcache:
Кроме того, если страница Cache-control: no-store выполняет запрос fetch или XHR и в ответе возвращает Cache-control: no-store , то эта страница также будет удалена, поскольку она может содержать конфиденциальные данные.
Обратите внимание, что это не полный список API, которые препятствуют использованию bfcache, а лишь список API, которые блокируют bfcache на страницах с Cache-Control: no-store даже если они не используются в момент ухода со страницы.
Время ожидания bfcache для страниц с Cache-Control: no-store также сокращено до 3 минут (с 10 минут, используемых для страниц, не использующих Cache-Control: no-store ), чтобы еще больше снизить риски.
Варианты выхода предприятия
В компаниях часто встречается сложно обновляемое программное обеспечение и используются общие устройства. Политику AllowBackForwardCacheForCacheControlNoStorePageEnabled можно отключить, чтобы и дальше предотвращать использование bfcache для страниц Cache-Control: no-store .
Проверка изменений
Разработчики могут протестировать это изменение с помощью следующего флага:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Если применяется какое-либо из ранее упомянутых исключений — например, изменение cookie-файлов — это не позволит странице использовать bfcache, и в инструменте тестирования bfcache в Chrome появится сообщение "Страницы, основной ресурс которых имеет Cache-Control: no-store не могут войти в кэш "назад/вперед"".
Вы можете использовать эту тестовую страницу bfcache для проверки работы программы как с этим флагом, так и без него.
Что должны знать разработчики
Хотя разработчикам не потребуется вносить какие-либо изменения, чтобы их пользователи могли воспользоваться преимуществами более широкого использования bfcache, им, возможно, следует учесть некоторые моменты. Аналогичные проблемы могли возникнуть и у других сайтов при первоначальном запуске bfcache в декабре 2021 года.
Стоит ли разработчикам по-прежнему стремиться к сокращению использования Cache-Control: no-store ?
Использование bfcache включено для Cache-Control: no-store при указанных выше ограниченных условиях и только для Chrome. Другие браузеры могут блокировать использование bfcache при использовании Cache-Control: no-store .
Лучшей практикой по-прежнему остается минимизация использования Cache-Control: no-store вместо того, чтобы полагаться на эти эвристические методы.
Влияние на производительность
Причина, по которой мы вносим это изменение, заключается в улучшении пользовательского опыта на веб-сайтах. Мы заметили существенные улучшения в показателях Core Web Vitals после первого запуска bfcache, и теперь хотим распространить эти же улучшения на большее количество сайтов.
Владельцы сайтов могут заметить улучшение показателей Core Web Vitals по мере внедрения этой функции, а также смогут измерять использование bfcache в CrUX, в том числе в CrUX Vis .
Анализ воздействия
Восстанавливаемые из bfcache страницы «восстанавливают» старую страницу (включая кучу JavaScript), а не перезагружают её. Многие популярные аналитические сервисы не учитывают восстановление из bfcache как новые просмотры страниц, поскольку оно регистрирует просмотры страниц только при их первоначальной загрузке.
Поэтому при первом использовании bfcache сайты могут заметить снижение количества загрузок страниц в своей аналитике. Мы рекомендуем рассматривать это как просмотры страниц, установив обработчики события pageshow и проверив persisted свойство:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
Обработка обновлений при восстановлении страницы
Поскольку теперь сайты могут видеть использование bfcache там, где раньше его не было, и страница вместо этого будет полностью перезагружена свежими данными, разработчикам, возможно, стоит рассмотреть возможность обновления данных при восстановлении bfcache.
Обновления можно запускать аналогично регистрации дополнительных просмотров страниц для аналитики с помощью события pageshow и проверки persisted свойства.
Обратите внимание, что не весь контент нуждается в обновлении, и пользователи могут предпочесть вернуться к контенту, который они видели ранее. Например, обновление списка статей может привести к тому, что пользователь больше не увидит статью, которую хотел просмотреть ранее.
Влияние на рекламу
Аналогично влиянию аналитики, сайты могут наблюдать снижение количества показов рекламы, если объявления загружаются только при полной загрузке страницы. Для обеспечения соответствия с полной загрузкой страницы можно программно обновлять объявления при восстановлении bfcache, используя событие pageshow и проверяя persisted свойство, но это не всегда может быть правильным решением . Обратитесь к документации вашего поставщика рекламы, чтобы узнать, как запускать перезагрузку объявлений.
Более подробная информация о bfcache
Для получения более подробной информации о bfcache см. наше подробное техническое руководство по bfcache .
Обратная связь
Мы будем рады получить отзывы об этом изменении, которые можно оставить в системе отслеживания ошибок Chrome, используя компонент bfcache .
Заключение
Мы рады предоставить преимущества bfcache для гораздо большего числа страниц, чтобы улучшить пользовательский опыт. Мы тщательно продумали это изменение, и наш подход направлен на его внедрение максимально безопасным способом. Мы надеемся, что предоставленная здесь информация поможет разработчикам понять это изменение и внести необходимые корректировки, чтобы избежать проблем в случае его возникновения.