Cache de avanço e retorno

Philip Walton

Barry Pollard

O cache de avanço e retorno (bfcache) é uma otimização do navegador que permite voltar e avançar na navegação. Ele melhora significativamente a experiência de navegação, especialmente para usuários com redes ou dispositivos mais lentos.

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

Compatibilidade com navegadores

Todos os principais navegadores incluem um bfcache, incluindo o Chrome desde a versão 96, o Firefox e o Safari.

Noções básicas do bfcache

Com o cache de avanço e retorno (bfcache), em vez de destruir uma página quando o usuário sai dela, adiamos a destruição e pausamos a execução do JS. Se o usuário voltar em breve, vamos tornar a página visível novamente e retomar a execução do JavaScript. Isso resulta em uma navegação de página quase instantânea para o usuário.

Quantas vezes você já acessou um site e clicou em um link para ir a 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 aceleração que ele pode trazer para as navegações:

No vídeo, o exemplo com bfcache é muito 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 baixados 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 são para voltar ou avançar. 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 tem um papel próprio na aceleração de navegações repetidas. O bfcache é um snapshot da página inteira na memória, incluindo o heap JavaScript, enquanto o cache HTTP contém apenas as respostas para solicitações feitas anteriormente. Como é muito raro que todas as solicitações necessárias para carregar uma página sejam atendidas pelo cache HTTP, as visitas repetidas usando restaurações do bfcache são sempre mais rápidas do que até mesmo as navegações não bfcache mais bem otimizadas.

Congelar uma página para reativá-la depois envolve alguma complexidade em termos de como preservar melhor 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 todos os timers pendentes ou promessas não resolvidas para páginas no bfcache, incluindo quase todas as tarefas pendentes nas filas de tarefas do JavaScript, e retomam o processamento de tarefas se a página for restaurada do bfcache.

Em alguns casos, como para tempos limite e promessas, o risco é 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 uma transação do IndexedDB, isso poderá afetar outras guias abertas na mesma origem, porque vários guias podem acessar os mesmos bancos de dados do IndexedDB simultaneamente. Como resultado, os navegadores geralmente não tentam armazenar em cache páginas no meio de uma transação do IndexedDB ou ao usar APIs que podem afetar outras páginas.

Para mais detalhes sobre como o uso de várias APIs afeta a qualificação de uma página para bfcache, consulte Otimizar suas páginas para bfcache.

O bfcache e os iframes

Se uma página tiver iframes incorporados, eles não serão qualificados separadamente para o bfcache. Por exemplo, se você navegar para outro URL em um iframe, o conteúdo anterior não vai entrar no bfcache. Se você voltar, o navegador vai "voltar" no iframe em vez do frame principal, mas a navegação de volta no iframe não vai usar o bfcache.

No entanto, quando o frame principal é restaurado do bfcache, os iframes incorporados são restaurados como estavam quando a página entrou no bfcache.

O frame principal também pode ser impedido de usar o bfcache se um iframe incorporado usar APIs que o bloqueiam. Para evitar isso, use a Política de permissões definida no frame principal ou o uso de atributos sandbox.

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

Como o bfcache funciona com navegações gerenciadas pelo navegador, ele não funciona com "navegações leves" em um app de página única (SPA, na sigla em inglês). No entanto, o bfcache ainda pode ajudar ao voltar para um SPA em vez de fazer uma reinicialização completa do app desde o início.

APIs para observar o bfcache

Embora o bfcache seja uma otimização feita automaticamente pelos navegadores, ainda é importante que os desenvolvedores saibam quando isso está acontecendo para otimizar as páginas para ele e ajustar as métricas ou a medição de performance de acordo.

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 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. Esses eventos são compatíveis apenas com navegadores baseados no Chromium.

Observar quando uma página é restaurada do bfcache

O evento pageshow é acionado logo depois do load quando a página é carregada pela primeira vez e todas as vezes que a página é restaurada do bfcache. O evento pageshow tem uma propriedade persisted, que é true se a página foi restaurada do bfcache e false caso contrário. É possível usar a propriedade persisted para diferenciar entre os carregamentos de página normais e as 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 (imediatamente antes do evento pageshow) e quando um usuário revisita uma guia em segundo plano congelada. Se você quiser atualizar o estado de uma página depois que ela for congelada (incluindo páginas no bfcache), use o evento resume. No entanto, se quiser medir a taxa de acertos do bfcache do seu site, use o evento pageshow. Em alguns casos, talvez seja necessário usar os dois.

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 é acionado 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ê pode ter certeza de que a página não vai entrar no bfcache. No entanto, o fato de persisted ser true não garante que uma 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 isso.

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 pretende armazenar a página em cache. Mas ele ainda pode descartar o conteúdo por vários motivos, explicados mais adiante.

Otimizar suas páginas para bfcache

Nem todas as páginas são armazenadas no bfcache, e mesmo quando uma página é armazenada lá, ela não fica indefinidamente. É fundamental que os desenvolvedores entendam o que torna as páginas qualificadas (e não qualificadas) para o bfcache e, assim, maximizem as taxas de acerto do cache.

