Cache de avanço e retorno

Otimize suas páginas para carregamentos instantâneos ao usar os botões "Voltar" e "Avançar" do navegador.

Philip Walton

Barry Pollard

O cache de avanço e retorno (ou bfcache) é uma otimização de navegador que permite a navegação instantânea para frente e para trás. Isso melhora significativamente a experiência de navegação dos usuários, especialmente aqueles com redes ou dispositivos mais lentos.

Como desenvolvedor da Web, é fundamental entender como otimizar suas páginas para o bfcache em todos os navegadores para que os usuários possam aproveitar os benefícios.

Compatibilidade com navegadores

O bfcache é compatível com o Firefox e o Safari há muitos anos, em computadores e dispositivos móveis.

A partir da versão 86, o Chrome ativou o bfcache para navegações entre sites no Android para uma pequena porcentagem de usuários. Nas versões subsequentes, o suporte adicional será lançado lentamente. Desde a versão 96, o bfcache está ativado para todos os usuários do Chrome em computadores e dispositivos móveis.

Noções básicas do bfcache

O bfcache é um cache na memória que armazena um snapshot completo de uma página (incluindo o heap JavaScript) conforme o usuário sai da página. Com a página inteira na memória, o navegador poderá restaurá-la de maneira rápida e fácil se o usuário decidir voltar.

Quantas vezes você visitou um site e clicou em um link para ir para outra página, mas percebeu que não era o que queria e clicou no botão "Voltar"? Nesse momento, o bfcache pode fazer uma grande diferença na velocidade de carregamento da página anterior:

Confira este vídeo do bfcache em ação para entender a velocidade que ele pode trazer às navegações:

No vídeo acima, o exemplo com bfcache é um pouco mais rápido do que o exemplo sem ele.

O bfcache não apenas acelera a navegação, mas também reduz o uso de dados, já que os recursos não precisam ser transferidos por download novamente.

Os dados de uso do Chrome mostram que 1 em 10 navegações no computador e 1 em cada 5 em dispositivos móveis são de avanço e retorno. Com o bfcache ativado, os navegadores podem eliminar a transferência de dados e o tempo gasto no carregamento de bilhões de páginas da Web todos os dias.

Como funciona o "cache"

O "cache" usado pelo bfcache é diferente do cache HTTP, que também é útil para acelerar navegações repetidas. O bfcache é um resumo de toda a página na memória (incluindo o heap JavaScript), enquanto o cache HTTP contém apenas as respostas de solicitações feitas anteriormente. Como é raro que todas as solicitações necessárias para carregar uma página possam ser atendidas do cache HTTP, visitas repetidas usando restaurações bfcache são sempre mais rápidas do que até mesmo as navegações sem uso de bfcache mais bem otimizadas.

No entanto, criar um snapshot de uma página na memória envolve certa complexidade em relação à melhor forma de preservar o código em andamento. Por exemplo, como você lida com chamadas setTimeout() em que o tempo limite é atingido enquanto a página está no bfcache?

A resposta é que os navegadores pausam a execução de timers pendentes ou promessas não resolvidas (basicamente, todas as tarefas pendentes nas filas de tarefas JavaScript) e retomam as tarefas de processamento quando (ou se) a página é restaurada do bfcache.

Em alguns casos, isso é relativamente baixo (por exemplo, tempos limite ou promessas), mas em outros, pode levar a um comportamento muito confuso ou inesperado. Por exemplo, se o navegador pausar uma tarefa necessária como parte de uma transação do IndexedDB, isso poderá afetar outras guias abertas na mesma origem, já que os mesmos bancos de dados IndexedDB podem ser acessados por várias guias simultaneamente. Como resultado, os navegadores geralmente não tentam armazenar páginas em cache no meio de uma transação do IndexedDB ou usar APIs que possam afetar outras páginas.

Para ver mais detalhes sobre como o uso da API afeta a qualificação para o bfcache de uma página, consulte Otimizar suas páginas para o bfcache abaixo.

O bfcache e os apps de página única (SPA)

