Cache de Voltar/Avançar (bfcache)

TL;DR — O cache de voltar/avançar (bfcache) é um recurso do navegador que congela uma página inteira na memória quando você sai dela, para que pressionar Voltar ou Avançar possa trazê-la de volta instantaneamente — sem recarregar — desde que o navegador ainda não tenha removido essa página congelada. É um recurso do navegador, não um fator de ranqueamento do Google. Mas, como uma página restaurada carrega quase instantaneamente, ela melhora discretamente seus números de Core Web Vitals nas navegações de Voltar/Avançar que são restauradas, motivo pelo qual uma auditoria de desempenho pode dizer para você “corrigir a elegibilidade do bfcache”.

O que é o bfcache

Quando você clica no botão Voltar do navegador, uma de duas coisas acontece. Ou o navegador reconstrói a página anterior do zero — baixando arquivos novamente, executando o JavaScript outra vez e refazendo o layout inteiro — ou restaura a página instantaneamente, exatamente como você a deixou. Essa versão instantânea é o cache de voltar/avançar, ou bfcache.

Este é o truque: em vez de descartar a página antiga quando você sai dela, o navegador congela a página inteira na memória — tudo, inclusive o JavaScript em execução — e a mantém parada. Se você voltar logo e o navegador ainda tiver aquela página congelada disponível, ele a descongela e mostra exatamente a página de novo — sem requisições de rede, sem espera. É uma restauração possível, não uma garantia: o navegador pode remover uma página congelada da memória antes que você pressione Voltar (pouca memória, um tempo limite, determinada atividade); nesse caso, você recebe apenas um recarregamento normal.

A própria descrição de uma linha do Google diz isso claramente: bfcache é “a browser optimization that enables instant back and forward navigation.” (tradução) «uma otimização do navegador que permite navegar instantaneamente para trás e para a frente».

Por que ele não é “o cache” que você já conhece

Esta é a parte que as pessoas confundem. Quando você ouve “cache”, provavelmente pensa no cache do navegador ou no cache HTTP — os arquivos (imagens, scripts, folhas de estilo) que o navegador salva para não precisar baixá-los novamente. O bfcache não é isso. Esses caches armazenam arquivos; o bfcache armazena a página viva inteira, com estado do JavaScript e tudo, como um snapshot. A própria documentação do Chrome explica: o bfcache “differs from browser cache and HTTP cache.” (tradução) «é diferente do cache do navegador e do cache HTTP».

Ele também não é outras duas coisas que às vezes são agrupadas com ele: o cache de recursos em memória do navegador (scripts compilados e imagens decodificadas que ele mantém na sessão atual) e o Cache Storage de um service worker (pares de requisição/resposta que um site gerencia explicitamente com caches.open()). Ambos podem estar ativos na mesma página que o bfcache — são mecanismos separados, não o próprio bfcache.

Ele também não é o antigo recurso de “página em cache” ou “snapshot em cache” que Google e Bing ofereciam nos resultados de busca (o pequeno menu que mostrava a versão de uma página que eles tinham arquivada). Aquilo era um recurso de busca e foi aposentado. O bfcache é um recurso vivo do navegador, sem relação com os resultados de busca.

O bfcache ajuda meu SEO?

Não diretamente. O bfcache não é um fator de ranqueamento do Google — a própria documentação de ranqueamento dos Core Web Vitals do Google nunca o menciona. O que ele faz é carregar suas navegações de Voltar/Avançar quase instantaneamente para os visitantes que realmente obtêm uma restauração, e os navegadores medem isso como um excelente “carregamento de página”. Portanto, se muitos visitantes usam Voltar e Avançar (compras, navegação nos resultados de busca, leitura de um artigo para outro), o bfcache pode melhorar os números de campo gerais dos Core Web Vitals do seu site — uma das várias coisas que o Google diz estar alinhada ao que seus sistemas de ranqueamento valorizam. São dois passos de distância de “o bfcache aumenta o ranqueamento”, e ele não garante sua taxa de restauração, sua avaliação geral de Core Web Vitals ou seus rankings — mas o efeito é real e mensurável.

Quer o quadro completo — exatamente o que bloqueia o bfcache, como testá-lo e a relação precisa (sem exageros) com os Core Web Vitals? Mude para a aba Avançado.

TL;DR — O bfcache é uma captura da página inteira em memória (DOM + memória dinâmica do JS + estado em execução), não uma resposta HTTP que possa ser buscada novamente, nem o cache de recursos em memória do navegador, nem o Cache Storage de um service worker — essa é a principal distinção conceitual. Ao sair, o navegador pausa o JS e congela a página; ao usar Voltar/Avançar, se aquela captura congelada ainda estiver disponível, ele a descongela e exibe novamente de imediato, com zero requisições de rede — mas a remoção é sempre possível, então trate uma restauração como provável, não garantida. Ele não é um fator de ranqueamento documentado da Busca do Google (a documentação de Core Web Vitals do Search Central nunca o menciona); sua relevância é indireta e limitada, por meio da medição de CWV em campo (principalmente LCP e CLS) nas navegações que são restauradas — ele não garante sua taxa de restauração, sua avaliação agregada de CWV, rankings ou conversões. O maior bloqueador de elegibilidade é o handler de unload (cerca de 18 pontos percentuais da taxa de sucesso no Chrome); historicamente, o maior era Cache-Control: no-store (bloqueando cerca de 17% das navegações de histórico mobile / 7% das desktop), embora o Chrome agora permita bfcache condicionalmente para muitas páginas no-store (removidas quando há mudança de autenticação/cookies, ainda bloqueadas pelas mesmas APIs de conexão aberta) após o lançamento de 2025. Conexões abertas, timers e observers devem ser fechados/pausados em pagehide/freeze e reestabelecidos em pageshow/resume; window.opener, políticas de permissões e frames também podem bloqueá-lo — confira o motivo por frame no DevTools ou em notRestoredReasons em vez de presumir. Faça testes pontuais com o Chrome DevTools; diagnostique em campo com a API notRestoredReasons exclusiva do Chrome (um resultado null não prova uma restauração, e o texto do motivo não é estável). Cada navegador tem suas próprias regras de elegibilidade, e navegações suaves de SPAs não recebem o mesmo tratamento.

