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

Оптимизируйте свои страницы для мгновенной загрузки при использовании кнопок браузера «Назад» и «Вперед».

Филип Уолтон

Барри Поллард

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

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

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

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

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

основы bfcache

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

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

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

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

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

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

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

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

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

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

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

Более подробную информацию о том, как использование различных API влияет на возможность использования bfcache страницы, см. в разделе «Оптимизация страниц для bfcache» ниже.

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

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

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

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

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

Новые события жизненного цикла страницы — 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

Событие pagehide является аналогом события pageshow . Событие pageshow срабатывает, когда страница загружается нормально или восстанавливается из 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 , могут гарантировать, что они не будут добавлены, используя политику разрешений из Chrome 115.

Permission-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. В настоящее время ведутся работы по изменению этого поведения для Chrome с целью сохранения конфиденциальности, но в настоящее время любые страницы, использующие Cache-Control: no-store , не будут иметь права на bfcache.

Поскольку 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, лучше всегда закрывать соединения и удалять или отключать наблюдателей во время события pagehide или freeze страницы. Это позволит браузеру безопасно кэшировать страницу без риска влияния на другие открытые вкладки.

Затем, если страница будет восстановлена ​​из 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 is leaving.
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, и выявить любые проблемы, которые могут помешать им получить право на участие.

Чтобы протестировать конкретную страницу, перейдите к ней в Chrome, а затем в DevTools выберите «Приложение» > «Обратный кеш» . Затем нажмите кнопку «Выполнить тест» , и DevTools попытается перейти назад и назад, чтобы определить, можно ли восстановить страницу из bfcache.

В случае успеха на панели появится сообщение «Восстановлено из обратного кэша»:

В случае неудачи на панели будет указано, что страница не была восстановлена, и будет указана причина.

Если причина кроется в том, что вы, как разработчик, можете устранить, это также будет указано:

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

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

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

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

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

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

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

Если вы не хотите, чтобы количество просмотров страниц уменьшалось из-за того, что Chrome включил 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';
    });
  }
});

Посмотрев на соотношение навигации back_forward к back_forward_cache , можно рассчитать соотношение bfcache.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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