Назад/вперед кеш

Philip Walton

Barry Pollard

Кэш назад/вперед (или bfcache) — это оптимизация браузера, которая обеспечивает мгновенную навигацию вперед и назад. Это значительно улучшает возможности просмотра, особенно для пользователей с медленными сетями или устройствами.

Веб-разработчикам очень важно понимать, как оптимизировать ваши страницы для bfcache , чтобы ваши пользователи могли воспользоваться преимуществами.

Совместимость с браузером

Все основные браузеры включают bfcache, включая Chrome начиная с версии 96, Firefox и Safari .

основы bfcache

При использовании обратного/прямого кэша (bfcache) вместо уничтожения страницы, когда пользователь уходит, мы откладываем уничтожение и приостанавливаем выполнение JS. Если пользователь вскоре вернется назад, мы снова сделаем страницу видимой и возобновим выполнение JS. Это приводит к почти мгновенной навигации по страницам для пользователя.

Сколько раз вы посещали веб-сайт и нажимали ссылку, чтобы перейти на другую страницу, только для того, чтобы понять, что это не то, что вам нужно, и нажать кнопку «Назад»? В этот момент bfcache может существенно повлиять на скорость загрузки предыдущей страницы:

Посмотрите это видео о bfcache в действии, чтобы понять, какое ускорение он может обеспечить при навигации:

На видео пример с bfcache работает немного быстрее, чем пример без него.

bfcache не только ускоряет навигацию, но и снижает использование данных, поскольку ресурсы не нужно загружать повторно.

Данные об использовании Chrome показывают, что 1 из 10 переходов на компьютере и 1 из 5 на мобильных устройствах осуществляется либо вперед, либо назад. Благодаря включенному bfcache браузеры могут исключить передачу данных и время, затрачиваемое на загрузку миллиардов веб-страниц каждый день!

Как работает «кэш»

«Кэш», используемый bfcache, отличается от кэша HTTP , который играет свою роль в ускорении повторной навигации. bfcache — это снимок всей страницы в памяти, включая кучу JavaScript, тогда как HTTP-кеш содержит только ответы на ранее сделанные запросы. Поскольку все запросы, необходимые для загрузки страницы, выполняются из HTTP-кеша очень редко, повторные посещения с использованием восстановления bfcache всегда выполняются быстрее, чем даже самые хорошо оптимизированные навигации без использования bfcache.

Заморозка страницы для ее повторного включения позже требует некоторой сложности с точки зрения того, как лучше всего сохранить незавершенный код. Например, как обрабатывать вызовы setTimeout() , когда таймаут истекает, пока страница находится в bfcache?

Ответ заключается в том, что браузеры приостанавливают все ожидающие таймеры или невыполненные обещания для страниц в bfcache, включая почти все ожидающие задачи в очередях задач JavaScript , и возобновляют обработку задач, если страница восстанавливается из bfcache.

В некоторых случаях, например, в случае тайм-аутов и обещаний, это довольно низкий риск, но в других случаях это может привести к запутанному или неожиданному поведению. Например, если браузер приостанавливает задачу, необходимую как часть транзакции IndexedDB , это может повлиять на другие открытые вкладки в том же источнике, поскольку к одним и тем же базам данных IndexedDB можно получить доступ для нескольких вкладок одновременно. В результате браузеры обычно не пытаются кэшировать страницы в середине транзакции IndexedDB или при использовании API, которые могут повлиять на другие страницы.

Дополнительные сведения о том, как использование различных API влияет на соответствие страницы требованиям bfcache, см. в разделе Оптимизация страниц для bfcache .

bfcache и iframe

Если страница содержит встроенные iframe, то сами iframe не подлежат использованию в bfcache. Например, если вы перейдете на другую страницу внутри iframe, а затем вернетесь назад, браузер вернется «назад» внутри iframe, а не в основной фрейм, но обратная навигация внутри iframe не будет использовать bfcache.

Основной фрейм также может быть заблокирован от использования bfcache, если встроенный iframe использует API, которые блокируют это. Чтобы избежать этого, можно использовать политику разрешений, установленную на основном фрейме, или использование атрибутов sandbox .

