Опубликовано: 21 октября 2024 г., Последнее обновление: 9 сентября 2025 г.
Chrome вносит изменения, позволяющие использовать возвратный кэш (bfcache) для страниц с Cache-Control: no-store когда это безопасно. Узнайте, что это означает для разработчиков.
Фон
Установка Cache-Control: no-store в HTTP-заголовке — это сигнал о том, что страница не должна сохраняться в HTTP-кеше. Это следует использовать для страниц, содержащих конфиденциальные данные, например, для страниц, на которых пользователь авторизован, но директива no-store часто используется на страницах без конфиденциальных данных.
С помощью bfcache вместо того, чтобы уничтожать страницу при уходе пользователя с неё, мы откладываем уничтожение и приостанавливаем выполнение JS-кода. Если пользователь вскоре вернётся, мы снова делаем страницу видимой и возобновляем выполнение JS-кода. Это обеспечивает практически мгновенную навигацию пользователя по страницам.
Хотя это не требуется спецификацией HTML, браузеры обычно воспринимают Cache-Control: no-store как сигнал, чтобы не помещать страницу в bfcache. Это основная причина, по которой bfcache не используется : примерно в 17% случаев навигации по истории на мобильных устройствах и в 7% случаев навигации по истории на настольных компьютерах. Это означает, что эти страницы не получают преимущества от быстрого восстановления и должны полностью перезагружать страницу, включая все сетевые вызовы, выполнение JavaScript и рендеринг.
Часто Cache-Control: no-store устанавливается, чтобы избежать проблем с кэшированием при изменении сайта, но эта причина менее актуальна, когда используется bfcache, поскольку вся страница восстанавливается почти так же, как если бы она была открыта все это время.
Как Chrome меняет это поведение
Chrome объявил о намерении изменить это поведение, но пока относится к этому вопросу с осторожностью. Начиная с версии Chrome 116, мы проводим эксперименты, постепенно увеличивая процент загрузки страниц, и ожидается, что он достигнет 100% в марте и апреле 2025 года.
Конфиденциальные данные
Хотя наш анализ показывает, что большинство переходов назад или вперёд не содержат конфиденциальных данных и, следовательно, должны быть помещены в bfcache, существуют случаи, когда страницы не следует помещать в bfcache. Например, при выходе из системы не должно быть возможности открыть страницу, на которую был выполнен вход, переходя назад или вперёд.
Чтобы избежать этого, Chrome удаляет страницу из bfcache при изменении файлов cookie или других методов авторизации .
Кроме того, использование следующих API для страниц, использующих Cache-Control: no-store , по-прежнему будет делать эти страницы непригодными для bfcache:
Обратите внимание, что это не полный список 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 по причине «Страницы, основной ресурс которых имеет Cache-Control: no-store не могут войти в обратный кэш». Это отображается в тестере bfcache в Chrome DevTools .
Вы можете использовать эту тестовую страницу 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, и теперь хотим внедрить эти улучшения на большем количестве сайтов.
Владельцы сайтов смогут заметить улучшение своих основных веб-показателей по мере их внедрения и смогут измерять использование 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 ещё большему числу страниц, чтобы улучшить взаимодействие с ними для пользователей. Мы тщательно продумали это изменение и стремимся внедрить его максимально безопасно. Мы надеемся, что представленная здесь информация поможет разработчикам разобраться в этом изменении и внести необходимые изменения, чтобы избежать проблем в случае его возникновения.