Sentry torna mensurável a saúde do back/forward cache
O problema invisível do bfcache
O bfcache (back/forward cache) é o mecanismo pelo qual o navegador congela um snapshot completo da página - DOM, heap de JavaScript, posição de scroll - e o restaura instantaneamente em navegações de voltar/avançar, sem recarregar nada. Quando o cache falha, a página é reconstruída do zero, com refetches e re-renderizações.
Sentry argumenta que essa é uma das jornadas de navegação mais frequentes da web e domina fluxos com valor de negócio, como e-commerce (produto para listagem), busca, documentação e marketplaces. O benefício é maior para usuários em redes e dispositivos mais lentos. Segundo o post, "quão rápido é o botão Voltar" deveria ser uma pergunta de performance de primeira classe, às vezes maior que o carregamento de página nova.
Por que as ferramentas não enxergam
Toda ferramenta de performance, incluindo as do próprio Sentry, é construída em torno do ciclo de vida de carregamento da página. Um acerto do bfcache é indistinguível de "nada acontecendo" - o paradoxo é que quanto melhor o bfcache funciona, menos dados as ferramentas coletam.
Além disso, a elegibilidade do cache depende de heurísticas do navegador que mudam ao longo do tempo. Desqualificadores mundanos já incluíram listeners de unload, o header Cache-Control: no-store, conexões abertas ou bloqueios dentro de iframes - e qualquer um pode ser introduzido pelo próprio código ou por um script de terceiro sem que ninguém perceba. A elegibilidade pode regredir com ou sem mudanças de código, e o texto argumenta que testes e code review não são viáveis para combater isso; é preciso monitoramento ativo.
Como funciona a nova integração
A solução é a bfcacheMetricsIntegration, que modela os sinais do navegador (pageshow e a API notRestoredReasons) como três application metrics:
browser.bfcache.navigation: contador por navegação de voltar/avançar, com resultadohitoumisse a contagem de razões de não restauração.browser.bfcache.not_restored(apenas Chromium): contador por razão de não restauração, com a string bruta do navegador (ex.:unload-listener,websocket,response-cache-control-no-store) e a localização do bloqueador (topouchild).browser.bfcache.reload.duration: distribuição em milissegundos do custo do reload de fallback quando há miss - a métrica de impacto, que mede o que o miss realmente custou ao usuário em vez de estimar quão rápido seria a restauração.
Juntas, as métricas respondem: a página restaurou? Por que não? Quanto o miss custou?
Uso e disponibilidade
A integração é opt-in e foi lançada nos JavaScript SDKs v11, ativada com uma linha no Sentry.init. Em vez de um dashboard pré-pronto, o time pode construir visualizações próprias com as métricas - o post mostra exemplos de prompts de criação agêntica de dashboards, como taxa de acerto geral ao longo do mês, rotas com mais misses e principais razões de bloqueio, globais ou por rota. Como são application metrics, cada "e se" é uma query, sem redeploy ou nova instrumentação.
Resultados de hit e miss funcionam nos navegadores modernos; as razões detalhadas de não restauração são por enquanto um aprimoramento exclusivo do Chromium, e a cobertura deve se ampliar conforme mais engines implementem a API notRestoredReasons. A Sentry também planeja estender a consciência de bfcache a recursos como os Core Web Vitals, que hoje não registram páginas restauradas porque nenhuma carga de página é disparada nesses casos.