O bfcache funciona com navegações gerenciadas pelo navegador. Portanto, ele não funciona com as chamadas "navegações suaves" dentro de um SPA, mas um dos principais argumentos de venda de um SPA é que esses tipos de navegação devem ser rápidos de qualquer maneira. No entanto, o bfcache pode definitivamente ajudar ao voltar a um SPA, em vez de fazer uma reinicialização completa desse app novamente desde o início.

APIs para observar o bfcache

Embora o bfcache seja uma otimização automática feita pelos navegadores, ainda é importante que os desenvolvedores saibam quando isso está acontecendo para que possam otimizar as páginas e ajustar métricas ou medição de desempenho adequadamente.

Os principais eventos usados para observar o bfcache são os eventos de transição de página (pageshow e pagehide), que existem desde que o bfcache tem e são compatíveis com praticamente todos os navegadores em uso atualmente.

Os eventos mais recentes do ciclo de vida da página (freeze e resume) também são enviados quando as páginas entram ou saem do bfcache, bem como em algumas outras situações. Por exemplo, quando uma guia em segundo plano é congelada para minimizar o uso da CPU. No momento, os eventos de ciclo de vida da página têm suporte apenas em navegadores baseados no Chromium.

Observar quando uma página é restaurada do bfcache

O evento pageshow é disparado logo após o load quando a página está sendo carregada pela primeira vez e sempre que ela é restaurada do bfcache. O evento pageshow tem uma propriedade persisted que será true se a página tiver sido restaurada do bfcache (e false em caso negativo). É possível usar a propriedade persisted para diferenciar os carregamentos de página regulares das restaurações do bfcache. Exemplo:

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

Em navegadores compatíveis com a API Page Lifecycle, o evento resume também é acionado quando as páginas são restauradas do bfcache (imediatamente antes do evento pageshow), embora também seja disparado quando um usuário acessar novamente uma guia em segundo plano congelada. Se você quiser atualizar o estado de uma página depois que ela for congelada (o que inclui páginas no bfcache), poderá usar o evento resume. No entanto, se quiser medir a taxa de ocorrências do bfcache do site, use o evento pageshow. Em alguns casos, pode ser necessário usar ambos.

Observar quando uma página está entrando no bfcache

O evento pagehide é a contraparte do evento pageshow. O evento pageshow é disparado quando uma página é carregada normalmente ou restaurada do bfcache. O evento pagehide é disparado quando a página é descarregada normalmente ou quando o navegador tenta colocá-la no bfcache.

O evento pagehide também tem uma propriedade persisted e, se for false, uma página não vai entrar no bfcache. No entanto, se a propriedade persisted for true, isso não garante que uma página será armazenada em cache. Isso significa que o navegador intends armazenar a página em cache, mas pode haver fatores que impossibilitam o armazenamento em cache.

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.');
  }
});

Da mesma forma, o evento freeze será disparado imediatamente após o evento pagehide (se a propriedade persisted do evento for true), mas novamente isso significa apenas que o navegador intends armazenar a página em cache. Talvez seja necessário descartá-lo por várias razões explicadas abaixo.

Otimizar suas páginas para o bfcache

Nem todas as páginas são armazenadas no bfcache e, mesmo quando uma página é armazenada lá, ela não fica lá indefinidamente. É fundamental que os desenvolvedores entendam o que torna as páginas qualificadas (e não qualificadas) para o bfcache a fim de maximizar as taxas de ocorrência em cache.

As seções abaixo descrevem as práticas recomendadas para que o navegador possa armazenar as páginas em cache.

Nunca usar o evento unload

A maneira mais importante de otimizar para o bfcache em todos os navegadores é nunca usar o evento unload. Sempre!

O evento unload é problemático para navegadores porque antecede o bfcache e muitas páginas na Internet operam com o pressuposto (razoável) de que uma página não continuará existindo depois que o evento unload for disparado. Isso apresenta um desafio, porque muitas dessas páginas também foram criadas com o pressuposto de que o evento unload seria disparado sempre que um usuário estivesse navegando, o que não é mais verdade (e não é verdade há muito tempo).

