Cache de avanço e retorno

Philip Walton

Barry Pollard

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

Como desenvolvedores Web, é fundamental entender como otimizar suas páginas para o bfcache, para que seus usuários possam aproveitar os benefícios.

Compatibilidade com navegadores

Há muitos anos, o bfcache é compatível com o Firefox e o Safari 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 foi 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.

Princípios básicos do bfcache

O bfcache é um cache na memória que armazena um instantâneo completo de uma página (incluindo a heap JavaScript) à medida que o usuário sai da página. Com a página inteira na memória, o navegador pode restaurá-la rapidamente se o usuário decidir voltar.

Quantas vezes você acessou um site e clicou em um link para ir a outra página, mas depois percebeu que não era o que você 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 para as navegações:

No vídeo, o exemplo com o 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 não é necessário fazer o download de recursos novamente.

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

Como o cache obras

O "cache" usado pelo bfcache é diferente do cache HTTP, que desempenha o próprio papel de acelerar navegações repetidas. O bfcache é um instantâneo de toda a página na memória, incluindo a pilha JavaScript, enquanto o cache HTTP contém somente as respostas de solicitações feitas anteriormente. Como é muito raro que todas as solicitações necessárias para carregar uma página sejam atendidas a partir do cache HTTP, visitas repetidas com restaurações do bfcache são sempre mais rápidas do que mesmo as navegações fora do bfcache mais bem otimizadas.

No entanto, criar um instantâneo de uma página na memória envolve alguma complexidade em termos de como melhor preservar o código em andamento. Por exemplo, como lidar com chamadas setTimeout() em que o tempo limite é atingido enquanto a página está no bfcache?

A resposta é que os navegadores pausam todos os timers ou promessas não resolvidas de páginas no bfcache, incluindo quase todas as tarefas pendentes nas filas de tarefas JavaScript, e retomam as tarefas de processamento se a página for restaurada do bfcache.

Em alguns casos, como para tempos limite e promessas, isso apresenta um risco razoavelmente baixo, mas em outros casos pode levar a um comportamento confuso ou inesperado. Por exemplo, se o navegador pausar uma tarefa necessária como parte de um IndexedDB transação, isso pode afetar outras guias abertas na mesma origem, porque os mesmos bancos de dados do 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 enquanto usam APIs que podem afetar outras páginas.

Para mais detalhes sobre como vários usos da API afetam a qualificação para o bfcache de uma página, consulte Otimizar suas páginas para o bfcache.

O bfcache e os iframes

Se uma página tiver iframes incorporados, os próprios iframes não serão elegíveis para o bfcache. Por exemplo, se você navegar para outra página dentro de um iframe e depois voltar, o navegador "voltar" no iframe em vez de no frame principal, mas a navegação de retorno no iframe não usará o bfcache.

O frame principal também pode ser impedido de usar o bfcache se um iframe incorporado usar APIs que impeçam isso. A Política de permissões definida no frame principal ou o uso de atributos sandbox podem ser usados para evitar isso.

O bfcache e os apps de página única (SPA, na sigla em inglês)

Como o bfcache funciona com navegações gerenciadas pelo navegador, ele não funciona com "navegação simples" em um app de página única (SPA). No entanto, o bfcache ainda pode ajudar ao voltar a um SPA em vez de fazer uma reinicialização completa desse aplicativo novamente desde o início.

APIs para observar o bfcache

Embora o bfcache seja uma otimização que os navegadores fazem automaticamente, ainda é importante que os desenvolvedores saibam quando isso está acontecendo para que possam otimizar as páginas para isso e ajustar as métricas ou métricas 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 são compatíveis com a maioria dos navegadores.

Os eventos mais recentes de ciclo de vida da página (freeze e resume) também são enviados quando as páginas entram ou saem do bfcache e em algumas outras situações, por exemplo, quando uma guia em segundo plano é congelada para minimizar o uso da CPU. Estes eventos só são compatíveis com navegadores baseados no Chromium.

Observar quando uma página é restaurada do bfcache

