Publicado em: 21 de outubro de 2024. Última atualização: 9 de setembro de 2025
O Chrome está fazendo uma mudança para permitir o uso do cache de avanço e retorno (bfcache) em páginas que usam Cache-Control: no-store quando isso é seguro. Saiba o que isso significa para os desenvolvedores.
Contexto
Definir Cache-Control: no-store como um cabeçalho HTTP é um sinal de que a página não deve ser armazenada no cache HTTP. Isso deve ser usado em páginas que contêm dados sensíveis, por exemplo, quando um usuário está conectado. No entanto, a diretiva no-store é usada com frequência em páginas sem dados sensíveis.
Com o 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.
Embora não seja exigido pela especificação HTML, os navegadores geralmente consideram Cache-Control: no-store como um sinal para evitar colocar a página no bfcache. Esse é o principal motivo para o bfcache não ser usado, em cerca de 17% das navegações de histórico em dispositivos móveis e 7% em computadores. Isso significa que essas páginas não se beneficiam das restaurações rápidas e precisam recarregar totalmente a página, incluindo chamadas de rede, execução de JavaScript e renderização.
Muitas vezes, Cache-Control: no-store é definido para evitar problemas de cache quando o site muda, mas esse motivo é menos relevante quando o bfcache é usado, já que a página inteira é restaurada quase como se tivesse ficado aberta o tempo todo.
Como o Chrome está mudando esse comportamento
O Chrome anunciou a intenção de mudar esse comportamento, mas está adotando uma abordagem cautelosa para essa mudança. Estamos realizando experimentos desde o Chrome 116, aumentando gradualmente a porcentagem de carregamentos de página. A expectativa é que esse número chegue a 100% em março e abril de 2025.
Dados sensíveis
Embora nossa análise mostre que a maioria das navegações para frente ou para trás não inclui dados sensíveis e, portanto, deve estar qualificada para o bfcache, há casos em que as páginas não devem ser colocadas no bfcache. Por exemplo, ao sair, não deve ser possível recuperar uma página conectada navegando para frente ou para trás.
Para evitar isso, o Chrome vai remover uma página do bfcache quando houver mudanças nos cookies ou em outros métodos de autorização.
Além disso, o uso das seguintes APIs em páginas que usam Cache-Control: no-store vai continuar impedindo que elas sejam qualificadas para o cache de avanço e retorno:
Esta não é uma lista completa de APIs que impedem o uso do bfcache, mas sim as APIs que bloqueiam o bfcache em páginas Cache-Control: no-store, mesmo que não estejam sendo usadas no momento de sair da página.
O tempo limite do bfcache para páginas Cache-Control: no-store também é reduzido para 3 minutos (de 10 minutos usados para páginas que não usam Cache-Control: no-store) para reduzir ainda mais o risco.
Desativações empresariais
As empresas costumam ter softwares difíceis de atualizar e dispositivos compartilhados. A política AllowBackForwardCacheForCacheControlNoStorePageEnabled pode ser desativada para continuar impedindo o uso do bfcache em páginas Cache-Control: no-store.
Testar a mudança
Os desenvolvedores podem testar essa mudança com a seguinte flag:
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
Se alguma das exceções anteriores se aplicar (por exemplo, cookies mudando), isso vai impedir que a página use o bfcache com o motivo "Páginas cujo recurso principal tem Cache-Control: no-store não podem entrar no cache de avanço e retorno", que aparece no testador de bfcache do Chrome DevTools.
Use esta página de teste do bfcache para testar com e sem essa flag.
O que os desenvolvedores precisam saber
Embora os desenvolvedores não precisem fazer mudanças para que os usuários se beneficiem desse maior uso do bfcache, há algumas coisas que eles precisam considerar como resultado disso. Essas foram considerações semelhantes às que outros sites podem ter enfrentado no lançamento inicial do bfcache em dezembro de 2021.
Os desenvolvedores ainda precisam reduzir o uso de Cache-Control: no-store?
O bfcache está ativado para Cache-Control: no-store nas circunstâncias limitadas mencionadas anteriormente e apenas no Chrome. Outros navegadores ainda podem bloquear o uso do bfcache quando Cache-Control: no-store é usado.
A prática recomendada continua sendo minimizar o uso de Cache-Control: no-store em vez de depender dessas heurísticas.
Impacto na performance
O motivo dessa mudança é melhorar a experiência na página para os usuários na Web. Notamos melhorias significativas nas Core Web Vitals quando lançamos o bfcache pela primeira vez, e agora queremos levar essas mesmas melhorias para mais sites.
Os proprietários de sites podem notar uma melhoria nas Core Web Vitals à medida que isso é lançado e podem medir o uso do bfcache no CrUX, incluindo no CrUX Vis.
Análise de impacto
As páginas restauradas do bfcache "restauram" a página antiga (incluindo o heap JavaScript) em vez de recarregar a página. Muitos provedores de análise conhecidos não medem as restaurações do bfcache como novas visualizações de página, já que só acionam visualizações quando são carregadas inicialmente.
Portanto, os sites podem notar uma redução nos carregamentos de página na análise quando começam a usar o bfcache pela primeira vez. Recomendamos considerar esses eventos como visualizações de página. Para isso, defina listeners para o evento pageshow e verifique a propriedade persisted:
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
Processar atualizações na restauração da página
Como os sites agora podem ver o uso do bfcache quando não viam antes e quando a página seria totalmente recarregada com dados atualizados, os desenvolvedores podem considerar a atualização dos dados em uma restauração do bfcache.
As atualizações podem ser acionadas de maneira semelhante ao registro de visualizações de página adicionais para análise usando o evento pageshow e verificando a propriedade persisted.
Nem todo o conteúdo precisa ser atualizado, e os usuários podem preferir voltar ao conteúdo que viram antes. Por exemplo, ao atualizar uma lista de artigos, o usuário pode não encontrar mais um artigo que estava voltando para ler.
Impacto nos anúncios
Assim como o impacto na análise, os sites podem ter uma redução nas impressões de anúncio se os anúncios forem carregados apenas no carregamento da página. Os anúncios podem ser atualizados de forma programática na restauração do bfcache para garantir a paridade com os carregamentos de página inteira. Para isso, use o evento pageshow e verifique a propriedade persisted, mas nem sempre essa é a melhor opção. Consulte a documentação do seu provedor de anúncios sobre como acionar recarregamentos de anúncios.
Mais informações sobre o bfcache
Para mais informações sobre o bfcache, consulte nosso guia técnico completo sobre o bfcache.
Feedback
Queremos saber o que você achou dessa mudança. Para isso, use o rastreador de problemas do Chrome com o componente bfcache.
Conclusão
Estamos animados em trazer o benefício do bfcache para muito mais páginas e melhorar a experiência na página para os usuários. Analisamos cuidadosamente essa mudança e nossa abordagem busca lançá-la da maneira mais segura possível. Esperamos que as informações fornecidas aqui ajudem os desenvolvedores a entender essa mudança e fazer as alterações necessárias para evitar problemas quando isso acontecer.