Os navegadores enfrentam um dilema: precisam escolher entre algo que possa melhorar a experiência do usuário, mas também pode arriscar quebrar a página.

No computador, o Chrome e o Firefox optaram por tornar as páginas desqualificadas para o bfcache se adicionarem um listener unload, o que é menos arriscado, mas também desqualifica muitas páginas. O Safari vai tentar armazenar em cache algumas páginas com um listener de eventos unload. No entanto, para reduzir possíveis falhas, ele não executará o evento unload quando um usuário estiver navegando para longe, o que torna o evento muito não confiável.

Em dispositivos móveis, o Chrome e o Safari vão tentar armazenar páginas em cache com um listener de eventos unload, já que o risco de falha é menor porque o evento unload sempre foi extremamente não confiável nesses dispositivos. O Firefox trata as páginas que usam unload como não qualificadas para o bfcache, exceto no iOS, que exige que todos os navegadores usem o mecanismo de renderização WebKit. Assim, ele se comporta como o Safari.

Em vez de usar o evento unload, use o evento pagehide. O evento pagehide é acionado em todos os casos em que o evento unload é acionado no momento e também é acionado quando uma página é colocada no bfcache.

Na verdade, o Lighthouse tem uma auditoria no-unload-listeners que avisa os desenvolvedores se algum JavaScript nas páginas deles (incluindo o de bibliotecas de terceiros) adicionar um listener de eventos unload.

Devido à falta de confiabilidade e ao impacto no desempenho do bfcache, o Chrome está tentando descontinuar o evento unload.

Usar a política de permissão para evitar que gerenciadores de descarregamento sejam usados em uma página

Os sites que não usam manipuladores de eventos unload podem garantir que eles não sejam adicionados usando uma política de permissões do Chrome 115.

Permission-Policy: unload()

Isso evita que terceiros ou extensões deixem o site lento adicionando gerenciadores de descarregamento e impedindo o uso do bfcache.

Adicione apenas listeners beforeunload condicionalmente

O evento beforeunload não desqualifica suas páginas para o uso de bfcache em navegadores modernos (bfcache), mas isso ainda não é confiável. Portanto, evite usá-lo, a menos que seja absolutamente necessário.

No entanto, ao contrário do evento unload, há usos legítimos para beforeunload. Por exemplo, quando você quiser avisar ao usuário que ele tem alterações não salvas, ele vai perder se sair da página. Nesse caso, recomendamos que você só adicione listeners beforeunload quando um usuário tiver mudanças não salvas e os remova imediatamente depois que as mudanças não forem salvas.

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);
});

Minimizar o uso de Cache-Control: no-store

Cache-Control: no-store é um servidor da Web de cabeçalho HTTP que pode ser definido em respostas que instrui o navegador a não armazenar a resposta em nenhum cache HTTP. Isso deve ser usado em recursos com informações sensíveis do usuário, como páginas protegidas por login.

Embora o bfcache não seja um cache HTTP, historicamente, quando Cache-Control: no-store é definido no próprio recurso da página (ao contrário de qualquer sub-recurso), os navegadores optam por não armazenar a página no bfcache. Estamos trabalhando para mudar esse comportamento do Chrome a fim de preservar a privacidade, mas, no momento, as páginas que usam Cache-Control: no-store não estão qualificadas para o bfcache.

Como o Cache-Control: no-store restringe a qualificação de uma página para o bfcache, ele só precisa ser definido em páginas que contêm informações sensíveis, em que o armazenamento em cache nunca é apropriado.

Para páginas que querem sempre veicular conteúdo atualizado e que o conteúdo não apresenta informações confidenciais, use Cache-Control: no-cache ou Cache-Control: max-age=0. Essas diretivas instruem o navegador a revalidar o conteúdo antes da veiculação e não afetam a qualificação para o bfcache de uma página.

Quando uma página é restaurada do bfcache, ela é restaurada na memória, não no cache de HTTP. Como resultado, diretivas como Cache-Control: no-cache ou Cache-Control: max-age=0 não são consideradas, e não ocorre revalidação antes que o conteúdo seja exibido ao usuário.