O evento pageshow é disparado logo após o evento load quando a página está sendo carregada inicialmente e sempre que a página é restaurada do bfcache. O evento pageshow tem uma propriedade persisted, que será true se a página tiver sido restaurada do bfcache e false, caso contrário. É possível usar a propriedade persisted para diferenciar os carregamentos de página normais 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 é acionado quando as páginas são restauradas do bfcache (logo antes do evento pageshow) e quando um usuário revisita uma guia congelada em segundo plano. Se você quiser atualizar o estado de uma página depois que ela for congelada (o que inclui páginas no bfcache), use o evento resume. No entanto, se quiser medir a taxa de hits do bfcache do seu site, será necessário usar o evento pageshow. Em alguns casos, pode ser necessário usar ambos.

Para detalhes sobre as práticas recomendadas de medição do bfcache, consulte Como o bfcache afeta a análise e a medição de desempenho.

Observar quando uma página está entrando no bfcache

O evento pagehide é disparado quando uma página é descarregada ou quando o navegador tenta colocá-la no bfcache.

O evento pagehide também tem uma propriedade persisted. Se for false, você terá certeza de que a página não entrará no bfcache. No entanto, o fato de persisted ser true não garante que a página será armazenada em cache. Isso significa que o navegador pretende armazenar a página em cache, mas pode haver outros 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 é disparado imediatamente após o evento pagehide se persisted for true, mas isso significa apenas que o navegador quer armazenar a página em cache. Ele ainda pode ter que descartá-lo por vários motivos explicados mais adiante.

Otimizar suas páginas para o bfcache

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

As seções a seguir descrevem as práticas recomendadas para aumentar a probabilidade de o navegador armazenar suas 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. Nunca!

O evento unload é problemático para navegadores porque ele é anterior ao bfcache e muitas páginas na Internet operam sob a suposição (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 saindo, o que não é mais verdade (e não é verdade há muito tempo).

Portanto, os navegadores enfrentam um dilema: eles precisam escolher entre algo que pode melhorar a experiência do usuário, mas que também podem correr o risco de corromper a página.

No computador, o Chrome e o Firefox optaram por não qualificar as páginas para o bfcache se adicionarem um listener unload, o que é menos arriscado, mas também desqualifica muitas páginas. O Safari tentará armazenar algumas páginas em cache 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, o que torna o evento muito não confiável.

Em dispositivos móveis, o Chrome e o Safari tentarão armazenar páginas em cache com um listener de eventos unload, já que o risco de falhas é menor devido ao fato de que o evento unload sempre foi extremamente não confiável em dispositivos móveis. 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. Por isso, ele se comporta como o Safari.

Em vez de usar o evento unload, use pagehide. O evento pagehide é disparado em todos os casos em que o evento unload é disparado e também 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 (inclusive de bibliotecas de terceiros) adicionar um listener de evento unload.

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

Usar a política de permissão para impedir 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.

Permission-Policy: unload=()

Isso também impede que terceiros ou extensões deixem o site lento adicionando gerenciadores de descarregamento e tornando o site inelegível para o bfcache.

Só adicionar listeners beforeunload condicionalmente

O evento beforeunload não desqualificará suas páginas para o bfcache em navegadores modernos, mas já funcionava e ainda não é confiável. Portanto, evite usá-lo, a menos que seja absolutamente necessário.

Ao contrário do evento unload, no entanto, há usos legítimos para beforeunload. Por exemplo, quando você quiser avisar o usuário que ele alterações não salvas, que serão perdidas se ele sair da página. Nesse caso, recomendado que você só adicione listeners beforeunload quando um usuário tiver dados não salvos alterações e removê-las imediatamente após salvar as alterações não 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 cabeçalho HTTP que os servidores da Web podem definir em respostas que instrui o navegador a não armazenar a resposta em nenhum cache HTTP. Ela é usada para recursos que contêm informações sensíveis do usuário, como páginas protegidas por login.

Embora o bfcache não seja um cache HTTP, quando o Cache-Control: no-store é definido no próprio recurso da página (em oposição a qualquer sub-recurso), os navegadores optam por não armazenar a página no bfcache. Ainda há trabalhos em andamento para mudar esse comportamento no Chrome de modo a 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ó deve ser definido em páginas com informações sensíveis, em que o armazenamento em cache de qualquer tipo nunca é apropriado.

Para páginas que precisam sempre exibir conteúdo atualizado e que o conteúdo não contém 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 de veiculá-lo e não afetam a qualificação do bfcache de uma página.

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

No entanto, essa provavelmente ainda é uma melhor experiência para o 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 a cada minuto, busque as atualizações usando o evento pageshow, conforme descrito na próxima seção.

Atualizar dados sensíveis ou desatualizados após a restauração do bfcache

Caso seu site mantenha o estado do usuário, especialmente informações confidenciais, 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 crítico é se um usuário sair de um site em um computador público e o próximo usuário clicar no botão "Voltar". Isso pode expor dados particulares que o usuário presumiu que foram apagados quando saiu.

Para evitar situações como essa, é recomendável 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
  }
});

