Navegação Instantânea na Web: Guia Completo da Speculation Rules API, Prerendering e bfcache

Introdução: A Era da Navegação Instantânea

Vou ser direto: em 2026, os utilizadores não têm paciência. E os números confirmam isso — 53% dos visitantes abandonam uma página que demora mais de 3 segundos a carregar, e cada 100 milissegundos de latência adicional pode custar até 7% em conversões. A navegação instantânea deixou de ser um "nice to have" e tornou-se uma questão de sobrevivência para qualquer site sério.

Se olharmos para trás, a evolução foi impressionante. Começámos com o humilde <link rel="prefetch"> e o <link rel="prerender">, passámos pelas Service Workers e pelo streaming de HTML, e chegámos agora a um ecossistema genuinamente maduro: a Speculation Rules API, o bfcache (Back/Forward Cache) e a View Transitions API. Juntas, estas tecnologias permitem transições de página em milissegundos — não em segundos.

O Chrome tem liderado esta revolução desde a versão 109. Em 2026, estas APIs estão estáveis, bem documentadas e já comprovadas em produção por alguns dos maiores sites do mundo. Então, vamos mergulhar em cada uma delas, com exemplos práticos que pode implementar já hoje.

Entendendo a Speculation Rules API

A Speculation Rules API é, na essência, uma forma declarativa de dizer ao navegador: "Olha, o utilizador provavelmente vai visitar esta página a seguir." Com base nessa indicação, o navegador pode pré-carregar (prefetch) ou pré-renderizar (prerender) essas páginas em segundo plano. Resultado? Navegação praticamente instantânea.

Prefetch vs. Prerender: Qual a Diferença?

Esta distinção é fundamental, por isso vale a pena explicar bem:

• Prefetch — Faz o download antecipado dos recursos da página (HTML, CSS, JavaScript, imagens), mas não os executa. Quando o utilizador navega, o navegador já tem os ficheiros em cache e só precisa de os processar. Ajuda bastante, mas não elimina totalmente o tempo de carregamento.
• Prerender — Aqui é que a magia acontece. Carrega a página completa num contexto oculto, executando todo o HTML, CSS e JavaScript. Quando o utilizador clica no link, o navegador simplesmente troca a página pré-renderizada para o primeiro plano. O LCP? Tipicamente perto de zero.

Claro que o prerender consome mais recursos. O Chrome impõe limites sensatos: até 50 prefetches e 10 prerenders ativos em simultâneo. Cabe-nos a nós escolher a estratégia certa para cada caso.

Como Funciona Internamente

Quando o navegador encontra regras de especulação, cria um processo interno que avalia as condições definidas. Para o prerender, é criado um hidden document — basicamente um documento completo numa aba invisível. Este documento tem restrições de segurança (nada de áudio, notificações push ou geolocalização). Quando a navegação acontece de facto, o documento pré-renderizado é promovido a visível, e a API document.prerendering muda de true para false.

Implementação Prática

Há duas formas principais de declarar regras de especulação: via tag <script type="speculationrules"> no HTML ou através do cabeçalho HTTP Speculation-Rules.

Regras Inline com Script Tag

A forma mais direta — e honestamente, a que uso na maioria dos projetos:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/produtos", "/sobre-nos", "/contacto"]
    }
  ],
  "prefetch": [
    {
      "urls": ["/blog", "/portfolio", "/precos"]
    }
  ]
}
</script>

Três páginas para prerender, três para prefetch. Simples. Note que as URLs têm de ser da mesma origem — não pode pré-renderizar páginas de domínios externos, por razões de segurança e privacidade.

Regras de Documento (Document Rules)