O que o bfcache realmente é (a espinha dorsal da precisão)

O ponto mais importante a acertar: bfcache é uma captura da página inteira em memória, não uma resposta HTTP armazenada em cache. Quando você sai de uma página, em vez de destruí-la, o navegador pausa a execução do JavaScript e congela a página inteira — o DOM, a memória dinâmica do JS, os temporizadores em andamento, tudo — e a mantém na memória. Se você pressionar Voltar ou Avançar enquanto a captura congelada ainda estiver disponível, o navegador a descongela e exibe novamente a página exata que você deixou, com zero requisições de rede e zero novo leiaute. É uma restauração possível, não uma garantia — o navegador pode remover a captura antes que você volte (pressão de memória, tempo limite, certos eventos), ou uma regra específica do navegador pode forçar um carregamento novo; nesse caso, trata-se apenas de uma navegação comum pelo histórico.

A formulação canônica do Google resume o mecanismo desta forma: “a browser optimization that enables instant back and forward navigation.” (tradução) «uma otimização do navegador que torna instantâneas as navegações de Voltar e Avançar». É por isso que confundi-lo com o cache HTTP/do navegador é o erro recorrente dos concorrentes. O cache HTTP armazena respostas a requisições anteriores — arquivos que pode servir novamente. O bfcache armazena a página viva em execução. A documentação do Chrome DevTools traça a distinção explicitamente: o bfcache “differs from browser cache and HTTP cache.” (tradução) «não é igual ao cache do navegador nem ao cache HTTP». Você não “liga” o bfcache com cabeçalhos de cache da mesma forma que configura o cache HTTP — o único ponto em que os cabeçalhos entram é que Cache-Control: no-store costumava desqualificar uma página (mais sobre isso abaixo).

A mesma distinção vale para outros dois caches que as pessoas às vezes confundem com o bfcache: o cache de recursos em memória do navegador (scripts compilados e imagens decodificadas mantidos na sessão atual) e o Cache Storage de um service worker (pares explícitos de requisição/resposta que o site gerencia por meio de caches.open()). Ambos podem estar ativos na mesma página ao mesmo tempo que o bfcache — nenhum deles é o bfcache, que é especificamente a instância congelada da página, e não ativos armazenados ou respostas interceptadas.

Mais uma distinção vale ser feita porque ainda causa confusão: o bfcache não tem nada a ver com o antigo recurso de busca “página em cache” que Google (e Bing) já exibiram nos resultados. Aquilo era um snapshot armazenado de uma página no índice de busca e foi aposentado. O bfcache é um recurso do mecanismo de renderização no lado do cliente.

Quão comuns são as navegações de Voltar/Avançar, de verdade?

Este não é um caso extremo de nicho. Segundo o web.dev, “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (tradução) «1 em cada 10 navegações no desktop e 1 em cada 5 no mobile são de Voltar ou Avançar». Em qualquer site com fluxos repetidos de voltar/avançar — categoria para produto e volta no e-commerce, resultados de busca, conteúdo paginado, leitura de artigo para artigo — isso representa uma grande parcela de navegações reais que você pode tornar quase instantâneas.

Suporte dos navegadores

“All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (tradução) «Todos os principais navegadores incluem um bfcache, entre eles o Chrome desde a versão 96, o Firefox e o Safari.» O Firefox e o Safari têm suas próprias implementações de bfcache, mais antigas e duradouras; todos os navegadores baseados em Chromium (Edge, Brave, Opera, Arc) herdam o comportamento do Chrome. A documentação da política do Edge da Microsoft descreve o mesmo recurso: ao sair de uma página, seu estado atual (árvore do documento, script e assim por diante) pode ser preservado no cache de voltar/avançar; se o navegador voltar à página, ela poderá ser restaurada a partir dele e exibida no estado em que estava antes de ser armazenada. Ele vem ativado por padrão no Edge; o único interruptor é uma política corporativa controlada por um administrador de TI, não pelo proprietário do site.

A ressalva importante: o bfcache de cada navegador aplica suas próprias regras de elegibilidade. Uma página aprovada no teste Test back/forward cache (tradução) «Testar cache de Voltar/Avançar» do Chrome DevTools não tem elegibilidade garantida no Firefox ou no Safari. Trate uma aprovação no Chrome como necessária, não suficiente.

O que bloqueia a elegibilidade do bfcache

O evento unload — o maior bloqueador individual

Se você guardar uma coisa deste artigo, que seja: pare de usar o evento unload. O web.dev dá a isso uma ênfase rara para um documento do Google: “Never use the unload event. Ever!” (tradução) «Nunca use o evento unload. Em hipótese alguma!» No Chrome, handlers de unload custam aproximadamente uma redução de 18 pontos percentuais na taxa de sucesso do bfcache — de longe o maior desqualificador autoinfligido.

Há duas razões para o Chrome estar descontinuando-o ativamente. Primeiro, ele é o maior bloqueador do bfcache. Segundo, unload já é extremamente pouco confiável: no mobile, frequentemente não dispara de modo algum, porque as abas vão para segundo plano e são encerradas, e o navegador prioriza o bfcache em vez de disparar unload. Portanto, o evento em que você confia para “limpeza” muitas vezes não executa e está bloqueando um ganho real de desempenho.

As correções:

• Substitua unload por pagehide. O evento pagehide dispara em todos os casos em que unload dispara, além de quando uma página entra no bfcache — é uma melhoria estrita. Use visibilitychange para uma limpeza confiável quando o “usuário está saindo”.
• Detecte uma restauração do bfcache com pageshow. Escute pageshow e verifique event.persisted — se for true, a página foi restaurada do bfcache, o que indica que você deve atualizar dados antigos ou recontar uma visualização de página.
• Bloqueie proativamente listeners de unload com o cabeçalho de resposta Permissions-Policy: unload=(), que impede que qualquer handler de unload seja registrado. O Chrome está migrando gradualmente a política padrão para negar (uma Permissions-Policy para unload foi lançada no Chrome 115).

