O Chrome está fazendo uma mudança para permitir o uso do cache de avanço e retorno (bfcache) para páginas que usam Cache-Control: no-store quando isso for seguro. Descubra o que isso significa para os desenvolvedores.
Contexto
Definir Cache-Control: no-store como um cabeçalho HTTP é um indicador de que a página não deve ser armazenada no cache HTTP. Isso deve ser usado para páginas que contêm dados sensíveis, por exemplo, para páginas em que um usuário está conectado, mas a diretiva no-store geralmente é usada 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 rapidamente, vamos tornar a página visível novamente e retomar a execução do JS. Isso resulta em uma navegação quase instantânea para o usuário.
Embora isso não seja exigido pela especificação HTML, os navegadores normalmente consideram Cache-Control: no-store como um sinal para evitar colocar a página no bfcache. Essa é a principal razão pela qual o bfcache não é usado, em cerca de 17% das navegações de histórico em dispositivos móveis e 7% das navegações de histórico em computadores. Isso significa que essas páginas não se beneficiam das restaurações rápidas e precisam ser recarregadas completamente, incluindo todas as chamadas de rede, execução de JavaScript e renderização.
Muitas vezes, o Cache-Control: no-store é definido para evitar problemas de armazenamento em 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 sido deixada aberta o tempo todo.
Como o Chrome está mudando esse comportamento
O Chrome anunciou a intenção de mudar esse comportamento, mas está tomando uma abordagem cautelosa. Estamos realizando experimentos desde o Chrome 116, e até recentemente eles eram executados em 5% dos carregamentos de página.
Aumentamos esse número para 10% dos carregamentos de página em 2 de outubro e pretendemos aumentar ainda mais para 20% dos carregamentos de página em novembro e 50% no início do ano que vem. Vamos lançar isso totalmente logo depois, com algumas exceções que serão discutidas a seguir.
Dados sensíveis
Embora nossa análise mostre que a maioria das navegações de volta ou para frente não inclui dados sensíveis e, portanto, pode ser qualificada para o bfcache, há casos em que as páginas não podem 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 APIs abaixo para páginas que usam Cache-Control: no-store continuará a desqualificar essas páginas para o bfcache:
Essa não é uma lista completa de APIs que impedem o uso do bfcache, mas sim de APIs que bloqueiam o bfcache em páginas Cache-Control: no-store, mesmo que elas não estejam sendo usadas no momento da saída da página.
O tempo limite do bfcache para páginas Cache-Control: no-store também foi 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ção empresarial
As empresas geralmente têm softwares e dispositivos compartilhados difíceis de atualizar. A política AllowBackForwardCacheForCacheControlNoStorePageEnabled pode ser desativada para continuar impedindo o uso do bfcache para páginas Cache-Control: no-store.
Como 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, a alteração de cookies, isso vai impedir que a página use o bfcache com a mensagem "As páginas cujo recurso principal tem Cache-Control: no-store não podem entrar no cache de avanço e retorno" no testador de bfcache das Ferramentas do desenvolvedor do Chrome.
Use esta página de teste do bfcache (em inglês) para realizar testes com e sem essa sinalização.
O que os desenvolvedores precisam saber
Embora os desenvolvedores não precisem fazer mudanças para que os usuários se beneficiem desse uso maior do bfcache, há algumas coisas que eles precisam considerar como resultado disso. Essas foram considerações semelhantes que outros sites podem ter tido no lançamento inicial do bfcache em dezembro de 2021.
Impacto no desempenho
Estamos fazendo essa mudança para melhorar a experiência da página para os usuários na Web. Notamos melhorias significativas nas Core Web Vitals quando lançamos o bfcache pela primeira vez. Agora queremos trazer essas mesmas melhorias para mais sites.
Os proprietários de sites podem notar uma melhoria nas Core Web Vitals à medida que o lançamento é feito e medir o uso do bfcache no CrUX, inclusive no painel do CrUX.
Análise de impacto
As páginas restauradas do bfcache "restauram" a página antiga (incluindo a pilha do JavaScript) em vez de recarregá-la. Muitos provedores de análise populares não medem restaurações de bfcache como novas visualizações de página, já que elas só acionam visualizações de página quando são carregadas pela primeira vez.
Portanto, os sites podem notar uma redução nos carregamentos de página nas análises quando começam a usar o bfcache pela primeira vez. Recomendamos considerar essas como visualizações de página, definindo listeners para o evento pageshow e verificando 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 usar o bfcache quando não usavam antes e a página era totalmente recarregada com dados novos, os desenvolvedores podem considerar atualizar os dados em uma restauração do bfcache.
As atualizações podem ser acionadas de maneira semelhante ao registro de outras visualizações de página para análise usando o evento pageshow e verificando a propriedade persisted.
Nem todo conteúdo precisa ser atualizado, e os usuários podem preferir voltar ao conteúdo que já viram. Por exemplo, a atualização de uma lista de artigos pode fazer com que o usuário não encontre mais um artigo que estava voltando para visualizar.
Impacto nos anúncios
Assim como no impacto do Google Analytics, os sites podem ter uma redução nas impressões de anúncios se eles 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 carregamentos de página completos, usando novamente o evento pageshow e verificando a propriedade persisted, mas nem sempre é a melhor opção. Consulte a documentação do seu provedor de anúncios sobre como acionar recarregar anúncios.
Mais informações sobre o bfcache
Para mais informações sobre o bfcache, consulte nosso guia técnico completo do bfcache.
Feedback
Estamos ansiosos para receber feedback sobre essa mudança, que pode ser fornecido no Issue Tracker do Chrome usando o componente bfcache.
Conclusão
Estamos felizes em trazer os benefícios do bfcache para muitas outras páginas e melhorar a experiência dos usuários. Consideramos cuidadosamente essa mudança, e nossa abordagem busca lançar isso 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.