Bfcache и одностраничные приложения (SPA)

Поскольку bfcache работает с навигацией, управляемой браузером, он не работает для «мягкой навигации» в одностраничном приложении (SPA). Тем не менее, bfcache все равно может помочь при возврате к SPA, вместо полной повторной инициализации этого приложения с самого начала.

API для наблюдения за bfcache

Хотя bfcache — это оптимизация, которую браузеры выполняют автоматически, разработчикам все равно важно знать, когда это происходит, чтобы они могли оптимизировать свои страницы для нее и соответствующим образом корректировать любые показатели или показатели производительности .

Основными событиями, используемыми для наблюдения за bfcache, являются события перехода страниц pageshow и pagehide , которые поддерживаются большинством браузеров .

Новые события жизненного цикла страницы — freeze и resume — также отправляются, когда страницы входят в bfcache или покидают его, а также в некоторых других ситуациях, например, когда фоновая вкладка зависает, чтобы минимизировать загрузку ЦП. Эти события поддерживаются только в браузерах на базе Chromium.

Наблюдайте за восстановлением страницы из bfcache.

Событие pageshow срабатывает сразу после события load при первоначальной загрузке страницы и каждый раз, когда страница восстанавливается из bfcache. Событие pageshow имеет persisted свойство, которое имеет значение true , если страница была восстановлена ​​из bfcache, и false в противном случае. Вы можете использовать свойство persisted , чтобы отличать регулярные загрузки страниц от восстановления bfcache. Например:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

В браузерах, поддерживающих API жизненного цикла страницы, событие resume срабатывает, когда страницы восстанавливаются из bfcache (непосредственно перед событием pageshow ) и когда пользователь повторно посещает замороженную фоновую вкладку. Если вы хотите обновить состояние страницы после ее заморозки (включая страницы в bfcache), вы можете использовать событие resume , но если вы хотите измерить частоту попаданий в bfcache вашего сайта, вам нужно будет использовать событие pageshow . В некоторых случаях вам может потребоваться использовать оба.

Подробные сведения о передовых методах измерения bfcache см. в разделе «Как bfcache влияет на аналитику и измерение производительности» .

Наблюдайте, когда страница входит в bfcache

Событие pagehide возникает либо при выгрузке страницы, либо когда браузер пытается поместить ее в bfcache.

Событие pagehide также имеет persisted свойство. Если оно false , вы можете быть уверены, что эта страница не собирается войти в bfcache. Однако persisted true не гарантирует, что страница будет кэширована. Это означает, что браузер намерен кэшировать страницу, но могут быть и другие факторы, которые делают кэширование невозможным.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

Аналогично, событие freeze срабатывает сразу после события pagehide , если persisted имеет true , но это означает лишь то, что браузер намеревается кэшировать страницу. Возможно, от него все равно придется отказаться по ряду причин, которые будут объяснены позже.

Оптимизируйте свои страницы для bfcache

Не все страницы сохраняются в bfcache, и даже если страница сохраняется там, она не остается там бесконечно. Крайне важно, чтобы разработчики понимали, что делает страницы подходящими (и неподходящими) для bfcache, чтобы максимизировать вероятность попадания в кеш.

В следующих разделах описаны лучшие практики, позволяющие максимально повысить вероятность того, что браузер сможет кэшировать ваши страницы.

Никогда не используйте событие unload

Самый важный способ оптимизировать bfcache во всех браузерах — никогда не использовать событие unload . Всегда!

Событие unload является проблематичным для браузеров, поскольку оно предшествует bfcache, и многие страницы в Интернете работают с (разумным) предположением, что страница не будет продолжать существовать после запуска события unload . Это представляет собой проблему, поскольку многие из этих страниц также были созданы с предположением, что событие unload будет срабатывать каждый раз, когда пользователь уходит, что больше не соответствует действительности (и уже давно не соответствует действительности ).

Таким образом, браузеры сталкиваются с дилеммой: им приходится выбирать между чем-то, что может улучшить взаимодействие с пользователем, но также может привести к поломке страницы.