As document rules são bastante mais poderosas. Em vez de listar URLs uma a uma, define padrões que se aplicam automaticamente a todos os links correspondentes:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/admin/*" } },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Este exemplo configura prerender para todos os links internos, exceto a página de logout, o admin e links com a classe no-prerender. A condição where suporta operadores and, or e not, além de href_matches para URLs e selector_matches para seletores CSS.

Cabeçalho HTTP Speculation-Rules

Se não tem controlo direto sobre o HTML (CDNs, proxies reversos), pode usar um cabeçalho HTTP:

# Cabeçalho HTTP na resposta
Speculation-Rules: "/speculation-rules.json"

O ficheiro JSON referenciado precisa do tipo MIME application/speculationrules+json:

// /speculation-rules.json
{
  "prefetch": [
    {
      "where": {
        "href_matches": "/artigos/*"
      },
      "eagerness": "moderate",
      "referrer_policy": "no-referrer"
    }
  ],
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "selector_matches": "[data-no-prerender]" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}

A vantagem? Pode fazer cache do ficheiro de regras separadamente do HTML e gerir tudo de forma centralizada em aplicações de grande escala.

Níveis de Eagerness

Um dos aspetos mais importantes da Speculation Rules API é o controlo sobre quando a especulação arranca. A propriedade eagerness tem quatro níveis — e escolher o certo faz toda a diferença.

immediate

A especulação começa imediatamente após a análise das regras. Sem esperar por interação nenhuma. Use apenas quando tem certeza absoluta de que o utilizador vai navegar (por exemplo, no próximo passo de um checkout).

eager

Semelhante ao immediate, mas com uma ligeira otimização interna. Na prática, o comportamento é quase idêntico.

moderate

A especulação ativa quando o utilizador faz hover sobre um link durante 200ms ou faz pointerdown. Honestamente, este é o sweet spot para a maioria dos sites — a intenção do utilizador já está parcialmente confirmada sem desperdiçar recursos.

conservative

Ativa apenas no pointerdown ou touchstart — o momento exato em que o utilizador começa a clicar. Menor risco de desperdício, mas também menor ganho (a janela é de apenas 100-200ms).

A minha recomendação: Comece com moderate para prerender e eager para prefetch. Ajuste com base em dados reais. O conservative é ideal como primeira camada numa estratégia progressiva, e o immediate deve ficar reservado para cenários de alta confiança.

Um detalhe importante: nas list rules (com URLs explícitas), o eagerness predefinido é immediate. Nas document rules, é conservative. Faz sentido — se especificou URLs concretas, provavelmente sabe o que está a fazer. Regras genéricas merecem mais cautela.

bfcache (Back/Forward Cache)

O bfcache é uma daquelas funcionalidades que muitos developers subestimam. Basicamente, o navegador guarda um snapshot completo da página em memória quando o utilizador sai. Quando carrega no botão voltar ou avançar, a página é restaurada instantaneamente — sem recarregar recursos nem re-executar JavaScript.

A boa notícia? Todos os navegadores modernos suportam o bfcache. A má notícia? Certas práticas comuns de desenvolvimento podem impedir que as suas páginas beneficiem dele.

Técnicas de Otimização para o bfcache

Evitar o Evento unload

Este é o principal vilão. Páginas com listeners de unload são automaticamente excluídas do bfcache na maioria dos navegadores. A solução é simples — use pagehide e pageshow:

// ❌ NÃO FAÇA ISTO — bloqueia o bfcache
window.addEventListener('unload', () => {
  // Lógica de limpeza
  analytics.sendBeacon('/log-saida');
});

// ✅ FAÇA ISTO — compatível com o bfcache
window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    // A página está a ser colocada no bfcache
    console.log('Página armazenada no bfcache');
  } else {
    // A página está realmente a ser descarregada
    analytics.sendBeacon('/log-saida');
  }
});

// Detetar restauração do bfcache
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // A página foi restaurada do bfcache
    console.log('Restaurada do bfcache!');
    // Atualizar dados que possam estar obsoletos
    atualizarTimestamps();
    verificarEstadoSessao();
  }
});

Cabeçalhos Cache-Control

Outro ponto que apanha muita gente de surpresa: os cabeçalhos Cache-Control também afetam a elegibilidade para o bfcache. Respostas com Cache-Control: no-store podem ser excluídas em certos navegadores. Se precisa de desativar o cache HTTP sem prejudicar o bfcache, use no-cache:

# Compatível com bfcache — permite revalidação
Cache-Control: no-cache, must-revalidate

# Pode bloquear o bfcache em alguns navegadores
Cache-Control: no-store

Outras Boas Práticas

• Fechar conexões abertas — WebSockets, EventSource e ligações IndexedDB ativas podem impedir o bfcache. Feche-as no pagehide e reabra-as no pageshow.
• Evitar window.opener — Use rel="noopener" nos links que abrem novas janelas.
• Cuidado com o beforeunload — Registe-o apenas quando existem alterações não guardadas e remova-o assim que possível.
• Testar regularmente — O Chrome DevTools tem um painel dedicado (Application > Back/forward cache) que vale a pena conhecer.

Atualizar Estado Após Restauração

Quando uma página volta do bfcache, o estado JavaScript está todo preservado — mas pode estar desatualizado. Isto é crucial, especialmente para sessões e dados dinâmicos:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Verificar se a sessão do utilizador ainda é válida
    fetch('/api/sessao/verificar', { method: 'HEAD' })
      .then(response => {
        if (response.status === 401) {
          window.location.reload();
        }
      });

    // Atualizar conteúdo dinâmico
    fetch('/api/notificacoes/contagem')
      .then(r => r.json())
      .then(data => {
        document.querySelector('.badge-notificacoes').textContent = data.total;
      });

    // Re-inicializar analytics para a nova pageview
    if (typeof gtag !== 'undefined') {
      gtag('event', 'page_view', {
        page_location: window.location.href,
        page_title: document.title
      });
    }
  }
});

Prerendering na Prática: Resultados Reais

Tudo isto é bonito na teoria, mas funciona mesmo? Sim. E os números falam por si.

Google Search

A equipa do Google Search implementou prerendering nas páginas de resultados. O resultado: redução de 67ms no LCP em dispositivos Android. Pode parecer pouco, mas num site com biliões de pageviews diários, cada milissegundo conta. E o melhor — esta melhoria não custou dados adicionais ao utilizador, porque o navegador só pré-renderiza quando tem confiança na navegação.

Scalemates

O Scalemates (um popular site de referência para modelistas) registou resultados ainda mais expressivos: o P95 do LCP melhorou em 500ms. Meio segundo de melhoria para os utilizadores com as piores experiências — isso é uma diferença que se sente.

Considerações de Memória

O prerendering consome memória — cada página pré-renderizada é um documento completo. Mas o Chrome é inteligente nesta gestão:

• Limite de 10 prerenders simultâneos
• Limite de 50 prefetches simultâneos
• Eviction automática — quando a memória aperta, o navegador descarta prerenders mais antigos ou menos prováveis
• Respeito pelo Data Saver — em modo de economia de dados, o prerendering pode ser reduzido ou desativado

Dica prática: Páginas muito pesadas (muitas imagens, vídeos, scripts complexos) ficam melhor com prefetch do que com prerender. Reserve o prerender para páginas leves e de alta probabilidade de navegação.

Lidar com Páginas Pré-renderizadas no JavaScript

Certas ações não devem acontecer durante o prerender — analytics, por exemplo. Felizmente, a API dá-nos as ferramentas necessárias:

// Verificar se a página está atualmente em prerender
if (document.prerendering) {
  console.log('Esta página está a ser pré-renderizada');
}

// Executar código apenas quando a página se tornar ativa
document.addEventListener('prerenderingchange', () => {
  // O prerendering terminou — a página agora está visível
  inicializarAnalytics();
  carregarChatWidget();
  iniciarAnimacoes();
});

// Padrão robusto para ambos os cenários
function quandoAtiva(callback) {
  if (!document.prerendering) {
    callback();
  } else {
    document.addEventListener('prerenderingchange', callback, { once: true });
  }
}

// Uso
quandoAtiva(() => {
  // Este código só executa quando a página é visível
  fetch('/api/analytics/pageview', {
    method: 'POST',
    body: JSON.stringify({
      pagina: window.location.pathname,
      timestamp: Date.now()
    })
  });
});

View Transitions API: Transições Visuais Suaves

A View Transitions API é o complemento perfeito da Speculation Rules API. Enquanto uma torna a navegação rápida, a outra torna-a elegante. E quando as duas trabalham juntas? O resultado é quase mágico.

Transições entre Documentos (Cross-Document)

Desde o Chrome 126, as transições visuais funcionam entre páginas diferentes — não apenas dentro de SPAs. Para ativar, basta uma meta tag e algum CSS:

<!-- Ativar view transitions cross-document -->
<meta name="view-transition" content="same-origin" />

<style>
/* Animação padrão de fade */
::view-transition-old(root) {
  animation: fade-out 0.2s ease-in;
}

