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

Philip Walton

Barry Pollard

Опубликовано: 25 мая 2023 г., Последнее обновление: 25 марта 2025 г.

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

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

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

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

основы bfcache

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

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

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

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

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

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

Как работает "кэш"

The "cache" used by bfcache is different from the HTTP cache , which plays its own role in speeding up repeat navigations. bfcache is a snapshot of the entire page in memory, including the JavaScript heap, whereas the HTTP cache contains only the responses for previously made requests. Since it's very rare for all requests required to load a page to be fulfilled from the HTTP cache, repeat visits using bfcache restores are always faster than even the most well-optimized non-bfcache navigations.

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

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

In some cases, such as for timeouts and promises, this is fairly low risk, but in other cases it can lead to confusing or unexpected behavior. For example, if the browser pauses a task that's required as part of an IndexedDB transaction , it can affect other open tabs in the same origin, because the same IndexedDB databases can be accessed by multiple tabs simultaneously. As a result, browsers will generally not attempt to cache pages in the middle of an IndexedDB transaction or while using APIs that might affect other pages.

Для получения более подробной информации о том, как использование различных 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.');
  }
});

In browsers that support the Page Lifecycle API, the resume event fires when pages are restored from bfcache (immediately before the pageshow event) and when a user revisits a frozen background tab. If you want to update a page's state after it's frozen (which includes pages in the bfcache), you can use the resume event, but if you want to measure your site's bfcache hit rate, you'd need to use the pageshow event. In some cases, you might need to use both.

Подробную информацию о лучших практиках измерения производительности с помощью 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 . Никогда!

The unload event is problematic for browsers because it predates bfcache and many pages on the internet operate under the (reasonable) assumption that a page won't continue to exist after the unload event has fired. This presents a challenge because many of those pages were also built with the assumption that the unload event would fire any time a user is navigating away, which is no longer true (and hasn't been true for a long time ).

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

В настольных версиях 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

It may be tempting to try to avoid the use of bfcache to serve a new set of ads on each back/forward navigation. However, as well as having a performance impact, it is questionable whether such behavior leads to better ad engagement. Users may have noticed an ad they intended to return to click but by reloading rather than restoring from the bfcache they not be able to. Testing this scenario—ideally with an A/B test—is important before making assumptions.

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

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

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

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

As a result, it's best to avoid creating window.opener references. You can do this by using rel="noopener" whenever possible (note, this is now the default in all modern browsers). If your site requires opening a window and controlling it through window.postMessage() or directly referencing the window object, neither the opened window nor the opener will be eligible for the 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.
// This happens by default just by loading gtag
gtag('config', 'TAG_ID');

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.
// To do this disable the default pageview so you can manually send it
// supplemented with the additional detail.
gtag('config', 'TAG_ID', { send_page_view: false });
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 также может негативно влиять на показатели производительности, собираемые в полевых условиях , в частности, на показатели, измеряющие время загрузки страниц.

Since bfcache navigations restore an existing page rather than initiate a new page load, the total number of page loads collected will decrease when bfcache is enabled. What's critical, though, is that the page loads being replaced by bfcache restores would likely have been some of the fastest page loads in your dataset. This is because back and forward navigations, by definition, are repeat visits, and repeat page loads are generally faster than page loads from first time visitors (due to HTTP caching , as mentioned earlier).

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

There are a few ways to deal with this issue. One is to annotate all page load metrics with their respective navigation type : navigate , reload , back_forward , or prerender . This lets you continue to monitor your performance within these navigation types, even if the overall distribution skews negative. We recommend this approach for non-user-centric page load metrics like Time to First Byte (TTFB) .

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

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

Core Web Vitals measure the user's experience of a web page across a variety of dimensions (loading speed, interactivity, visual stability), and since users experience bfcache restores as faster navigations than full page loads, it's important that the Core Web Vitals metrics reflect this. After all, a user doesn't care whether or not bfcache was enabled, they just care that the navigation was fast!

Инструменты, которые собирают и предоставляют отчеты по метрикам 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).