На настольных компьютерах Chrome и Firefox решили запретить страницам использовать bfcache, если они добавляют прослушиватель unload , что менее рискованно, но также дисквалифицирует многие страницы. Safari попытается кэшировать некоторые страницы с помощью прослушивателя событий unload , но для уменьшения возможных сбоев он не будет запускать событие unload , когда пользователь уходит, что делает событие очень ненадежным.

На мобильных устройствах Chrome и Safari попытаются кэшировать страницы с помощью прослушивателя событий unload , поскольку риск поломки ниже из-за того, что событие unload всегда было крайне ненадежным на мобильных устройствах. Firefox рассматривает страницы, использующие unload как непригодные для bfcache, за исключением iOS, которая требует, чтобы все браузеры использовали механизм рендеринга WebKit, и поэтому он ведет себя как Safari.

Вместо использования события unload используйте событие pagehide . Событие pagehide срабатывает во всех случаях, когда срабатывает событие unload , а также когда страница помещается в bfcache.

Фактически, в Lighthouse есть аудит no-unload-listeners , который предупредит разработчиков, если какой-либо JavaScript на их страницах (в том числе из сторонних библиотек) добавит прослушиватель событий unload .

Из-за его ненадежности и влияния на производительность bfcache Chrome планирует отказаться от поддержки события unload .

Используйте политику разрешений, чтобы предотвратить использование обработчиков выгрузки на странице.

Сайты, которые не используют обработчики событий unload могут гарантировать, что они не будут добавлены с помощью политики разрешений .

Permissions-Policy: unload=()

Это также не позволяет третьим лицам или расширениям замедлять работу сайта, добавляя обработчики выгрузки и делая сайт недоступным для bfcache.

Добавляйте прослушиватели beforeunload только условно

Событие beforeunload не делает ваши страницы неприемлемыми для bfcache в современных браузерах, но раньше это было так, и оно по-прежнему ненадежно, поэтому избегайте его использования без крайней необходимости.

Однако, в отличие от события unload , у beforeunload есть законные варианты использования. Например, если вы хотите предупредить пользователя о том, что у него есть несохраненные изменения, которые они потеряют, если покинут страницу. В этом случае рекомендуется добавлять прослушиватели beforeunload только в том случае, если у пользователя есть несохраненные изменения, а затем удалять их сразу после сохранения несохраненных изменений.

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

Минимизируйте использование Cache-Control: no-store

Cache-Control: no-store — это HTTP-заголовок, который веб-серверы могут устанавливать для ответов, который указывает браузеру не сохранять ответ в каком-либо HTTP-кэше. Он используется для ресурсов, содержащих конфиденциальную информацию пользователя, например страниц после входа в систему.

Хотя bfcache не является HTTP-кешем, исторически, когда Cache-Control: no-store установлен для самого ресурса страницы (в отличие от любого подресурса), браузеры предпочитали не сохранять страницу в bfcache, поэтому любые страницы, использующие Cache-Control: no-store может не иметь права на bfcache. В настоящее время ведется работа по изменению этого поведения Chrome с целью сохранения конфиденциальности.

Поскольку Cache-Control: no-store ограничивает право страницы на использование bfcache, его следует устанавливать только на страницах, содержащих конфиденциальную информацию, где любое кэширование неприемлемо.

Для страниц, которым необходимо всегда предоставлять актуальное содержимое (и это содержимое не содержит конфиденциальной информации), используйте Cache-Control: no-cache или Cache-Control: max-age=0 . Эти директивы предписывают браузеру повторно проверить содержимое перед его обслуживанием и не влияют на соответствие страницы требованиям bfcache.

Обратите внимание, что когда страница восстанавливается из bfcache, она восстанавливается из памяти, а не из HTTP-кэша. В результате директивы типа Cache-Control: no-cache или Cache-Control: max-age=0 не учитываются, и повторная проверка перед отображением содержимого пользователю не выполняется.