::view-transition-new(root) {
  animation: fade-in 0.3s ease-out;
}

@keyframes fade-out {
  from { opacity: 1; }
  to { opacity: 0; }
}

@keyframes fade-in {
  from { opacity: 0; }
  to { opacity: 1; }
}

/* Transição personalizada para imagens de produto */
.produto-imagem {
  view-transition-name: produto-hero;
}

::view-transition-old(produto-hero) {
  animation: scale-down 0.3s ease-in;
}

::view-transition-new(produto-hero) {
  animation: scale-up 0.3s ease-out;
}

@keyframes scale-down {
  from { transform: scale(1); }
  to { transform: scale(0.8); opacity: 0; }
}

@keyframes scale-up {
  from { transform: scale(0.8); opacity: 0; }
  to { transform: scale(1); opacity: 1; }
}
</style>

Combinado com prerendering, o efeito é extraordinário: clique, transição suave, página nova instantaneamente. É o tipo de experiência que faz os utilizadores pensarem "isto parece uma app nativa."

Boas Práticas com View Transitions

• Transições curtas — Entre 200ms e 400ms. Mais do que isso e parece lento.
• Respeitar preferências — Use @media (prefers-reduced-motion: reduce) para quem prefere menos movimento.
• Nomes estratégicos — Cada view-transition-name deve ser único na página. Atribua nomes apenas onde realmente precisa de transições personalizadas.
• Testar em dispositivos reais — GPUs limitadas podem comportar-se de forma inesperada.

