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

Philip Walton

Barry Pollard

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

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

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

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

основы bfcache

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

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

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

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

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

Данные об использовании Chrome показывают, что каждая десятая навигация на настольных компьютерах и каждая пятая на мобильных устройствах — это переход назад или вперед. С включенным 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. Например, если вы переходите на другой URL-адрес внутри iframe, предыдущий контент не попадает в bfcache, и если вы возвращаетесь назад, браузер переходит «назад» внутри iframe, а не в основной фрейм, но навигация назад внутри iframe не будет использовать bfcache.

Однако, когда основной фрейм восстанавливается из bfcache, встроенные 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 страницы, добавленные с обработчиком события unload listener), не подлежат кэшированию через bfcache. Это менее рискованно, но также исключает из кэширования множество страниц. 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 не сделает ваши страницы непригодными для кэширования в современных браузерах, но раньше это происходило, и оно по-прежнему ненадежно, поэтому избегайте его использования, если это не абсолютно необходимо.

В отличие от события 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 открытой страницы.

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

В результате лучше избегать создания ссылок window.opener . Это можно сделать, используя rel="noopener" везде, где это возможно (обратите внимание, что это теперь значение по умолчанию во всех современных браузерах). Если ваш сайт требует открытия окна и управления им через window.postMessage() или путем прямой ссылки на объект window, ни открытое окно, ни открывающий объект не будут доступны для 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 .

В следующем примере показано, как обеспечить возможность кэширования bfcache для страниц, использующих IndexedDB, путем закрытия открытого соединения в обработчике события 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. В инструментах разработчика перейдите в раздел «Приложение» -> «Кэш перемотки вперед-назад» .
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, чтобы выявить страницы, которые его не используют. Это можно сделать, измерив тип навигации при загрузке страниц:

// 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 User Experience Report , рассматривают восстановление bfcache как отдельные посещения страниц в своем наборе данных. И хотя специальных API для измерения этих метрик после восстановления bfcache не существует, вы можете приблизительно оценить их значения, используя существующие веб-API:

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

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

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

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

• Кэширование в Firefox (bfcache в Firefox)
• Кэш страниц (bfcache в Safari)
• Кэш "назад/вперед": поведение, доступное через веб-интерфейс (различия в работе bfcache в разных браузерах)
• Тестер bfcache (проверка влияния различных API и событий на работу bfcache в браузерах)
• Революционное улучшение производительности: кэширование «Назад/Вперед» в браузере (тематическое исследование от Smashing Magazine, демонстрирующее значительное улучшение показателей Core Web Vitals благодаря включению bfcache).