Cache-Control: no-store — historicamente o maior, agora com nuances

Este é o ponto de atualização que a maior parte do conteúdo concorrente erra. Historicamente, Cache-Control: no-store era o maior motivo individual para páginas serem excluídas do bfcache — os números do próprio Chrome o colocam em aproximadamente 17% das navegações de histórico no mobile e 7% no desktop. Muitos sites definem no-store defensivamente para evitar servir uma página antiga, mas o argumento do Google é que essa justificativa perde força com bfcache: uma restauração do bfcache não carrega uma resposta antiga armazenada, e sim exibe novamente a página viva exata, quase como se a aba tivesse permanecido aberta.

Então o Chrome mudou o comportamento — mas condicionalmente, não de forma universal. Os experimentos começaram no Chrome 116, com o lançamento final para 100% dos usuários durante março e abril de 2025: agora o Chrome permite bfcache para muitas páginas no-store, sujeito a condições específicas de segurança em vez de uma exceção geral. Segundo a documentação do próprio Chrome, há restrições reais — a página é removida do bfcache se o estado de autenticação ou os cookies mudarem enquanto ela está congelada (assim, um visitante que saiu da conta ou limpou cookies não vê um snapshot antigo de sessão autenticada), e uma lista fixa de APIs — as mesmas APIs de conexão aberta tratadas abaixo (IndexedDB, WebSocket, WebRTC e as demais) — ainda exclui uma página no-store do bfcache da mesma forma que excluiria qualquer outra página. Esse é um comportamento específico do Chrome em uma faixa específica de versões, não uma regra que você possa presumir em outros navegadores ou versões antigas do Chrome — obtenha o relatório atual do DevTools/notRestoredReasons para o navegador e a versão que está testando, em vez de confiar em uma regra fixa. Conclusão prática: qualquer guia (inclusive versões antigas deste artigo) que liste no-store como bloqueador incondicional e permanente do bfcache está desatualizado — assim como tratar o problema como totalmente resolvido. Se a atualização realmente importa para uma página, a documentação do Chrome sugere no-cache ou um max-age curto (por exemplo, max-age=60), em vez de no-store.

Conexões abertas, observers e outros bloqueadores

No momento da navegação, determinados recursos abertos ainda podem bloquear a elegibilidade — e exatamente quais são esses recursos, e se bloqueiam de vez ou apenas são fechados e podem ser reconectados, depende do navegador e da versão. Trate a lista abaixo como exemplos de um padrão, não como uma lista fixa e permanente de bloqueadores:

• Requisições fetch()/XMLHttpRequest em andamento.
• Transações abertas de IndexedDB.
• Conexões WebSocket/WebRTC abertas, timers e observers (MutationObserver, IntersectionObserver e similares). Esta área está evoluindo: notas de versão recentes do Microsoft Edge mostram que um WebSocket aberto agora é fechado quando uma página entra no bfcache (em vez de bloquear o armazenamento de forma direta), com reconexão recomendada pelo evento pageshow e pela verificação de event.persisted. Isso reflete a tendência mais ampla do Chrome de reduzir bloqueadores em vez de simplesmente excluir páginas.

O padrão geral a implementar, em vez de memorizar uma lista fixa: feche ou pause conexões abertas, timers e observers no tratamento de pagehide/freeze e restabeleça-os no tratamento de pageshow/resume quando event.persisted for true. Esse padrão continua válido mesmo que um navegador mude exatamente quais APIs bloqueiam a elegibilidade de forma direta e quais ele apenas suspende, permitindo reconexão.

window.opener, políticas de permissões e frames. Uma referência a window.opener, determinadas políticas de permissões e iframes incorporados (da mesma origem ou de origem cruzada) também podem afetar a elegibilidade — isso aparece no checklist que extraí do guia de CLS da Ahrefs e na documentação do Chrome. Mas não presuma a causa real a partir de um checklist genérico: o painel do Chrome DevTools e a API notRestoredReasons informam os motivos de bloqueio por frame — o frame superior e cada iframe separadamente — porque o frame realmente responsável pelo bloqueio nem sempre é a página de nível superior. Obtenha o motivo real no relatório por frame do navegador que está testando, em vez de adivinhar a partir de uma lista geral.

Acertando a sequência de eventos/estado do ciclo de vida

Confundir o que cada evento do ciclo de vida realmente prova com o que apenas sugere é o segundo erro de correção mais comum aqui, depois dos erros de elegibilidade acima:

A regra prática: trate pagehide.persisted como intenção, não como prova — a página ainda pode ser removida antes que você veja uma restauração. Apenas pageshow.persisted === true confirma que uma restauração aconteceu. Faça a limpeza incondicionalmente em pagehide/freeze (é barato e seguro até em uma navegação normal) e faça o trabalho específico de restauração somente em pageshow/resume, condicionado a event.persisted, para não atualizar dados nem contar duas vezes uma visualização analítica em um carregamento novo comum.

Como testar e diagnosticar o bfcache

Laboratório / pontual: Chrome DevTools

Abra DevTools → Aplicativo → Serviços em segundo plano → Cache de Voltar/Avançar e clique em Test back/forward cache (tradução) «Testar cache de Voltar/Avançar». O Chrome navega automaticamente para chrome://terms/ e volta, depois informa sucesso ou uma lista específica de motivos de bloqueio. É útil para verificar uma URL de cada vez.

Campo / produção: a API notRestoredReasons

Antes, a única forma de verificar a elegibilidade era aquele teste manual do DevTools, uma URL por vez — não havia como saber por que as navegações de usuários reais estavam bloqueadas. A propriedade notRestoredReasons de PerformanceNavigationTiming (lançada no Chrome 123+) fecha essa lacuna: ela informa os motivos específicos de bloqueio para o frame superior e iframes da mesma origem em dados reais de campo.