O ideal é atualizar o conteúdo no lugar certo, mas para algumas mudanças pode ser necessário forçar uma recarga completa. O código a seguir verifica a presença de 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 atualização tem a vantagem de 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 veicular um novo conjunto de anúncios em cada navegação de retorno/avanço. No entanto, além de afetar a performance, não é possível confirmar se esse comportamento melhora o engajamento com o anúncio. Os usuários podem ter notado um anúncio no qual pretendiam voltar e clicar, mas recarregando, em vez de restaurar do bfcache, não conseguem. É importante testar esse cenário (de preferência com um teste A/B) 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 é true permite que isso aconteça sem afetar a performance da página. Consulte seu provedor de anúncios, mas confira este exemplo de como fazer isso com a tag do Google Publishing.

Evitar referências a window.opener

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

Além de ser um risco à 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 corromper todas as páginas que tentam acessá-la.

Como resultado, é melhor evitar criar referências window.opener. Você pode fazer isso usando rel="noopener" sempre que possível. Observação: agora esse é o padrão em todos os navegadores mais recentes. Se o site exigir a abertura de uma janela e controlá-la por window.postMessage() ou referência direta ao objeto de janela, nem a janela aberta nem a pessoa de abertura serão qualificadas para o bfcache.

Feche as conexões abertas antes que o usuário saia da página

Como mencionado anteriormente, quando uma página é colocada no bfcache, ele pausa todas as tarefas JavaScript programadas e as retoma quando a página é retirada do cache.

Se essas tarefas JavaScript programadas acessarem apenas APIs DOM ou outras APIs isoladas somente à página atual, pausar essas tarefas enquanto a página não está visível para o usuário não causará 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), isso poderá ser um problema, porque pausar essas tarefas pode impedir que o código em outras guias seja executado.

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

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

Se sua página usar uma dessas APIs, recomendamos fechar as conexões e remover ou desconectar 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 durante o evento pageshow ou resume.

O exemplo a seguir mostra como garantir que as páginas que usam o IndexedDB sejam qualificadas para o bfcache 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 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());

Faça um teste para garantir que suas páginas possam 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 possam impedir a qualificação delas.

Para testar uma página:

1. Acesse a página no Chrome.
2. No DevTools, acesse Aplicativo -> Cache de avanço e retorno.
3. Clique no botão Run Test. O DevTools então tenta navegar para fora e voltar para determinar se a página pode ser restaurada do bfcache.

Se o teste for bem-sucedido, o painel vai exibir a mensagem "Restaurado do cache de avanço e retorno".

Se ela não for bem-sucedida, o painel vai indicar o motivo. Se o motivo for algo que você possa resolver como desenvolvedor, o painel o marcará como Acionável.

Neste exemplo, o uso de um listener de eventos unload torna a página não qualificada para o bfcache. Para corrigir isso, mude de unload para pagehide:

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

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

O Lighthouse 10.0 também adicionou uma auditoria do bfcache (link em inglês), que realiza um teste semelhante. Para mais informações, consulte os documentos da auditoria do bfcache.

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

Se você usa uma ferramenta de análise para medir as visitas ao seu site, talvez note uma diminuição no número total de visualizações de página registradas porque o Chrome ativa o bfcache para mais usuários.

