bfcache: navegação instantânea ao voltar e avançar no site

Resposta direta: o bfcache mantém uma fotografia completa da página, incluindo estado do JavaScript, para restaurá-la quase instantaneamente quando alguém usa voltar ou avançar. Ele é diferente do cache HTTP e costuma funcionar automaticamente, mas eventos como unload, conexões abertas e certas políticas podem impedir a restauração. Teste por template, trate pageshow e pagehide e atualize apenas o estado que realmente ficou obsoleto.

O ganho importa porque voltar faz parte da navegação real. Em um blog, a pessoa abre um artigo e retorna à lista. Em uma loja, compara produtos. Em um site de serviços, alterna entre portfólio e formulário.

O que fica preservado

O navegador pode guardar documento, memória do JavaScript, posição de rolagem e estado visual. Ao restaurar, evita baixar, interpretar e executar tudo novamente. A experiência parece imediata.

Cache HTTP guarda respostas de recursos, como CSS e imagens, e ainda exige reconstruir a página. O bfcache preserva uma instância inteira. Os mecanismos trabalham juntos, mas resolvem custos diferentes.

A elegibilidade é decisão do navegador. O site deve remover bloqueios e lidar corretamente com restauração, não forçar suporte.

Por que unload é um problema

O evento unload foi usado para enviar dados ao sair, mas não é confiável em dispositivos móveis e pode impedir bfcache. A recomendação moderna é evitar seu uso.

Para salvar estado, considere visibilitychange. Para liberar recursos, use pagehide. Para detectar retorno do bfcache, escute pageshow e leia a propriedade persisted do evento.

Não troque unload por beforeunload global. beforeunload deve existir somente quando há alterações não salvas e risco real de perda, sendo removido quando deixa de ser necessário.

Conexões e recursos que precisam ser fechados

WebSocket, WebRTC, bloqueios e transações abertas podem tornar a página inelegível ou insegura para congelamento. Feche ou pause no pagehide e restabeleça quando necessário.

O mesmo vale para IndexedDB em transação, eventos de servidor e observadores que dependem de estado externo. Cada recurso precisa de ciclo de vida explícito.

Bibliotecas de terceiros também podem adicionar bloqueios. Inventarie chat, analytics, vídeo e testes A/B, atualize versões e retire scripts sem valor.

Dados antigos após a restauração

Uma página restaurada mostra o estado de quando foi deixada. Carrinho, autenticação, estoque ou notificações podem ter mudado. No pageshow com persisted verdadeiro, atualize apenas elementos sensíveis.

Evite recarregar a página inteira sempre; isso elimina o benefício. Consulte um endpoint leve, compare versão ou invalide o componente afetado.

Se a sessão expirou, retire informações privadas e peça autenticação novamente. Não presuma que a tela restaurada comprova autorização atual.

Páginas sensíveis e no-store

Respostas com informações financeiras ou pessoais exigem política de cache deliberada. Cache-Control no-store pode limitar armazenamento, mas o comportamento de bfcache evolui entre navegadores. Siga a documentação atual e teste os alvos suportados.

Não aplique no-store ao site inteiro por hábito. Isso prejudica caches úteis e não substitui autenticação, autorização e limpeza de dados.

Separe páginas públicas, sessão autenticada e etapas realmente sensíveis. Cada grupo pode ter estratégia diferente.

Formulários e rascunhos

A restauração pode preservar campos preenchidos. Em contato comum, isso evita frustração. Em dados confidenciais, pode ser indesejado. Defina uma política por campo e por página.

Não limpe tudo indiscriminadamente. Explique quando um rascunho é salvo, evite armazenar segredos e confirme o estado do envio para impedir duplicidade.

Depois de uma conversão, use identificador idempotente no servidor. Voltar à tela não deve reenviar pagamento ou formulário.

Analytics sem duplicar conversões

Uma restauração não é idêntica a uma nova navegação. Algumas bibliotecas disparam page view somente no carregamento; outras podem duplicar eventos quando reinicializadas.

Defina se a restauração contará como visualização de página e documente a decisão. Para conversão, use evento único confirmado pelo servidor ou por identificador, nunca apenas a exibição da página de obrigado.

Inclua uma dimensão que diferencie carregamento normal e pageshow restaurado. Isso permite entender comportamento sem inflar resultados.

Como testar no navegador

Abra a página, navegue para outra URL do mesmo ou de outro site e volte. Verifique console, rede, posição de rolagem, formulário, login e eventos.

Ferramentas de desenvolvimento baseadas em Chromium oferecem teste de Back-forward Cache na área Application. Elas podem informar bloqueios. Execute em produção ou ambiente equivalente, pois extensões e depuração alteram o comportamento.

A API notRestoredReasons pode explicar por que uma página não foi restaurada em navegadores compatíveis. Trate-a como diagnóstico progressivo, porque suporte e detalhes variam.

Plano de teste por template

1. Liste home, categoria, artigo, produto, carrinho, login e formulário.
2. Teste voltar e avançar em desktop e celular.
3. Registre se houve restauração.
4. Verifique estado visual e rolagem.
5. Confirme autenticação e dados atualizados.
6. Valide analytics e conversões.
7. Analise bloqueios informados.
8. Corrija primeiro scripts globais.
9. Repita após atualizações de terceiros.

Exemplo em blog