const nav = performance.getEntriesByType('navigation')[0];
console.log(nav.notRestoredReasons);

Alguns pontos precisam ser acertados ao usá-la, diretamente da orientação da própria API do Chrome:

• Ela funciona apenas no Chrome (123+). Firefox e Safari não expõem uma API de campo equivalente, então você ainda precisa de verificações manuais pontuais nesses navegadores para conhecer sua taxa de restauração neles.
• Um resultado null é ambíguo, não um sinal verde. Pode significar que a página foi restaurada ou que o navegador simplesmente não coletou um motivo — a documentação do próprio Chrome diz para não tratar null como prova de restauração bem-sucedida.
• O texto do motivo não é um contrato estável. Não codifique correspondências de strings; agrupe e acompanhe tendências por motivo, pois a formulação exata pode mudar entre versões do Chrome.

Na prática: extraia notRestoredReasons junto das taxas de restauração pageshow.persisted antes e depois de uma correção entrar no ar, compare a tendência em vez de um único snapshot e combine isso com uma verificação manual no DevTools/laboratório no Firefox e no Safari, navegadores que a API não alcança. Esta é a ferramenta para diagnosticar bfcache em escala no RUM/produção, em vez de verificar URLs uma por uma — apenas não a trate como o quadro inteiro.

Bfcache e Core Web Vitals — a relação precisa

Esta é a nuance que a maior parte do conteúdo concorrente mistura, e o ângulo que vale assumir.

Como uma restauração do bfcache é medida. Os navegadores (e, portanto, os dados de campo do CrUX) contam uma navegação restaurada pelo bfcache como um “carregamento de página” extremamente rápido — LCP quase instantâneo e, quando a página está implementada corretamente (nada precisa refazer o layout), efetivamente zero CLS adicional, porque não há nova renderização. Na comparação real do DebugBear, uma página restaurada pelo bfcache atingiu LCP em cerca de 100 ms, contra ~427 ms em um carregamento sem cache. É exatamente por isso que o bfcache aparece como alavanca para CLS e LCP no meu próprio checklist de CLS da Ahrefs, onde coloco de forma simples: “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (tradução) «Garanta que suas páginas sejam elegíveis para o bfcache. O cache de Voltar/Avançar mantém páginas no cache do navegador e carrega instantaneamente uma página já visitada, sem causar mudanças de layout.»

Há duas ressalvas de escopo que merecem precisão, pois é aqui que o conteúdo concorrente costuma exagerar. Primeiro, isso afeta apenas as navegações que o CrUX classifica como voltar/avançar (sua dimensão navigation-type) — não diz nada sobre primeiras visitas ou recarregamentos, que são a maioria do tráfego na maior parte dos sites. Segundo, uma restauração melhorar a experiência medida dos usuários que a obtêm não é uma garantia: quem for removido do bfcache (veja a tabela do ciclo de vida acima) ainda terá um carregamento normal e sem essa melhoria, portanto o trabalho de elegibilidade move sua taxa de restauração entre as navegações de Voltar/Avançar, não uma parcela fixa do tráfego total — e não garante sua avaliação agregada de Core Web Vitals em campo, seus rankings ou sua taxa de conversão. É uma alavanca real, mensurável e de escopo específico, não uma correção geral de desempenho ou SEO.

O bfcache é um fator de ranqueamento? Não. Esta é a afirmação defensável e diferenciada. A própria documentação de ranqueamento dos Core Web Vitals do Google não menciona bfcache. A cadeia honesta de influência é: elegibilidade do bfcache → melhores números de CWV em campo (principalmente LCP/CLS) nas navegações de voltar/avançar → Core Web Vitals é um entre vários sinais de “experiência na página” que o Google diz estar alinhado ao que seus sistemas de ranqueamento já valorizam. Isso é uma afirmação materialmente mais fraca e precisa do que “o bfcache aumenta rankings” — e é a afirmação que o conteúdo concorrente deveria fazer, mas normalmente não formula com cuidado. O bfcache também é, corretamente, um recurso do mecanismo de renderização, não do crawler — não tem relação com a forma como Googlebot ou Bingbot rastreiam suas páginas; por isso, não existe uma “posição do Bing sobre bfcache para SEO” como existe para robots.txt ou sitemaps.

SPAs e navegações suaves. O bfcache opera em navegações e eventos reais do histórico do navegador. Uma mudança de rota “suave” no lado do cliente de um aplicativo de página única (uma troca de visualização conduzida por JS que não dispara uma navegação real do navegador) não é um evento de bfcache e não recebe o mesmo tratamento. Tentativas de algumas ferramentas de RUM de atribuir Core Web Vitals a navegações suaves podem criar divergências de medição entre CrUX e RUM — um ponto que vale destacar ao auditar um site baseado em framework JS.

Quão comuns são os bloqueadores de bfcache no mundo real?

O Web Almanac do HTTP Archive acompanha isso, e é uma área viva e mutável — não uma notícia antiga já resolvida. Na edição de 2022, pelo menos ~22% das páginas mobile eram inelegíveis para bfcache apenas pelos critérios de unload e no-store. Desde então, o uso de handlers de unload vem caindo entre níveis de site e dispositivos — mas o uso de Cache-Control: no-store subiu (o capítulo de 2025 o coloca em cerca de 23% dos sites, contra ~21% em 2024, parcialmente atribuído ao aumento de experiências autenticadas/personalizadas e a requisitos de conformidade mais rigorosos).

A descoberta contraintuitiva que vale citar: sites maiores e com mais tráfego têm probabilidade desproporcionalmente maior de bloquear o próprio bfcache. Entre os mil sites principais, cerca de 28% das páginas desktop e 20% das mobile ainda usam handlers de unload, contra apenas ~11% desktop / ~10% mobile em todos os sites — frequentemente porque sites maiores carregam mais código legado de analytics dependente de unload. Os sites com mais tráfego de voltar/avançar a perder são muitas vezes os que ainda se atrapalham sozinhos.