Essa ainda é, provavelmente, uma melhor experiência do usuário, já que as restaurações do bfcache são instantâneas e, como as páginas não permanecem no bfcache por muito tempo, é improvável que o conteúdo esteja desatualizado. No entanto, se o conteúdo mudar minuto a minuto, você poderá buscar as atualizações usando o evento pageshow, conforme descrito na próxima seção.

Atualizar dados desatualizados ou confidenciais após a restauração do bfcache

Se o site mantiver o estado do usuário, especialmente informações confidenciais dele, esses dados precisarão ser atualizados ou apagados depois que uma página for restaurada do bfcache.

Por exemplo, se um usuário acessar uma página de finalização da compra e atualizar o carrinho de compras, uma navegação de retorno poderá expor informações desatualizadas se uma página desatualizada for restaurada do bfcache.

Outro exemplo mais importante é quando um usuário sai de um site em um computador público e o próximo usuário clica no botão "Voltar". Isso pode expor dados particulares que o usuário supõe que foram apagados ao sair.

Para evitar situações como essa, é bom sempre atualizar a página após um evento pageshow se event.persisted for true:

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

Embora o ideal seja atualizar o conteúdo no local, você pode forçar uma atualização completa para algumas alterações. O código a seguir verifica se há um cookie específico do site no evento pageshow e atualiza se o cookie não for encontrado:

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

A vantagem de uma atualização é preservar o histórico (para permitir navegações futuras), mas um redirecionamento pode ser mais apropriado em alguns casos.

Restauração de anúncios e bfcache

Pode ser tentador tentar evitar o uso do bfcache para exibir um novo conjunto de anúncios em cada navegação de avanço e retorno. No entanto, além de ter um impacto na performance, é questionável se esse comportamento gera um melhor engajamento com o anúncio. Os usuários podem ter notado um anúncio que pretendiam retornar ao clicar, mas ao recarregar, em vez de restaurar do bfcache, eles não conseguiram. Testar esse cenário (de preferência com um teste A/B) é importante antes de fazer suposições.

Para sites que querem atualizar os anúncios na restauração do bfcache, atualizar apenas os anúncios no evento pageshow quando event.persisted for true permite que isso aconteça sem afetar a performance da página. Consulte seu provedor de anúncios, mas confira um exemplo de como fazer isso com a Tag do Google Publishing.

Evitar referências window.opener

Em navegadores mais antigos, se uma página tiver sido aberta usando window.open() de um link com target=_blank, sem especificar rel="noopener", a página de abertura terá uma referência ao objeto da janela da página aberta.

Além de ser um risco de segurança, uma página com uma referência window.opener não nula não pode ser colocada com segurança no bfcache, porque isso pode interromper qualquer página que tente acessá-la.

Por isso, é recomendável evitar a criação de referências window.opener. Para fazer isso, use rel="noopener" sempre que possível. Observação: agora esse é o padrão em todos os navegadores mais recentes. Caso seu site exija a abertura de uma janela e o controle usando window.postMessage() ou a referência direta ao objeto da janela, nem a janela nem o abridor estão qualificados para o bfcache.

Sempre feche conexões abertas antes que o usuário saia

Como mencionado acima, quando uma página é colocada no bfcache, todas as tarefas JavaScript programadas são pausadas e retomadas quando a página é retirada do cache.

Se essas tarefas JavaScript programadas só acessam APIs do DOM (ou outras APIs isoladas apenas à página atual), pausar essas tarefas enquanto a página não está visível para o usuário não causa problemas.

No entanto, se essas tarefas estiverem conectadas a APIs que também podem ser acessadas por outras páginas na mesma origem (por exemplo: IndexedDB, Web Locks, WebSockets etc.), isso poderá ser um problema, porque pausar essas tarefas pode impedir a execução do código em outras guias.

Como resultado, alguns navegadores não tentarão colocar uma página em bfcache nos seguintes cenários:

• Páginas com uma conexão do IndexedDB aberta
• Páginas com fetch() ou XMLHttpRequest em andamento
• Páginas com uma conexão WebSocket ou WebRTC aberta