Monitoramento e Debug

Implementar estas técnicas sem monitorização é como conduzir de olhos fechados. Felizmente, as ferramentas disponíveis são excelentes.

Chrome DevTools: Painel Application

No painel Application, existe uma secção "Speculative loads" que mostra tudo o que precisa de saber:

• Regras de especulação ativas na página
• Estado de cada especulação (pendente, em execução, concluída, cancelada)
• Motivo de cancelamento, quando aplicável
• Recursos carregados em cada prefetch ou prerender

Chrome DevTools: Painel Performance

No painel Performance, as navegações pré-renderizadas aparecem com indicações visuais distintas. Pode ver o momento do início, a duração total, quando o utilizador clicou e a diferença efetiva no LCP.

Verificação do bfcache

O painel Application > Back/forward cache permite testar a elegibilidade de qualquer página. Se não for elegível, o DevTools explica porquê — uso de unload, WebSockets ativos, Cache-Control: no-store, etc.

PageSpeed Insights e CrUX

O PageSpeed Insights e o CrUX já refletem os benefícios do prerendering nos dados de campo. Quando uma página é pré-renderizada, os Core Web Vitals medidos incluem o tempo de ativação, resultando em métricas bastante melhores. São ferramentas indispensáveis para validar o impacto real.

Monitorização Programática

Para quem quer ir mais fundo, a Performance API permite monitorizar tudo por código:

// Verificar se a navegação atual foi pré-renderizada
const navEntry = performance.getEntriesByType('navigation')[0];

if (navEntry.activationStart > 0) {
  console.log('Esta página foi pré-renderizada!');
  console.log(`Tempo de ativação: ${navEntry.activationStart}ms`);

  // Calcular o LCP ajustado
  const observador = new PerformanceObserver((lista) => {
    const entradas = lista.getEntries();
    const ultimaEntrada = entradas[entradas.length - 1];
    const lcpAjustado = ultimaEntrada.startTime - navEntry.activationStart;
    console.log(`LCP ajustado (pós-ativação): ${lcpAjustado}ms`);
  });
  observador.observe({ type: 'largest-contentful-paint', buffered: true });
}

// Monitorizar todas as especulações
if ('PerformanceSpeculationRulesEntry' in window) {
  const obsEspec = new PerformanceObserver((lista) => {
    for (const entrada of lista.getEntries()) {
      console.log(`Especulação: ${entrada.name}`);
      console.log(`Tipo: ${entrada.entryType}`);
      console.log(`Duração: ${entrada.duration}ms`);
    }
  });
  obsEspec.observe({ type: 'speculation-rules' });
}

Impacto nos Core Web Vitals

Vamos ao que interessa a toda a gente: como é que estas técnicas afetam as métricas que o Google realmente usa para classificar o seu site?

LCP (Largest Contentful Paint)