Onde isso se encaixa

O bfcache é uma entre várias alavancas de desempenho neste cluster. Seu retorno aparece nos dados de campo dos Core Web Vitals — especificamente em Cumulative Layout Shift e Largest Contentful Paint, já que uma página restaurada é exibida instantaneamente sem refazer o layout. Ele é diferente de cache, que armazena arquivos em vez de um snapshot da página viva, embora os dois compartilhem o cabeçalho Cache-Control como ponto de contato. Não há relação direta com Interaction to Next Paint, então não vou forçar uma.

Resumo de IA

Uma versão condensada da versão Avançada:

• Bfcache = uma captura da página inteira em memória (DOM + memória dinâmica do JS + estado em execução), não uma resposta HTTP que possa ser buscada novamente, nem o cache de recursos em memória do navegador, nem o Cache Storage de um service worker. Ao sair, o navegador pausa o JS e congela a página; ao usar Voltar/Avançar, se a captura congelada ainda estiver disponível, ele a descongela e exibe novamente de imediato, com zero requisições de rede — a remoção é sempre possível, portanto uma restauração é provável, não garantida. A documentação do Chrome diz que ele “differs from browser cache and HTTP cache.” (tradução) «funciona de modo diferente do cache do navegador e do cache HTTP». Ele também não é o antigo recurso de busca “página em cache”, hoje aposentado.
• Não é fator de ranqueamento e tem escopo limitado. A própria documentação de ranqueamento dos Core Web Vitals do Google nunca menciona bfcache. A cadeia real é indireta: elegibilidade do bfcache → melhores números de CWV em campo (principalmente LCP/CLS) nas navegações de Voltar/Avançar que são restauradas → CWV é um sinal de experiência na página que o Google diz estar alinhado aos seus sistemas de ranqueamento. Ele não garante taxa de restauração, CWV agregado, rankings ou conversão — e só afeta navegações que o CrUX classifica como voltar/avançar.
• Escala: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward.” (tradução) «No desktop, 1 em cada 10 navegações é de Voltar ou Avançar; no mobile, a proporção é de 1 em cada 5.» Suporte: Chrome desde a versão 96, além de Firefox e Safari — mas cada navegador tem suas próprias regras de elegibilidade.
• Maior bloqueador: o evento unload — “Never use the unload event. Ever!” (tradução) «Jamais use o evento unload!» — cerca de 18 pontos percentuais da taxa de sucesso no Chrome. Substitua por pagehide + visibilitychange; detecte restaurações com pageshow / event.persisted; bloqueie unload com Permissions-Policy: unload=().
• Cache-Control: no-store foi historicamente o maior bloqueador (~17% das navegações de histórico mobile / ~7% desktop). O Chrome agora permite bfcache para muitas páginas no-store condicionalmente após o lançamento de março–abril de 2025 — remove-as quando autenticação/cookies mudam, ainda bloqueia pelas mesmas APIs de conexão aberta — e apenas no Chrome; guias antigas que chamam no-store de bloqueador absoluto estão desatualizados, assim como tratá-lo como totalmente resolvido.
• Outros bloqueadores: fetch/XHR em andamento, timers, observers, IndexedDB aberto, WebSocket/WebRTC (feche/pause em pagehide/freeze, reconecte em pageshow/resume), window.opener, políticas de permissões e frames — obtenha o motivo por frame no DevTools/notRestoredReasons em vez de presumir.
• Correção do ciclo de vida: pagehide.persisted é intenção, não prova; somente pageshow.persisted === true confirma uma restauração. Faça a limpeza incondicionalmente em pagehide/freeze; faça o trabalho específico de restauração (atualizar dados sensíveis, reconectar, contar uma visualização analítica) apenas em pageshow/resume.
• Testes: Test back/forward cache (tradução) «Testar cache de Voltar/Avançar» no Chrome DevTools (laboratório pontual); a API notRestoredReasons exclusiva do Chrome (Chrome 123+) para dados de campo — null não prova restauração, o texto do motivo não é estável e Firefox/Safari exigem verificações pontuais manuais. Compare as taxas de notRestoredReasons e pageshow.persisted antes/depois de uma correção.
• SPAs: navegações suaves no lado do cliente não são eventos de bfcache e não recebem o mesmo tratamento (uma fonte de divergência entre CrUX e RUM).
• Adoção (Web Almanac): o uso de no-store está subindo (~21%→23%), e o uso de unload é maior nos maiores sites (~28% desktop entre os mil principais) — sites grandes frequentemente bloqueiam o próprio bfcache.

Documentação oficial

Documentação de fontes primárias sobre bfcache. Observe a divisão: o bfcache vive na documentação do Chrome / mecanismo de renderização (a voz institucional do Google sobre ele), não no Google Search Central — essa separação é o próprio ponto.

Google / Chrome

• Cache de Voltar/Avançar — a documentação canônica: definição, mecanismo, a estatística de 1 em 10 / 1 em 5 e a orientação sobre unload.
• Testar o cache de Voltar/Avançar — etapas de teste no DevTools, principais bloqueadores e a afirmação de que ele é diferente do cache do navegador e do cache HTTP.
• Ativação do bfcache para Cache-Control: no-store — a mudança de política de 2025, os números de 17% / 7% e a linha do tempo do lançamento.
• Descontinuação do evento unload — por que unload está sendo descontinuado e a migração para Permissions-Policy.
• API notRestoredReasons do cache de Voltar/Avançar — diagnóstico de campo em PerformanceNavigationTiming (Chrome 123+).
• Entenda os Core Web Vitals e os resultados da Busca do Google — o documento de ranqueamento do Google Search Central; citado aqui como evidência de que nunca menciona bfcache.

Microsoft / Edge

• Política do Microsoft Edge: BackForwardCacheEnabled — definição do Edge, a mesma ressalva sobre unload e o interruptor de política corporativa.

MDN / padrões web