Однако это, вероятно, по-прежнему удобнее для пользователя, поскольку восстановление bfcache происходит мгновенно, а поскольку страницы не остаются в bfcache очень долго, маловероятно, что содержимое устарело. Однако, если ваш контент меняется каждую минуту, вы можете получать любые обновления с помощью события pageshow , как описано в следующем разделе.

Обновите устаревшие или конфиденциальные данные после восстановления bfcache.

Если на вашем сайте сохраняется состояние пользователя, особенно любая конфиденциальная информация о пользователе, эти данные необходимо обновить или очистить после восстановления страницы из bfcache.

Например, если пользователь переходит на страницу оформления заказа, а затем обновляет свою корзину покупок, обратная навигация потенциально может предоставить устаревшую информацию, если устаревшая страница будет восстановлена ​​из bfcache.

Другой, более важный пример: пользователь выходит из сайта на общедоступном компьютере, а следующий пользователь нажимает кнопку «Назад». Это потенциально может привести к раскрытию личных данных, которые, как предполагал пользователь, были удалены при выходе из системы.

Чтобы избежать подобных ситуаций, полезно всегда обновлять страницу после события pageshow , если event.persisted имеет true :

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

Хотя в идеале вы должны обновить содержимое на месте, для некоторых изменений вам может потребоваться принудительно полная перезагрузка. Следующий код проверяет наличие специфичного для сайта файла cookie в событии pageshow и перезагружается, если файл cookie не найден:

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

Преимущество перезагрузки заключается в том, что история по-прежнему сохраняется (что позволяет осуществлять навигацию вперед), но в некоторых случаях перенаправление может быть более подходящим.

Восстановление рекламы и bfcache

Может возникнуть соблазн попытаться избежать использования bfcache для показа нового набора объявлений при каждой навигации вперед/назад. Однако, помимо влияния на производительность, сомнительно, приведет ли такое поведение к улучшению взаимодействия с рекламой. Пользователи, возможно, заметили рекламу, которую они намеревались вернуть, чтобы нажать на нее, но, перезагрузив ее, а не восстановив из bfcache, они не смогут этого сделать. Прежде чем делать предположения, важно протестировать этот сценарий — в идеале с помощью A/B-теста.

Для сайтов, которые хотят обновить рекламу при восстановлении bfcache, обновление только рекламы в событии pageshow , когда event.persisted имеет true позволяет сделать это, не влияя на производительность страницы. Обратитесь к своему рекламному провайдеру, и вот один пример того, как это сделать с помощью тега публикации Google .

Избегайте ссылок window.opener

В старых браузерах, если страница была открыта с помощью window.open() по ссылке с target=_blank без указания rel="noopener" , открывающаяся страница будет иметь ссылку на объект окна открытой страницы.

Помимо угрозы безопасности , страница с ненулевой ссылкой window.opener не может быть безопасно помещена в bfcache, поскольку это может привести к поломке любых страниц, пытающихся получить к ней доступ.

В результате лучше избегать создания ссылок window.opener . Вы можете сделать это, используя rel="noopener" всякий раз, когда это возможно (обратите внимание, что теперь это значение по умолчанию во всех современных браузерах). Если ваш сайт требует открытия окна и управления им через window.postMessage() или напрямую ссылается на объект окна, ни открытое окно, ни средство открытия не будут иметь права на использование bfcache.

Закройте открытые соединения, прежде чем пользователь уйдет

Как упоминалось ранее, когда страница хранится в bfcache, она приостанавливает все запланированные задачи JavaScript и возобновляет их, когда страница извлекается из кеша.

Если эти запланированные задачи JavaScript обращаются только к API DOM — или к другим API, изолированным только от текущей страницы, — то приостановка этих задач, пока страница не видна пользователю, не вызовет никаких проблем.

Однако если эти задачи связаны с API, которые также доступны с других страниц в том же источнике (например: IndexedDB, Web Locks, WebSockets), это может быть проблематичным, поскольку приостановка этих задач может помешать запуску кода на других вкладках.

В результате некоторые браузеры не будут пытаться поместить страницу в bfcache в следующих сценариях:

