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, и до недавнего времени они проводились при 5 % загрузки страниц.
Мы увеличили этот показатель до 10 % от загрузки страниц 2 октября и намерены увеличить этот показатель до 20 % от всех загрузок страниц в ноябре и до 50 % в начале следующего года, а вскоре после этого запустим эту функцию полностью, а некоторые варианты отказа будут обсуждаться далее.
Конфиденциальные данные
Хотя наш анализ показывает, что большинство переходов вперед и назад не содержат конфиденциальных данных и поэтому должны иметь право на использование 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 года.
Влияние на производительность
Причина, по которой мы вносим это изменение, — улучшить удобство использования страниц для пользователей в Интернете. Мы увидели заметные улучшения в Core Web Vitals, когда впервые запустили bfcache, и теперь хотим внедрить те же улучшения на большее количество сайтов.
Владельцы сайтов могут увидеть улучшение своих основных веб-показателей по мере его внедрения и могут измерять использование bfcache в CrUX, в том числе на панели управления CrUX .
Аналитика воздействия
Страницы, восстановленные из 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 на многих других страницах, чтобы улучшить их удобство для пользователей. Мы тщательно обдумали это изменение и наш подход направлен на то, чтобы внедрить его максимально безопасным способом. Мы надеемся, что представленная здесь информация поможет разработчикам понять это изменение и внести необходимые изменения, чтобы избежать проблем, когда это произойдет.