• bfcache — glossário da MDN — definição geral para desenvolvimento web e a distinção em relação ao cache HTTP.
• Monitoramento dos motivos de bloqueio do bfcache — MDN — uso prático de notRestoredReasons.

Citações da fonte

Declarações registradas na documentação-fonte. Cada link é profundo e salta para o trecho citado na página de origem.

Google / Chrome — o que é o bfcache e por que ele importa

• “Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation.” (tradução) «O cache de Voltar/Avançar, ou bfcache, é uma otimização do navegador que permite navegar instantaneamente pelo histórico.» — web.dev. Ir para a citação
• “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!” (tradução) «Uma em cada 10 navegações no desktop e uma em cada 5 no mobile é de Voltar ou Avançar. Com o bfcache ativo, os navegadores podem eliminar a transferência de dados e o tempo de carregamento de bilhões de páginas todos os dias!» Ir para a citação
• “All major browsers include a bfcache, including Chrome since version 96, Firefox and Safari.” (tradução) «Os principais navegadores oferecem bfcache, inclusive Chrome desde a versão 96, Firefox e Safari.» Ir para a citação

Google / Chrome — a principal regra de otimização

• “Never use the unload event. Ever!” (tradução) «Não use o evento unload — nunca!» — web.dev. Ir para a citação

Chrome DevTools — bfcache não é o cache HTTP

• “Back/forward cache differs from browser cache and HTTP cache.” (tradução) «O cache de Voltar/Avançar é um mecanismo distinto do cache do navegador e do cache HTTP.» — documentação do Chrome DevTools. Ir para a citação

Microsoft Edge — o mesmo recurso, a mesma ressalva

• “When navigating away from a page, its current state (document tree, script, and so on) may be preserved in the back-forward cache. If the browser navigates back to the page, the page may be restored from the back-forward cache and displayed in the state it was in before being cached.” (tradução) «Ao sair de uma página, seu estado atual — árvore do documento, script e outros elementos — pode ser preservado no cache de Voltar/Avançar. Se o navegador retornar à página, poderá restaurá-la desse cache e exibi-la no estado anterior ao armazenamento.» — documentação da política do Microsoft Edge. Ir para a citação

Patrick Stox (eu) — bfcache como alavanca de CLS

• “Make sure your pages are eligible for bfcache. The back/forward cache keeps pages in the browser cache. It allows for instant loading of a page that was already loaded, meaning no layout shifts will happen.” (tradução) «Verifique se suas páginas podem usar o bfcache. Ele conserva páginas no cache do navegador e permite reabrir imediatamente uma página já carregada, evitando mudanças de layout.» — meu guia de CLS da Ahrefs. Leia

Checklist de elegibilidade do bfcache

Uma verificação para confirmar que suas páginas podem entrar no cache de voltar/avançar:

• Nenhum listener de evento unload em qualquer lugar da página (seu ou de scripts de terceiros). Este é o maior bloqueador individual.
• O código de limpeza/analytics foi movido de unload para pagehide e visibilitychange.
• Um listener de pageshow verifica event.persisted para atualizar dados antigos e recontar corretamente as visualizações após uma restauração do bfcache.
• Considere o cabeçalho de resposta Permissions-Policy: unload=() para bloquear o registro de qualquer listener de unload.
• Revise Cache-Control: no-store — se você o definiu defensivamente, confirme que ainda precisa dele (o Chrome 2025+ permite bfcache condicionalmente para muitas páginas no-store — removidas quando há mudança de autenticação/cookies, ainda bloqueadas pelas mesmas APIs de conexão aberta; não presuma que outros navegadores ou versões tenham o mesmo comportamento); se a atualização for importante, prefira no-cache ou um max-age curto.
• Não deixe conexões abertas, timers ou observers pendurados no momento da navegação — fetch/XHR em andamento, transações abertas de IndexedDB, WebSocket/WebRTC, MutationObserver/IntersectionObserver (feche/pause em pagehide/freeze e restabeleça em pageshow/resume quando event.persisted confirmar a restauração).
• Não deixe referências a window.opener, políticas de permissões restritivas ou frames bloqueados mantendo a página inelegível — verifique o motivo por frame no DevTools/notRestoredReasons em vez de presumir qual se aplica.
• Teste em laboratório a página no Chrome DevTools → Aplicativo → Cache de Voltar/Avançar → Test back/forward cache (tradução) «Testar cache de Voltar/Avançar».
• Faça diagnóstico em campo em escala com notRestoredReasons no seu RUM (somente Chrome; um resultado null não prova uma restauração, e o texto do motivo não é um contrato estável — acompanhe tendências por motivo, não codifique strings).
• Não presuma que uma aprovação no Chrome significa elegibilidade em todo lugar — verifique pontualmente Firefox e Safari, que aplicam regras próprias.

Cola rápida do bfcache

O que o bloqueia — e a correção

Eventos que você deve conhecer

Teste-o

Fatos rápidos

• Bfcache = página viva inteira na memória, não arquivos, não o cache de recursos, não o Cache Storage de service worker. O Chrome diz que ele “differs from browser cache and HTTP cache.” (tradução) «não é o mesmo que o cache do navegador ou o cache HTTP».
• Não é fator de ranqueamento do Google — os documentos de CWV do Search Central nunca o mencionam. Uma restauração melhora o LCP/CLS medido para os usuários que a obtêm; não garante taxa de restauração, CWV agregado, rankings ou conversão.
• Suporte: Chrome 96+, Firefox e Safari — cada um com suas próprias regras.
• 1 em cada 10 navegações no desktop / 1 em cada 5 no mobile são de Voltar/Avançar.

Antipadrões do bfcache (e os mitos por trás deles)

“Bfcache é apenas meu cache HTTP/do navegador — eu o configuro com Cache-Control.” Não. O bfcache é um snapshot distinto da página inteira em memória; a documentação do Chrome diz que ele “differs from browser cache and HTTP cache.” (tradução) «é diferente do cache do navegador e do cache HTTP». Os cabeçalhos de cache só importam porque no-store costumava desqualificar uma página. Você não “liga o bfcache” com cabeçalhos de cache.