As seções a seguir descrevem as práticas recomendadas para aumentar a probabilidade de o navegador armazenar em cache suas páginas.

Nunca use o evento unload

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

O evento unload é problemático para os navegadores porque é anterior ao bfcache, e muitas páginas na Internet operam sob a premissa (razoável) de que uma página não vai continuar existindo depois que o evento unload for acionado. Isso é um desafio porque muitas dessas páginas também foram criadas com a premissa de que o evento unload seria acionado sempre que um usuário saísse da página, o que não é mais verdade (e não é verdade há muito tempo).

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

No computador, o Chrome e o Firefox optaram por tornar as páginas inelegíveis para bfcache se elas adicionarem um listener unload, o que é menos arriscado, mas também desqualifica muitas páginas. O Safari tenta armazenar em cache algumas páginas com um listener de eventos unload, mas, para reduzir possíveis falhas, ele não executa o evento unload quando um usuário está saindo da página, o que torna o evento muito não confiável.

Em dispositivos móveis, o Chrome e o Safari tentam armazenar em cache páginas com um listener de eventos unload, já que o risco de falha é menor porque o evento unload sempre foi extremamente não confiável em dispositivos móveis. O Firefox trata as páginas que usam unload como inelegíveis para o cache de avanço e retorno, exceto no iOS, que exige que todos os navegadores usem o mecanismo de renderização WebKit e, portanto, 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 é 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 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 pretende descontinuar o evento unload.

Usar a política de permissões para impedir o uso de manipuladores de descarregamento 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.

Permissions-Policy: unload=()

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

Adicionar apenas listeners de beforeunload de forma condicional

O evento beforeunload não torna suas páginas inelegíveis para bfcache em navegadores modernos, mas isso acontecia antes e 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ê quer avisar o usuário de que ele tem alterações não salvas que serão perdidas se ele sair da página. Nesse caso, é recomendável adicionar listeners beforeunload somente quando um usuário tiver mudanças não salvas e removê-los imediatamente depois que elas 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 cabeçalho HTTP que os servidores da Web podem definir em respostas para instruir o navegador a não armazenar a resposta em nenhum cache HTTP. É usado 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, historicamente, quando Cache-Control: no-store é definido no próprio recurso da página (em vez de qualquer sub-recurso), os navegadores optam por não armazenar a página no bfcache. Portanto, as páginas que usam Cache-Control: no-store podem não estar qualificadas para o bfcache. Estamos trabalhando para mudar esse comportamento no Chrome de uma maneira que preserve a privacidade.

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

Para páginas que precisam sempre veicular conteúdo atualizado e que não contêm informações sensíveis, use Cache-Control: no-cache ou Cache-Control: max-age=0. Essas diretivas instruem o navegador a revalidar o conteúdo antes de veicular, 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 mostrado ao usuário.

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

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

Se o site mantiver o estado do usuário, principalmente informações sensíveis, esses dados precisam ser atualizados ou limpos depois que uma página é restaurada do bfcache.

Por exemplo, se um usuário navegar até uma página de finalização da compra e atualizar o carrinho, uma navegação para trás poderá expor informações desatualizadas se uma página obsoleta for restaurada do bfcache.

Outro exemplo mais crítico é 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 achava que tinham sido apagados quando ele fez logout.

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

O ideal é atualizar o conteúdo no local, mas, para algumas mudanças, talvez seja 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 recarrega 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();
  }
});

Uma atualização tem a vantagem de preservar o histórico (para permitir navegações para frente), mas um redirecionamento pode ser mais adequado em alguns casos.

Anúncios e restauração do bfcache

Pode ser tentador evitar o uso do bfcache para veicular um novo conjunto de anúncios em cada navegação para frente/para trás. No entanto, além de ter um impacto na performance, é questionável se esse comportamento leva a um melhor engajamento com o anúncio. Os usuários podem ter notado um anúncio em que pretendiam clicar novamente, mas, ao recarregar em vez de restaurar do bfcache, não conseguem fazer isso. É importante testar esse cenário, de preferência com um teste A/B, antes de fazer qualquer suposição.

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

Evitar referências window.opener

Em navegadores mais antigos, se uma página fosse aberta usando window.open() de 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 de segurança, uma página com uma referência window.opener não nula não pode ser colocada em bfcache com segurança, porque isso pode quebrar qualquer página que tente acessá-la.

Por isso, é melhor evitar criar referências window.opener. Para isso, use rel="noopener" sempre que possível. Esse é o padrão em todos os navegadores modernos. Se o site exigir a abertura de uma janela e o controle dela por window.postMessage() ou referenciando diretamente o objeto da janela, nem a janela aberta nem o abridor serão qualificados para o bfcache.

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

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

Se essas tarefas JavaScript programadas estiverem apenas acessando APIs DOM ou outras APIs isoladas apenas para a página atual, pausar essas tarefas enquanto a página não estiver visível para o usuário não vai causar problemas.