Caso sua página use uma dessas APIs, é recomendável sempre fechar as conexões e remover ou desconectar os observadores durante o evento pagehide ou freeze. Isso permite que o navegador armazene a página em cache com segurança sem o risco de afetar outras guias abertas.

Em seguida, se a página for restaurada do bfcache, será possível reabrir ou se reconectar a essas APIs (no evento pageshow ou resume).

O exemplo a seguir mostra como garantir que suas páginas estejam qualificadas para o uso do bfcache ao usar o IndexedDB fechando uma conexão aberta no listener de eventos 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());

Testar para garantir que suas páginas podem ser armazenadas em cache

O Chrome DevTools pode ajudar você a testar suas páginas para garantir que elas estejam otimizadas para o bfcache e identificar problemas que podem estar impedindo que elas sejam qualificadas.

Para testar uma página específica, acesse-a no Chrome e, no DevTools, acesse Aplicativo > Cache de avanço e retorno. Em seguida, clique no botão Run Test e o DevTools tentará sair e voltar para determinar se a página pode ser restaurada do bfcache.

Se funcionar, o painel vai exibir a mensagem "Restaurado do cache de avanço e retorno":

Caso contrário, o painel vai indicar que a página não foi restaurada e listar o motivo.

Se o motivo for algo que você, como desenvolvedor, possa resolver, isso também será indicado:

Na captura de tela acima, o uso de um listener de eventos unload está impedindo que a página seja qualificada para o bfcache. Para corrigir isso, mude de unload para pagehide:

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

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

O Lighthouse 10.0 também adicionou uma auditoria bfcache, que executa um teste semelhante ao do DevTools e fornece motivos por que a página não está qualificada se a auditoria falhar. Consulte os documentos de auditoria do bfcache para mais informações.

Como o bfcache afeta a medição de análise e desempenho

Se você rastrear as visitas ao seu site com uma ferramenta de análise, provavelmente notará uma diminuição no número total de visualizações de página informadas enquanto o Chrome continua ativando o bfcache para mais usuários.

Na verdade, é provável que você já esteja abaixo do relatório de visualizações de página de outros navegadores que implementam o bfcache, já que a maioria das bibliotecas de análise conhecidas não rastreia restaurações do bfcache como novas visualizações de página.

Se você não quiser que as contagens de visualizações de página diminuam porque o Chrome ativou o bfcache, informe as restaurações do bfcache como visualizações de página (recomendado) detectando o evento pageshow e verificando a propriedade persisted.

O exemplo a seguir mostra como fazer isso com o Google Analytics. A lógica deve ser semelhante para outras ferramentas de análise:

// 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');
  }
});

Como medir a proporção de ocorrência do bfcache

Você também pode acompanhar se o bfcache foi usado para ajudar a identificar páginas que não estão utilizando o bfcache. Isso pode ser feito medindo o tipo de navegação para carregamentos de página:

// 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';
    });
  }
});

Analisando a proporção de navegações de back_forward para back_forward_cache, é possível calcular a proporção de bfcache.

É importante ter em mente que há vários cenários fora do controle dos proprietários do site em que a navegação de retorno/avançar não usa o bfcache, incluindo:

• quando o usuário fecha o navegador e o inicia novamente.
• quando o usuário duplica uma guia.
• quando o usuário fecha uma guia e a abre.

Em alguns casos, o tipo de navegação original pode ser preservado por alguns navegadores e, portanto, pode mostrar um tipo back_forward, apesar de não serem navegações de avanço e retorno.

Mesmo sem essas exclusões, o bfcache será descartado após um período para economizar memória.

Portanto, os proprietários de sites não podem esperar uma proporção de hits de bfcache de 100% para todas as navegações de back_forward. No entanto, medir a proporção pode ser útil para identificar as páginas em que a própria página está impedindo o uso do bfcache em uma alta proporção de navegações de ida e volta.