• Страницы с открытым соединением IndexedDB
• Страницы с выполняемой функцией fetch() или XMLHttpRequest.
• Страницы с открытым соединением WebSocket или WebRTC.

Если ваша страница использует какой-либо из этих API, мы настоятельно рекомендуем закрывать соединения и удалять или отключать наблюдателей во время события скрытия или freeze pagehide . Это позволяет браузеру безопасно кэшировать страницу без риска повлиять на другие открытые вкладки.

Затем, если страница восстановлена ​​из bfcache, вы можете повторно открыть или повторно подключиться к этим API во время события pageshow или resume .

В следующем примере показано, как убедиться, что страницы, использующие IndexedDB, имеют право на использование bfcache, закрыв открытое соединение в прослушивателе событий pagehide :

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

Протестируйте, чтобы убедиться, что ваши страницы кэшируются.

Инструменты разработчика Chrome помогут вам протестировать ваши страницы, чтобы убедиться, что они оптимизированы для bfcache, и выявить любые проблемы, которые могут помешать им получить право на участие.

Чтобы протестировать страницу:

1. Перейдите на страницу в Chrome.
2. В DevTools перейдите в Application -> Back-forward Cache .
3. Нажмите кнопку «Выполнить тест» . Затем DevTools пытается перейти назад и назад, чтобы определить, можно ли восстановить страницу из bfcache.

Если проверка прошла успешно, на панели появится сообщение «Восстановлено из обратного кэша».

Если попытка не удалась, на панели будет указана причина. Если причина кроется в том, что вы можете устранить как разработчик, панель помечает ее как «Действующая» .

В этом примере использование прослушивателя событий unload делает страницу неприемлемой для bfcache. Вы можете это исправить, переключившись с unload на использование pagehide :

window.addEventListener('pagehide', ...);

window.addEventListener('unload', ...);

В Lighthouse 10.0 также добавлен аудит bfcache , который выполняет аналогичный тест. Дополнительную информацию см. в документации аудита bfcache .

Как bfcache влияет на аналитику и измерение производительности

Если вы используете инструмент аналитики для измерения посещений вашего сайта, вы можете заметить уменьшение общего количества просмотров страниц, поскольку Chrome включает bfcache для большего количества пользователей.

На самом деле вы, вероятно, уже занижаете количество просмотров страниц в других браузерах, реализующих bfcache, поскольку многие популярные аналитические библиотеки не измеряют восстановление bfcache как новые просмотры страниц.

Чтобы включить восстановление bfcache в счетчик просмотров страниц, установите прослушиватели для события pageshow и проверьте свойство persisted .

В следующем примере показано, как это сделать с помощью Google Analytics. Другие аналитические инструменты, вероятно, используют аналогичную логику:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

Измерьте коэффициент попадания в bfcache

Вы также можете проверить, использовался ли bfcache, чтобы определить страницы, которые не используют bfcache. Это можно сделать, измерив тип навигации при загрузке страниц:

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

Рассчитайте коэффициент попадания в bfcache, используя значения для навигации back_forward и навигации back_forward_cache .

Важно понимать, что существует ряд сценариев, находящихся вне контроля владельцев сайта, когда навигация «Назад/Вперед» не будет использовать bfcache, в том числе:

• когда пользователь выходит из браузера и запускает его снова
• когда пользователь дублирует вкладку
• когда пользователь закрывает вкладку и снова открывает ее

В некоторых из этих случаев исходный тип навигации может сохраняться некоторыми браузерами и поэтому может отображать тип back_forward несмотря на то, что это не навигация «Назад/Вперед».

Даже без этих исключений bfcache будет удален через некоторое время для экономии памяти.

Таким образом, владельцам веб-сайтов не следует ожидать 100%-ного коэффициента попадания в bfcache для всех переходов back_forward . Однако измерение их соотношения может быть полезно для выявления страниц, на которых сама страница препятствует использованию bfcache для значительной части переходов вперед и назад.