No entanto, se essas tarefas estiverem conectadas a APIs que também podem ser acessadas de outras páginas na mesma origem (por exemplo, IndexedDB, Web Locks, WebSockets), isso pode ser problemático, porque pausar essas tarefas pode impedir que o código em outras guias seja executado.

Como resultado, alguns navegadores não tentam colocar uma página no 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 WebSocket ou WebRTC aberta

Se a página estiver usando alguma dessas APIs, recomendamos 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 afetar outras guias abertas.

Em seguida, se a página for restaurada do bfcache, você poderá 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 IndexedDB estejam qualificadas para 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());

Teste para garantir que suas páginas possam ser armazenadas em cache

As Ferramentas para desenvolvedores do Chrome ajudam a testar as páginas para garantir que elas sejam otimizadas para o uso do bfcache e identificar problemas que possam as desqualificar.

Para testar uma página:

1. Acesse a página no Chrome.
2. No DevTools, acesse Application -> Back-forward Cache.
3. Clique no botão Executar teste. Em seguida, as DevTools tentam acessar outra página e voltar para determinar se a página pode ser restaurada do bfcache.

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

Se não for possível, o painel vai indicar o motivo. Se for possível resolver o problema que impediu a restauração, isso também vai ser informado no painel.

Neste exemplo, o uso de um listener de eventos unload torna a página inadequada 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 de bfcache, que realiza um teste semelhante. Para mais informações, consulte a documentação da auditoria do bfcache.

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

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 relatadas à medida que o Chrome ativa o bfcache para mais usuários.

Na verdade, é provável que você já esteja subestimando as visualizações de página de outros navegadores que implementam o bfcache, porque muitas bibliotecas de análise conhecidas não medem as restaurações do bfcache como novas visualizações de página.

Para incluir restaurações do bfcache na 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

Também é possível medir se o bfcache foi usado para ajudar a identificar páginas que não estão utilizando o recurso. 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 taxa de acertos do bfcache usando as contagens de navegações back_forward e back_forward_cache.

É importante saber que há vários cenários fora do controle dos proprietários de sites em que uma navegação para frente e para trás não usa o bfcache, incluindo:

• quando o usuário fecha e abre o navegador 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, mostrar um tipo de back_forward, mesmo que não sejam navegações para frente/para trás.

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 taxa de acertos de bfcache de 100% para todas as navegações back_forward. No entanto, medir a proporção 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 para frente e para trás.

A equipe do Chrome adicionou a API NotRestoredReasons para ajudar a expor os motivos pelos quais as páginas não usam o bfcache. Assim, os desenvolvedores podem melhorar as taxas de acerto do bfcache. A equipe do Chrome também adicionou tipos de navegação ao CrUX, permitindo ver o número de navegações do bfcache mesmo sem fazer a medição por conta própria.

Medição da performance

O bfcache também pode afetar negativamente as métricas de performance coletadas em campo, principalmente as 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 diminui quando o bfcache está ativado. No entanto, o que é fundamental é que os carregamentos de página substituídos pelas restaurações do bfcache provavelmente seriam alguns dos mais rápidos no seu conjunto de dados. Isso acontece porque as navegações de volta e para frente, 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 pela primeira vez (devido ao armazenamento em cache HTTP, conforme mencionado anteriormente).

O resultado é menos carregamentos rápidos de página no seu conjunto de dados, o que provavelmente vai distorcer a distribuição para mais lento, apesar de a performance do usuário provavelmente ter melhorado.

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 sua performance 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 o tempo até o 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 o que o usuário vivencia.

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 percebem as restaurações do bfcache como navegações mais rápidas do que carregamentos de página inteira, é importante que as métricas das Core Web Vitals reflitam isso. Afinal, um usuário não se importa se o bfcache foi ativado ou não, apenas que a navegação foi rápida.

As ferramentas que coletam e geram relatórios sobre as métricas das 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 restaurações do bfcache, é possível aproximar os valores usando APIs da Web atuais:

• Para o 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 renderizado, porque todos os elementos no frame serão renderizados ao mesmo tempo. No caso de uma restauração do bfcache, o LCP e o FCP são iguais.
• Para Interaction to Next Paint (INP), continue usando o Performance Observer atual, mas redefina o valor atual do INP para 0.
• Para Cumulative Layout Shift (CLS), continue usando o Performance Observer atual, mas redefina o valor de CLS atual para 0.

Para mais detalhes sobre como o bfcache afeta cada métrica, consulte as páginas individuais dos guias de métricas das Core Web Vitals. Para um exemplo específico de como implementar versões bfcache dessas métricas, consulte a solicitação de pull que as adiciona à biblioteca JS web-vitals.

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

Outros recursos

• Armazenamento em cache do Firefox (bfcache no Firefox)
• Cache de página (bfcache no Safari)
• Cache de avanço e retorno: comportamento exposto na Web (diferenças do bfcache entre navegadores)
• Testador de bfcache (teste como diferentes APIs e eventos afetam o bfcache nos navegadores)
• Mudança na performance: cache de avanço e retorno do navegador (um estudo de caso da Smashing Magazine mostrando melhorias drásticas nas principais métricas da Web ao ativar o bfcache)