O LCP é, sem dúvida, a métrica que mais beneficia. Com prerendering, a página já está completamente renderizada quando o utilizador navega — o LCP efetivo pode ser literalmente de zero milissegundos. O prefetch também ajuda, embora de forma menos dramática, ao eliminar o tempo de download.

O bfcache tem um efeito semelhante para navegações de retrocesso/avanço: restauração instantânea, LCP próximo de zero.

INP (Interaction to Next Paint)

O INP beneficia indiretamente. Com prerendering, todo o JavaScript já foi executado — event listeners inicializados, código compilado. Quando o utilizador interage pela primeira vez, o thread principal está mais livre para responder.

Mas atenção: o prerendering não é solução mágica para INP. Se os seus event handlers são lentos, vão continuar lentos. O prerendering apenas garante que o carregamento inicial não compete com as interações do utilizador.

CLS (Cumulative Layout Shift)

O impacto no CLS é subtil mas real. Com prerendering, todos os recursos (imagens, fontes) já estão carregados quando a página fica visível. Adeus à troca de fontes (FOIT/FOUT) e ao carregamento tardio de imagens sem dimensões definidas — duas fontes clássicas de layout shifts.

A View Transitions API também contribui, oferecendo transições controladas em vez de saltos abruptos de conteúdo.

Estratégia em Camadas: A Abordagem de Harry Roberts

Harry Roberts, um dos consultores de performance web mais respeitados da comunidade, propôs uma abordagem em camadas que, na minha opinião, é a forma mais sensata de implementar a Speculation Rules API. A ideia é simples: comece pelo seguro e vá aumentando a agressividade conforme os dados justifiquem.

Camada 1: Base Conservadora

Primeiro, aplique prerender apenas quando o utilizador demonstra intenção clara (pointerdown/touchstart):

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "selector_matches": "[data-no-prerender]" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Baixo risco, ganho consistente. O prerender só ativa frações de segundo antes da navegação.

Camada 2: Hover Moderado

Depois, acrescente prerender no hover para ampliar a janela de oportunidade:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } },
          { "not": { "selector_matches": "[data-no-prerender]" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

O tempo médio entre hover e clique é de 300-400ms. São 200ms de hover que dão ao navegador uma janela preciosa para completar o prerender.

Camada 3: Páginas de Alta Confiança

Para páginas onde a probabilidade de navegação é muito alta, vá com immediate:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/checkout/confirmacao"],
      "eagerness": "immediate"
    }
  ],
  "prefetch": [
    {
      "where": {
        "href_matches": "/produtos/*"
      },
      "eagerness": "eager"
    }
  ]
}
</script>

Um detalhe elegante: múltiplas tags <script type="speculationrules"> podem coexistir na mesma página. O navegador combina tudo automaticamente, o que significa que diferentes equipas podem adicionar as suas regras sem conflitos.

A Importância dos Dados

Harry Roberts insiste — e com razão — que cada camada deve ser justificada por dados. Antes de aumentar o eagerness, pergunte-se:

• Taxa de acerto — Que percentagem das especulações resulta em navegações efetivas?
• Impacto no LCP — Qual a melhoria real nos Core Web Vitals?
• Consumo de recursos — Qual o impacto na largura de banda e memória dos utilizadores?
• Custo do servidor — O aumento de pedidos é sustentável?

Compatibilidade e Fallbacks

Vamos ser honestos: a Speculation Rules API só funciona em navegadores Chromium — Chrome, Edge, Opera e Samsung Internet. Firefox e Safari ainda não a implementaram (em fevereiro de 2026). Mas isto não deve impedir a adoção.

Progressive Enhancement

A beleza desta API é que funciona como progressive enhancement puro. Navegadores que não a suportam simplesmente ignoram a tag <script type="speculationrules">. Sem erros, sem impacto negativo. Os utilizadores desses navegadores têm a experiência normal; os restantes ganham navegação instantânea.

Se quiser um fallback mais ativo para navegadores sem suporte:

<script>
// Verificar suporte da Speculation Rules API
if (!HTMLScriptElement.supports ||
    !HTMLScriptElement.supports('speculationrules')) {

  // Fallback: usar <link rel="prefetch"> tradicional
  document.querySelectorAll('a[href^="/"]').forEach(link => {
    link.addEventListener('mouseenter', () => {
      const prefetchLink = document.createElement('link');
      prefetchLink.rel = 'prefetch';
      prefetchLink.href = link.href;
      document.head.appendChild(prefetchLink);
    }, { once: true });
  });

  console.log('Speculation Rules API não suportada. Usando prefetch como fallback.');
} else {
  console.log('Speculation Rules API suportada!');
}
</script>

Tabela de Compatibilidade (Fevereiro 2026)

• Chrome 109+ — Suporte completo (prefetch e prerender)
• Edge 109+ — Suporte completo (baseado em Chromium)
• Opera 95+ — Suporte completo (baseado em Chromium)
• Samsung Internet 21+ — Suporte completo
• Firefox — Sem suporte (a tag é ignorada de forma segura)
• Safari — Sem suporte (a tag é ignorada de forma segura)

Para o bfcache, a situação é bem melhor: todos os navegadores modernos o suportam. As boas práticas deste artigo (evitar unload, usar pagehide/pageshow) são universais.

A View Transitions API cross-document está no Chrome 126+ e Chromium correspondentes. Para Safari e Firefox, pode recorrer a CSS puro ou bibliotecas como Barba.js ou Swup.

Armadilhas Comuns e Como Evitá-las

Depois de implementar estas técnicas em vários projetos, posso dizer que há erros que aparecem repetidamente. Aqui ficam os mais frequentes:

1. Pré-renderizar Páginas com Side Effects

Nunca pré-renderize páginas que fazem coisas irreversíveis ao carregar — confirmar encomendas, enviar emails, processar pagamentos. A ação seria executada antes do utilizador sequer navegar para a página. Use data-no-prerender ou exclua essas URLs nas regras.

2. Ignorar o Estado de Prerendering em Analytics

Se o seu código de analytics corre durante o prerender, vai registar pageviews fantasma. Páginas que o utilizador nunca visitou de facto. Use sempre document.prerendering ou o evento prerenderingchange antes de disparar eventos.

3. Uso Excessivo de immediate

Configurar dezenas de páginas com eagerness: "immediate" vai sobrecarregar a largura de banda do utilizador e o seu servidor. Limite o immediate a 2-3 páginas, no máximo.

4. Não Testar em Dispositivos com Pouca Memória

O Chrome faz gestão automática, sim. Mas testar em dispositivos de gama baixa e média continua a ser essencial para garantir que a experiência não degrada.

5. Esquecer de Atualizar as Regras

As regras de especulação devem evoluir com o site. Mudou a estrutura de URLs? Adicionou secções novas? Atualize as regras. Melhor ainda: gere-as dinamicamente no servidor com base em dados de navegação reais.

Conclusão e Recomendações

A navegação instantânea em 2026 não é ficção científica — é uma realidade acessível a qualquer developer com as ferramentas certas. O trio Speculation Rules API + bfcache + View Transitions API dá-nos tudo o que precisamos.

Para resumir as recomendações principais:

1. Comece pelo bfcache — Maior impacto, menor esforço. Remova os listeners de unload, use pagehide/pageshow, verifique a elegibilidade no DevTools. Funciona em todos os navegadores.
2. Implemente a Speculation Rules API em camadas — Comece com conservative, passe para moderate, use immediate só para páginas de alta confiança.
3. Prefira document rules a list rules — Adaptam-se automaticamente a novos links, menos manutenção.
4. Adicione View Transitions — Para criar aquela sensação de app nativa que os utilizadores adoram.
5. Monitorize sempre — DevTools, CrUX e ferramentas de RUM. Meça o impacto real e ajuste a estratégia.
6. Progressive enhancement — A Speculation Rules API é só Chromium. Garanta que a experiência base é sólida para todos os navegadores.
7. Proteja-se contra side effects — Use document.prerendering para adiar analytics, publicidade e outras ações sensíveis.

As ferramentas estão maduras, os padrões estáveis e os resultados comprovados. Não há razão para não começar hoje.

Em resumo: Speculation Rules API para navegações futuras, bfcache para o botão voltar e View Transitions para continuidade visual — esta é a trifeta da navegação web moderna. Quando aplicadas em conjunto e com estratégia, estas tecnologias transformam qualquer site numa experiência que rivaliza com apps nativas.