Команда Chrome добавила API NotRestoredReasons , который помогает выявить причины, по которым страницы не используют bfcache, чтобы разработчики могли улучшить показатели попадания в bfcache. Команда Chrome также добавила в CrUX типы навигации, позволяющие видеть количество переходов по bfcache, даже не измеряя его самостоятельно.

Измерение производительности

bfcache также может отрицательно влиять на показатели производительности, собираемые в поле , в частности на показатели, измеряющие время загрузки страницы.

Поскольку навигация по bfcache восстанавливает существующую страницу, а не инициирует загрузку новой страницы, общее количество собранных загрузок страниц уменьшится при включении bfcache. Однако важно то, что загрузка страниц, замененная восстановлением bfcache, вероятно, была бы одной из самых быстрых загрузок страниц в вашем наборе данных. Это связано с тем, что навигация вперед и назад по определению представляет собой повторные посещения, а повторная загрузка страниц обычно происходит быстрее, чем загрузка страниц от первых посетителей (из-за HTTP-кэширования , как упоминалось ранее).

В результате в вашем наборе данных будет меньше быстрых загрузок страниц, что, скорее всего, приведет к более медленному искажению распределения — несмотря на то, что производительность, с которой сталкивается пользователь, вероятно, улучшилась!

Есть несколько способов справиться с этой проблемой. Один из них — аннотировать все показатели загрузки страницы с указанием соответствующего типа навигации : navigate , reload , back_forward или prerender . Это позволяет вам продолжать отслеживать свою эффективность в этих типах навигации, даже если общее распределение имеет отрицательный результат. Мы рекомендуем этот подход для показателей загрузки страницы, не ориентированных на пользователя, таких как время до первого байта (TTFB) .

Для показателей, ориентированных на пользователя, таких как Core Web Vitals , лучшим вариантом будет указать значение, которое более точно отражает то, что испытывает пользователь.

Влияние на основные веб-показатели

Core Web Vitals измеряет взаимодействие пользователя с веб-страницей по различным параметрам (скорость загрузки, интерактивность, визуальная стабильность), и поскольку пользователи воспринимают восстановление bfcache как более быструю навигацию, чем полную загрузку страницы, важно, чтобы метрики Core Web Vitals отражали это. . В конце концов, пользователю все равно, включен bfcache или нет, ему важно лишь, чтобы навигация была быстрой!

Инструменты, которые собирают и составляют отчеты по метрикам Core Web Vitals, такие как отчет об опыте пользователя Chrome , рассматривают восстановление bfcache как отдельные посещения страниц в своем наборе данных. И хотя не существует специальных API-интерфейсов веб-производительности для измерения этих показателей после восстановления bfcache, вы можете приблизительно оценить их значения, используя существующие веб-API:

• Для наибольшего отрисовки содержимого (LCP) используйте разницу между меткой времени события pageshow и меткой времени следующего нарисованного кадра, поскольку все элементы в кадре будут нарисованы одновременно. В случае восстановления bfcache LCP и FCP одинаковы.
• Для взаимодействия с следующей отрисовкой (INP) продолжайте использовать существующий Performance Observer, но сбросьте текущее значение INP на 0.
• Для накопительного смещения макета (CLS) продолжайте использовать существующий Performance Observer, но сбросьте текущее значение CLS на 0.

Дополнительные сведения о том, как bfcache влияет на каждую метрику, см. на страницах руководств по отдельным метрикам Core Web Vitals. Конкретный пример того, как реализовать версии этих метрик в bfcache, можно найти в PR, добавив их в JS-библиотеку web-vitals .

Библиотека JavaScript web-vitals поддерживает восстановление bfcache в сообщаемых ею метриках.

Дополнительные ресурсы

• Кэширование Firefox (bfcache в Firefox)
• Кэш страниц (bfcache в Safari)
• Обратный/прямой кеш: поведение, доступное через Интернет (различия bfcache в разных браузерах)
• тестер bfcache (проверьте, как различные API и события влияют на bfcache в браузерах)
• Изменение игры в производительности: кэширование вперед/назад в браузере (пример из журнала Smashing Magazine, демонстрирующий значительные улучшения Core Web Vitals за счет включения bfcache)