“Bfcache é um fator de ranqueamento do Google, então corrigi-lo aumenta rankings.” Isso não é estabelecido por nenhuma fonte oficial da Busca do Google. O documento de ranqueamento dos Core Web Vitals não menciona bfcache. A relação real é indireta (melhor LCP/CLS em campo nas navegações de Voltar/Avançar), uma afirmação mais fraca e precisa.

“Cache-Control: no-store sempre bloqueia o bfcache, permanentemente.” Isso era verdade historicamente — e ainda é a maior causa histórica —, mas já não é categoricamente verdadeiro após o lançamento completo, em 2025, do bfcache compatível com no-store no Chrome. Guias anteriores à mudança estão desatualizados nesse ponto — mas tratá-lo como totalmente resolvido também está errado: a exceção do Chrome é condicional (remoção quando autenticação/cookies mudam, ainda bloqueada pelas mesmas APIs de conexão aberta) e específica do Chrome, não uma luz verde universal.

“Uma página que dispara pagehide com persisted: true foi definitivamente armazenada.” Não — isso é intenção, não prova. O navegador ainda pode remover a página antes que você veja uma restauração. Apenas pageshow.persisted === true confirma que uma restauração realmente aconteceu.

“Se passa no teste de bfcache do Chrome DevTools, é elegível em todo lugar.” Falso. Chrome, Firefox e Safari aplicam restrições próprias; uma aprovação em um não garante elegibilidade em outro.

“unload é uma boa forma de executar código de saída/limpeza, então vou mantê-lo.” Não — o Chrome o considera extremamente pouco confiável (frequentemente não dispara no mobile) e está descontinuando-o ativamente via Permissions-Policy, precisamente porque ele é o maior bloqueador individual do bfcache. Use pagehide + visibilitychange.

“Bfcache ajuda minha SPA da mesma forma que ajuda um site multipágina.” Não sem ressalvas. O bfcache está ligado a navegações reais do navegador; uma mudança de rota “suave” no lado do cliente não é o mesmo evento e não recebe o mesmo tratamento — o que também causa divergências entre CrUX e RUM em sites dominados por SPA.

“O bfcache está resolvido / é notícia velha, não vale auditá-lo.” Os próprios dados do Web Almanac contradizem isso: o uso de no-store está subindo, e o uso de unload continua marcadamente maior nos sites maiores e de maior tráfego — justamente os que têm mais tráfego de Voltar/Avançar a perder.

Ferramentas para testar e diagnosticar o bfcache

• Painel do Chrome DevTools — cache de Voltar/Avançar. Aplicativo → Serviços em segundo plano → Cache de Voltar/Avançar → Test back/forward cache (tradução) «Testar cache de Voltar/Avançar». Navega automaticamente para chrome://terms/ e volta, depois informa sucesso ou os motivos exatos de bloqueio. É melhor para uma verificação pontual de uma única URL.
• A API notRestoredReasons (Chrome 123+). Leia performance.getEntriesByType('navigation')[0].notRestoredReasons no seu RUM para ver os motivos de bloqueio de usuários reais — inclusive de iframes da mesma origem — em escala, não apenas em um laboratório manual.
• PageSpeed Insights / Lighthouse / CrUX. É onde uma recomendação ou sinalização de “cache de voltar/avançar” costuma aparecer primeiro em uma auditoria e onde surge o benefício de CWV em campo de um site elegível para bfcache.
• Cabeçalho Permissions-Policy: unload=(). Não é uma ferramenta de teste, mas sim a alavanca de aplicação: defina-o para impedir ativamente o registro de listeners de unload (inclusive de terceiros).
• Capítulo de Performance do Web Almanac (HTTP Archive). Para comparar a prevalência de bloqueadores do bfcache na web por dispositivo e nível de ranking do site.

O DevTools diz que um handler de unload bloqueou a restauração

Sintoma: o teste do cache de voltar/avançar nomeia unload. Causa provável: código de primeiro ou terceiro que registrou um listener de unload. Correção: substitua a limpeza por pagehide/visibilitychange, adicione Permissions-Policy: unload=() quando apropriado e execute novamente o teste após cada alteração nos scripts afetados.

Uma página restaurada mostra dados de usuário antigos

Sintoma: Voltar retorna instantaneamente, mas o estado da conta, o inventário ou outro valor dinâmico está antigo. Causa provável: a página retomou seu estado congelado sem atualizar dados sensíveis ao tempo. Correção: escute pageshow, verifique event.persisted e atualize apenas os dados necessários. Confirme que carregamentos normais e restaurações funcionam.

O analytics perde ou duplica visualizações de Voltar/Avançar

Sintoma: as visualizações de página diferem das navegações reais pelo histórico. Causa provável: o analytics executa apenas no carregamento original ou executa duas vezes sem distinguir uma restauração. Correção: trate pageshow explicitamente e use event.persisted para contar a navegação restaurada uma vez.

O laboratório passa, mas a restauração em campo continua baixa

Sintoma: uma URL amostrada passa no DevTools, enquanto o RUM informa muitas não restaurações. Causa provável: outros templates, navegadores, estados de usuários reais ou conexões abertas intermitentes adicionam bloqueadores. Correção: colete notRestoredReasons, agrupe por motivo e template e reproduza o caso de campo dominante em vez de extrapolar uma única aprovação.

Prove que uma correção de bfcache entrou em vigor

Teste de elegibilidade

Teste: DevTools → Application → Back/forward cache → Test back/forward cache. Resultado esperado: a página é restaurada com sucesso, sem motivo de bloqueio. Interpretação da falha: resta pelo menos um bloqueador de elegibilidade. Janela de monitoramento: imediata para o Chrome no estado testado. Gatilho de rollback: a correção quebra a limpeza, a segurança ou o comportamento necessário do aplicativo.

Teste de comportamento da restauração