A pessoa abre um artigo na listagem, lê e volta. Com bfcache, retorna à mesma posição sem reconstrução. O site deve preservar filtros e evitar reenviar uma visualização de conversão.

Se uma faixa de notícia mudou, ela pode ser atualizada separadamente, sem recarregar toda a lista.

Exemplo em loja virtual

O cliente compara dois produtos e retorna à categoria. A rolagem e filtros permanecem. Ao restaurar a página do produto, preço e estoque são revalidados.

O carrinho usa estado do servidor como fonte final. Restaurar a tela não deve desfazer uma alteração feita em outra aba.

Exemplo em área autenticada

Uma tela de painel é congelada. Ao retornar, consulta se a sessão continua válida e atualiza alertas. Se houver logout em outra aba, remove conteúdo e redireciona.

O teste inclui permissões reduzidas, expiração e troca de conta.

Impacto em SEO

O bfcache melhora experiência e pode reduzir a espera em navegações de histórico, mas não garante posição. Conteúdo, rastreamento, indexação, links e utilidade continuam essenciais.

Ele também não substitui Core Web Vitals. A navegação inicial ainda precisa carregar bem. Use o recurso como parte de engenharia de desempenho, junto a imagens otimizadas, JavaScript controlado e servidor rápido.

Checklist técnico

• Nenhum listener global de unload.
• beforeunload só quando necessário.
• pagehide libera recursos.
• pageshow reconhece persisted.
• WebSocket e transações têm ciclo definido.
• Estado sensível é revalidado.
• Formulários não duplicam envio.
• Analytics diferencia restauração.
• Scripts de terceiros foram auditados.
• Templates testados em celular.
• Bloqueios documentados.
• Regressão incluída em releases.

Erros frequentes

Os mais comuns são usar unload para analytics, recarregar tudo no pageshow, confiar em estado de autenticação antigo e medir página de obrigado como venda. Outro erro é testar só a home.

Não persiga elegibilidade a qualquer custo em páginas sensíveis. Segurança e correção vêm antes.

Arquitetura de eventos recomendada

Centralize os listeners de ciclo de vida em um módulo pequeno. Ele pode publicar eventos internos como página congelada, página restaurada e estado revalidado. Componentes de carrinho, autenticação e analytics assinam somente o que precisam.

Essa organização evita que cada biblioteca adicione seu próprio unload ou refaça toda a inicialização. Também permite desligar um fornecedor sem deixar handlers esquecidos.

Registre a versão da página e o horário em que foi congelada. Ao restaurar, compare com uma versão leve do servidor. Atualize o preço, sessão ou alerta necessário; preserve rolagem e entradas seguras.

Teste automatizado e observabilidade

Inclua uma jornada de voltar e avançar nos testes de navegador. Verifique que não há nova solicitação de documento quando o bfcache é usado, que a posição permanece e que conversões não duplicam.

Adicione contadores para carregamentos normais, restaurações e falhas de revalidação, sem coletar conteúdo de formulário. Uma queda brusca na taxa de restauração depois de um release pode revelar um script bloqueador.

Dados de campo são importantes porque extensões, memória do aparelho e políticas do navegador afetam elegibilidade. Segmente por template e navegador, preserve privacidade e não espere cem por cento.

Estratégia para terceiros

Carregue apenas ferramentas com finalidade comprovada. Pergunte ao fornecedor como o script reage a pagehide e pageshow, se abre conexões persistentes e como evita eventos duplicados.

Quando não houver correção, atrase o carregamento, limite a páginas necessárias ou substitua a solução. O custo de um script inclui rede, execução, privacidade e perda de recursos como bfcache.

Documente dependências críticas e teste após cada atualização. Tags injetadas fora do fluxo de desenvolvimento também precisam de governança.

Compartilhe o diagnóstico com produto, marketing e suporte. Um retorno instantâneo que preserva contexto reduz fricção, mas só gera valor quando a informação continua correta e a jornada respeita a intenção do visitante.

Perguntas frequentes

bfcache e cache HTTP são iguais?

Não. Um guarda a página inteira em memória; o outro reutiliza respostas de rede.

Preciso ativar o bfcache?

Em geral, o navegador decide automaticamente. O trabalho é remover bloqueios e tratar a restauração.

Como sei se a página voltou do cache?

No evento pageshow, verifique se persisted é verdadeiro.

Posso manter beforeunload?

Somente quando existe alteração não salva. Remova o listener fora desse estado.

O recurso melhora Core Web Vitals?

Pode melhorar a experiência ao voltar, mas não substitui as métricas e a otimização do primeiro carregamento.

Funciona em todos os navegadores?

O conceito tem suporte amplo, mas critérios e ferramentas variam. Teste nos navegadores usados pelo público.

Conclusão

O bfcache recompensa páginas com ciclo de vida bem projetado. A Open Leads considera desempenho, mensuração e segurança na criação de sites. Veja também o guia de preload, prefetch e Speculation Rules e navegue pelo blog.

Quer transformar tráfego em oportunidades reais? A Open Leads integra mídia paga, mensuração e criação de sites focados em conversão. Conheça os serviços da Open Leads.

Fontes consultadas

Consulte os materiais originais usados na pesquisa deste artigo.

• Back/forward cache — web.dev
• Back/forward cache glossary — MDN Web Docs
• Monitoring bfcache blocking reasons — MDN Web Docs
• HTTP caching — MDN Web Docs