Na verdade, você provavelmente já está informando menos visualizações de página de outros navegadores que implementam o bfcache, porque muitas bibliotecas conhecidas de análise não medem as restaurações do bfcache como novas visualizações de página.

Para incluir restaurações do bfcache na sua contagem de visualizações de página, defina listeners para o evento pageshow e verifique a propriedade persisted.

O exemplo a seguir mostra como fazer isso com o Google Analytics. Outras ferramentas de análise provavelmente usam uma lógica semelhante:

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

Medir a proporção de ocorrências do bfcache

Avalie também se o bfcache foi usado para ajudar a identificar as 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';
    });
  }
});

Calcule a proporção de ocorrências do bfcache usando as contagens de navegações back_forward e back_forward_cache.

É importante perceber que há diversos cenários, fora do controle dos proprietários do site, em que uma navegação de retorno/retorno 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 e reabre uma guia.

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

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 devem esperar uma proporção de ocorrência de bfcache de 100% para todas as navegações back_forward. No entanto, medir a proporção delas pode ser útil para identificar 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 adicionou a API NotRestoredReasons para ajudar a explicar por que as páginas não usam o bfcache. Assim, os desenvolvedores podem melhorar as taxas de hits do bfcache. A equipe do Chrome também adicionou tipos de navegação ao CrUX, permitindo ver o número de navegações com o bfcache sem precisar fazer a medição por conta própria.

Medição da performance

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

Como as navegações do bfcache restauram uma página existente em vez de iniciar um novo carregamento, o número total de carregamentos de página coletados diminuirá quando o bfcache for 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 mais rápidos do seu conjunto de dados. Isso ocorre porque as navegações de ida e volta, por definição, são visitas repetidas, e os carregamentos de página repetidos geralmente são mais rápidos do que os 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 distorcerá a distribuição mais lentamente, apesar do fato de que o desempenho do usuário provavelmente melhorou.

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. Assim, você pode continuar monitorando seu desempenho nesses tipos de navegação, mesmo que a distribuição geral seja negativa. Recomendamos essa abordagem para métricas de carregamento de página não centradas no usuário, como Tempo para primeiro byte (TTFB).

Para métricas centradas no usuário, como as Core Web Vitals, uma opção melhor é 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 as restaurações do bfcache são executadas mais rapidamente do que o carregamento da página inteira, é importante que as Core Web Vitals reflitam isso. Afinal, o usuário não se importa se o bfcache foi ativado ou não, ele apenas se importa que a navegação foi rápida.

As ferramentas que coletam e relatam as Core Web Vitals, como o Chrome User Experience Report, tratam as restaurações do bfcache como visitas separadas à página no conjunto de dados. Embora não haja APIs de desempenho da Web dedicadas para medir essas métricas após a restauração do bfcache, é possível aproximar os valores usando as APIs da Web existentes:

• Para a Largest Contentful Paint (LCP), use o delta entre o carimbo de data/hora do evento pageshow e o carimbo de data/hora do próximo frame pintado, porque todos os elementos no frame serão pintados ao mesmo tempo. No caso de uma restauração do bfcache, a LCP e a FCP são iguais.
• Para Interaction to Next Paint (INP), continue usando seu observador de desempenho, mas redefina o valor de INP atual para 0.
• Para Cumulative Layout Shift (CLS), continue usando o Performance Observer, mas redefina o valor atual de CLS para 0.

Para mais detalhes sobre como o bfcache afeta cada métrica, consulte as páginas dos guias de métricas individuais das Core Web Vitals. Para ver um exemplo específico de como implementar versões do bfcache dessas métricas, consulte RP como adicioná-las à biblioteca JS web-vitals.

A biblioteca JavaScript web-vitals oferece suporte a restaurações do bfcache nas métricas informadas.

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 do bfcache (link em inglês) (teste como diferentes APIs e eventos afetam o bfcache nos navegadores)
• Mudança de desempenho: cache de avanço e retorno do navegador (um estudo de caso da Smashing Magazine mostrando melhorias drásticas nas Core Web Vitals ao ativar o bfcache)