Teste: navegue para longe e pressione Voltar; depois verifique se pageshow recebe event.persisted === true e se os dados sensíveis ao tempo são atualizados. Resultado esperado: uma restauração instantânea, dados corretos e uma visualização analítica. Interpretação da falha: a página não foi armazenada ou o tratamento da restauração está incompleto. Janela de monitoramento: imediata em estados representativos, com e sem login. Gatilho de rollback: dados sensíveis antigos ou ações duplicadas após a restauração.

Teste do motivo em campo

Teste: monitore PerformanceNavigationTiming.notRestoredReasons no RUM. Resultado esperado: o bloqueador visado diminui nos templates afetados sem que um novo bloqueador dominante o substitua. Interpretação da falha: a amostra de laboratório não representou a produção ou outra dependência é responsável pelo problema. Janela de monitoramento: tráfego suficiente de Voltar/Avançar no mundo real para comparar a mesma combinação de templates. Gatilho de rollback: uma regressão material do aplicativo ou da integridade dos dados ligada à alteração.

Métricas de bfcache que vale acompanhar

Taxa de restauração

Métrica: navegações de Voltar/Avançar elegíveis restauradas pelo bfcache. O que informa: com que frequência os usuários recebem o benefício da navegação instantânea. Como extrair: entradas de navegação do RUM e pageshow.persisted, segmentadas por navegador e template. Referência/faixa realista: estabeleça sua própria linha de base, pois regras do navegador, estado da página e combinação de navegações variam. Cadência: semanalmente e após alterações no ciclo de vida.

Motivos de não restauração

Métrica: navegações do histórico agrupadas por notRestoredReasons. O que informa: quais bloqueadores custam mais restaurações reais. Como extrair: a API PerformanceNavigationTiming nos navegadores compatíveis. Referência/faixa realista: busque zero para bloqueadores controlados pelo seu próprio código, identificando a cobertura de navegador/API. Cadência: triagem semanal.

Correção das navegações restauradas

Métrica: erros, incidentes de dados antigos e analytics/ações duplicados após uma restauração. O que informa: se uma elegibilidade maior preserva a correção do aplicativo. Como extrair: eventos de erro do RUM, monitoramento do aplicativo e QA de analytics associado a pageshow.persisted. Referência/faixa realista: zero falhas conhecidas de correção ou privacidade. Cadência: alertas contínuos e QA de lançamento.

Recursos que valem seu tempo

Minha produção relacionada

• O que é Cumulative Layout Shift (CLS) e como melhorá-lo — onde listo a elegibilidade do bfcache como tática de melhoria de CLS, com um checklist curto de bloqueadores.
• O que são Core Web Vitals (CWVs) e como melhorá-los — as métricas principais, com bfcache como uma entre várias alavancas de CLS.
• Guia para iniciantes em SEO técnico — onde o desempenho web se encaixa no panorama maior.

Minhas palestras

• Como a busca funciona (SlideShare) — minha apresentação sobre rastreamento, renderização, indexação e ranqueamento, para contextualizar por que um recurso do mecanismo de renderização como bfcache fica fora dos sinais de ranqueamento da Busca. Aplica-se minha ressalva habitual: “This is my understanding of systems… not going to be 100% complete or accurate.” (tradução) «Esta é minha compreensão dos sistemas; ela não será 100% completa nem precisa.»

Oficial

• Cache de Voltar/Avançar (web.dev) — a documentação canônica.
• Ativação do bfcache para Cache-Control: no-store e Descontinuação do evento unload (Chrome para Desenvolvedores) — as duas mudanças que tornam guias antigos desatualizados.
• Entenda os Core Web Vitals e os resultados da Busca do Google (Google Search Central) — o documento de ranqueamento que, significativamente, nunca menciona bfcache.

Do setor

• bfcache — glossário da MDN — definição precisa e neutra em relação ao mecanismo, além da distinção em relação ao cache HTTP.
• O que o cache de Voltar/Avançar significa para a velocidade do site? (DebugBear) — o texto mais orientado por dados neste espaço, com um log de site real e uma comparação concreta de LCP (~100 ms em cache contra ~427 ms sem cache).
• Explicação do cache de Voltar/Avançar (SpeedVitals) — mecânica, elegibilidade, testes e impacto em CWV.
• Cache de Voltar/Avançar: o que é e como implementar (NitroPack) — focado em implementação, para um público de CMS/hospedagem.
• Recurso revolucionário de desempenho: cache de Voltar/Avançar do navegador (Smashing Magazine) — um mergulho técnico sólido, mas anterior à mudança de no-store de 2025.
• Web Almanac — capítulo de desempenho (2025) (HTTP Archive) — dados de adoção no mundo real sobre a prevalência de unload e no-store por dispositivo e nível de ranking do site.

Estatísticas que vale citar

• Navegações de Voltar/Avançar são comuns: “1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward” (tradução) «1 em cada 10 navegações no desktop e 1 em cada 5 no mobile é de Voltar ou Avançar» — a escala da oportunidade, não um caso de nicho. Fonte
• unload custa ~18 pontos percentuais da taxa de sucesso do bfcache no Chrome — por isso é o maior bloqueador e está sendo descontinuado. Fonte
• Cache-Control: no-store foi o maior bloqueador histórico — aproximadamente 17% das navegações de histórico no mobile e 7% no desktop — antes do lançamento de março–abril de 2025 do Chrome permitir bfcache para muitas páginas no-store. Fonte
• Uma restauração do bfcache é quase instantânea: o DebugBear mediu LCP de cerca de 100ms para uma página restaurada contra ~427 ms para um carregamento sem cache. Fonte
• Sites grandes se bloqueiam mais: entre os mil sites principais, ~28% das páginas desktop e ~20% das mobile ainda usam handlers de unload, contra ~11% / ~10% em todos os sites — e o uso de no-store está subindo (~21%→23%). Fonte

Teste seus conhecimentos: Cache de Voltar/Avançar (bfcache)

Cinco perguntas rápidas sobre o que é o bfcache, o que o bloqueia e como ele se relaciona com SEO. Escolha uma resposta para cada pergunta e depois confira.

Registro de alterações