A equipe do Chrome está trabalhando em uma API NotRestoredReasons para ajudar a expor os motivos pelos quais o bfcache não foi usado, para ajudar os desenvolvedores a entender por que o cache não foi usado e se é possível trabalhar nisso para melhorar os sites.

Medição da performance

O bfcache também pode afetar negativamente as métricas de desempenho coletadas no campo, especificamente as que medem os tempos de carregamento da página.

Como as navegações bfcache restauram uma página atual em vez de iniciar um novo carregamento, o número total de carregamentos de página coletados vai diminuir quando o bfcache estiver ativado. No entanto, o importante é que os carregamentos de página que estão sendo substituídos pelas restaurações do bfcache provavelmente foram alguns dos carregamentos de página mais rápidos do seu conjunto de dados. Isso ocorre porque as navegações de avanço e retorno, por definição, são visitas repetidas, e os carregamentos de página repetidos geralmente são mais rápidos do que os carregamentos de página de visitantes novos (devido ao armazenamento em cache HTTP, como mencionado anteriormente).

O resultado é menos carregamentos de página rápidos no conjunto de dados, o que provavelmente distorce a distribuição mais lentamente, apesar de o desempenho ter melhorado no usuário.

Há algumas maneiras de lidar com esse problema. Uma delas é anotar todas as métricas de carregamento de página com o respectivo tipo de navegação: navigate, reload, back_forward ou prerender. Isso permite que você continue monitorando o desempenho nesses tipos de navegação, mesmo que a distribuição geral tenha uma distorção negativa. Essa abordagem é recomendada para métricas de carregamento de página não centradas no usuário, como Tempo até o primeiro byte (TTFB, na sigla em inglês).

Para métricas centradas no usuário, como as Core Web Vitals, a melhor opção é informar um valor que represente com mais precisão a experiência do usuário.

Impacto nas Core Web Vitals

As Core Web Vitals medem a experiência do usuário em uma página da Web em várias dimensões (velocidade de carregamento, interatividade, estabilidade visual). Como os usuários experimentam restaurações do bfcache como navegações mais rápidas do que os carregamentos de página tradicionais, é importante que as métricas das Core Web Vitals reflitam isso. Afinal, um usuário não se importa se o bfcache está ativado ou não, ele só se importa que a navegação foi rápida.

Ferramentas como o Chrome User Experience Relatório, que coletam e informam sobre as Core Web Vitals tratam as restaurações do bfcache como visitas separadas à página no conjunto de dados.

Embora ainda não existam APIs de desempenho da Web dedicadas para medir essas métricas após restaurações do bfcache, os valores podem ser aproximados usando APIs da Web atuais.

• Para a Maior exibição de conteúdo (LCP, na sigla em inglês), é possível usar o delta entre o carimbo de data/hora do evento pageshow e o do próximo frame pintado, já que todos os elementos no frame serão pintados ao mesmo tempo. No caso de uma restauração bfcache, a LCP e a FCP serão as mesmas.
• Para Latência na primeira entrada (FID, na sigla em inglês), é possível adicionar novamente os listeners de eventos (os mesmos usados pelo polyfill FID) no evento pageshow e informar o FID como o atraso da primeira entrada após a restauração do bfcache.
• Para a Mudança de layout cumulativa (CLS), você pode continuar usando o Performance Observer atual. Basta redefinir o valor atual de CLS para 0.

Para saber mais sobre como o bfcache afeta cada métrica, consulte as páginas de guias de métricas das Core Web Vitals. Para um exemplo específico de como implementar versões do bfcache dessas métricas no código, consulte PR como adicioná-las à biblioteca JS da web-vitals.

Outros recursos

• Armazenamento em cache do Firefox (bfcache no Firefox)
• Cache da página (bfcache no Safari)
• Cache de avanço e retorno: comportamento exposto na Web (diferenças de bfcache nos navegadores)
• Testador de bfcache (teste como diferentes APIs e eventos afetam o bfcache nos navegadores)
• Performance Game Changer: cache de avanço e retorno do navegador (um estudo de caso da Smashing Magazine que mostra melhorias drásticas nas Core Web Vitals com a ativação do bfcache)