Páginas com Carregamento Instantâneo usando Speculation Rules

Aprenda como melhorar o Core Web Vitals fazendo com que as páginas carreguem instantaneamente com a Speculation Rules API

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-26

Melhore instantaneamente o Core Web Vitals com a Speculation Rules API

Já se perguntou por que algumas páginas parecem carregar instantaneamente? Provavelmente é porque essa página implementou Speculation Rules!

A Speculation Rules API melhora a velocidade de futuros carregamentos de página em aplicações de múltiplas páginas (MPAs) fazendo o prefetch ou até mesmo o prerender delas. Os desenvolvedores podem configurar speculation rules para sugerir ao navegador o prefetch ou prerender de documentos para carregamentos de página mais rápidos (ou instantâneos). As speculation rules substituem técnicas mais antigas como <link rel="prefetch"> para o prefetch de recursos ou a obsoleta <link rel="prerender">, exclusiva do Chrome.

As speculation rules funcionam no nível do documento, tornando-as adequadas para MPAs que envolvem navegações de página completas. Single-page applications (SPAs) que usam principalmente chamadas de API ou atualizações parciais de conteúdo não se beneficiariam tanto desta API para suas mudanças de rota internas. No entanto, Speculation Rules ainda podem beneficiar SPAs fazendo o prerender do estado inicial da aplicação a partir de uma landing page, potencialmente compensando o tempo de carregamento inicial.

Revisado por último por Arjen Karel em fevereiro de 2026

Guia de Início Rápido do Speculation Rules

Já sabe o que são as speculation rules? Incrível! Aqui estão alguns snippets prontos para você começar imediatamente. Basta escolher o snippet certo para você e colocá-lo no <head> da sua página (sinta-se à vontade para alterar prerender para prefetch e/ou o eagerness)!

<!--
   WordPress speculation rules por corewebvitals.io
   faz prefetch de todos os links internos
   ignora links que correspondem a wp-login, wp-admin, wp content
   ignora links que têm o atributo nofollow
   ignora links que têm uma query string, por exemplo: /search?q=welcome
-->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "and": [
                { "href_matches": "\\/*" },
                { "not": {
                    "href_matches": [
                        "\\/wp-login.php",
                        "\\/wp-admin\\/*",
                        "\\/*\\\\?*",
                        "\\/wp-content\\/*"
                    ]
                }},
                { "not": {
                    "selector_matches": "a[rel~=\\"nofollow\\"]"
                }}
            ]
        },
        "eagerness": "moderate"
    }]
}
</script>
<!-- Speculation rules acionadas por data-preload por corewebvitals.io -->
<script type="speculationrules">
{
    "prefetch": [{
        "source": "document",
        "where": {
            "selector_matches": "a[data-preload]"
        },
        "eagerness": "moderate"
    }]
}
</script>

Dica: se você precisa construir rapidamente suas próprias speculation rules, por que não experimentar o <b>gerador de speculation rules</b>

Impacto no mundo real

As speculation rules não são teóricas. Os maiores nomes da web já as estão utilizando com resultados mensuráveis.

A Ray-Ban implementou regras de prerender em suas páginas de listagem de produtos com eagerness moderado. O LCP caiu de 4.69 segundos para 2.66 segundos em dispositivos móveis (43% mais rápido). As taxas de conversão em dispositivos móveis aumentaram em 101% e as conversões em desktop em 156%.

A Shopify lançou o prefetch conservador em toda a sua plataforma em junho de 2025. Seus testes A/B mostraram uma melhoria média de 130ms no desktop e 180ms em dispositivos móveis em todas as métricas de renderização.

O Cloudflare Speed Brain, lançado em setembro de 2024, adiciona speculation rules a todos os planos da Cloudflare por padrão. Sites com prefetches bem-sucedidos viram uma redução de 45% no LCP.

Até mesmo a Pesquisa do Google usa speculation rules: os resultados de pesquisa têm prefetch com eagerness eager, economizando 67ms no LCP do Android por clique.

Em sites monitorados pelo CoreDash, navegações com prerender têm um LCP p75 de 320ms em comparação com 1.800ms para navegações padrão nos mesmos sites. Isso é uma melhoria de 82% com uma única API. Sites usando speculation rules com eagerness moderado veem aproximadamente 28% das navegações com sucesso de prefetch ou prerender. Navegações com prefetch mostram um p75 de TTFB de apenas 45ms, porque o HTML já está no cache de memória do navegador.

Benefícios das Speculation Rules

Melhoria na user experience (UX): Ao prever e pré-carregar conteúdo, as Speculation Rules garantem carregamentos de página quase instantâneos, fazendo a navegação parecer contínua para os usuários. Isso rivaliza com o desempenho de single-page applications mesmo para sites tradicionais de múltiplas páginas sem a complexidade e a dependência de JavaScript. Tempos de carregamento mais rápidos significam uma melhor experiência de navegação, provavelmente aumentando o engajamento do usuário e reduzindo as taxas de rejeição.

Vantagens de SEO: Como uma melhor velocidade de página é um fator direto de ranqueamento e um melhor Time to First Byte resultará em um melhor Largest Contentful Paint, a implementação de speculation rules certamente melhorará o Core Web Vitals e dará a você esse bônus de PageSpeed.

Complexidade reduzida: Carregamentos de página quase instantâneos costumavam ser possíveis apenas usando uma SPA ou escrevendo uma lógica de prefetch personalizada para MPAs. Para muitos casos de uso, a desvantagem de uma SPA é o tempo de inicialização, que pode ser considerável já que dependem fortemente de JavaScript, e a complexidade aumentada em comparação com uma MPA. As speculation rules não têm esses problemas. Isso torna o carregamento rápido alcançável para uma gama mais ampla de sites, especialmente os focados em conteúdo.

A API também simplifica o processo de decisão sobre quais páginas devem receber prerender delegando grande parte da lógica para o navegador. Isso é uma enorme melhoria em relação aos métodos anteriores que dependiam de JavaScript para fazer essas verificações e injetar páginas para pré-carregar. Navegadores podem nativamente considerar o contexto do usuário, como pouca memória em dispositivos móveis ou modo de economia de bateria, ao decidir se devem fazer o prerender. Essa adaptação dinâmica ajuda a conservar os recursos do usuário e garante uma experiência mais suave mesmo sob restrições.

Outros benefícios: O cabeçalho HTTP Speculation-Rules permite uma implementação mais fácil via Redes de Distribuição de Conteúdo (CDNs), eliminando a necessidade de modificar diretamente o conteúdo do documento. O controle granular com regras de documento permite que os desenvolvedores definam condições precisas para prefetch ou prerender baseadas em padrões de URL ou seletores CSS. Isso reduz a especificação manual de URL e permite conjuntos de speculation rules em todo o site. A configuração de "eagerness" fornece um controle refinado sobre quando a especulação ocorre, equilibrando a velocidade de pré-carregamento com o consumo de recursos. Isso ajuda a reduzir o pré-carregamento desnecessário e evita o desperdício de recursos.

Suporte de navegadores

As speculation rules são suportadas no Chrome 109+, Edge 109+ e em todos os navegadores baseados em Chromium. Isso cobre aproximadamente 79% do tráfego global de navegadores de acordo com o Can I Use. O Firefox declarou uma posição de padrões positiva para a parte de prefetch, mas ainda não lançou o suporte. O Safari 26.2 tem uma implementação funcional atrás de uma flag, mas não está habilitada por padrão.

Para navegadores que não suportam speculation rules, você pode usar a detecção de recursos para ter um fallback para <link rel="prefetch">:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  // o navegador suporta speculation rules
} else {
  // fallback: injetar <link rel="prefetch">
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page.html';
  document.head.append(link);
}

Mecânica das Speculation Rules

As speculation rules são definidas usando uma estrutura JSON e podem ser implementadas de duas maneiras:

  • Script Inline: Inclua o JSON dentro de uma tag <script type="speculationrules"> no <head> ou no <body> do documento HTML principal.
  • Cabeçalho HTTP: Entregue regras usando o cabeçalho HTTP Speculation-Rules na resposta do documento. Esse cabeçalho aponta para um arquivo JSON contendo as regras, facilitando implementações mais fáceis em CDN sem modificar diretamente o conteúdo HTML.

A estrutura JSON usa os arrays "prefetch" e "prerender" para conter as regras de cada tipo de carregamento especulativo. Cada regra pode usar diferentes fontes: seja uma lista de URLs ou regras de documento.

  • urls (uma lista de URLs): Um array de URLs para prefetch ou prerender.
  • where (regras de documento): Um objeto que usa condições para determinar quais links na página devem sofrer prefetch ou prerender.

Cada regra é definida como um objeto que inclui propriedades como:

  • requires: Um array de strings para definir restrições nas especulações. Atualmente, a única string válida é "anonymous-client-ip-when-cross-origin", indicando que um prefetch de origem cruzada (cross-origin) deve anonimizar o endereço IP do cliente.
  • target_hint: Uma string que fornece uma dica sobre o nome de destino navegável ("_self" ou "_blank"), permitindo ao user agent otimizar o processo de carregamento.
  • referrer_policy: Uma política de referrer a ser aplicada às URLs com prefetch ou prerender.
  • relative_to (apenas para fonte "list"): Especifica se as URLs fornecidas no array "urls" são relativas à URL base do documento ("document") ou à localização do arquivo JSON das speculation rules ("ruleset").
  • eagerness: Controla a agressividade com que o navegador deve fazer o prefetch ou prerender. As configurações disponíveis são "immediate", "eager", "moderate" e "conservative", cada uma com diferentes gatilhos.
  • expects_no_vary_search: Uma dica que informa ao navegador se a URL especulada deve ter uma resposta diferente baseada nos parâmetros de busca. Útil para páginas com parâmetros UTM ou outras query strings de rastreamento que não alteram o conteúdo.

Finalmente, cada regra tem uma configuração de eagerness que permite definir quando as especulações devem ser executadas, separando quando especular de quais URLs realizar as especulações. A configuração de eagerness está disponível tanto para regras de fonte de lista quanto de documento e tem quatro opções: immediate, eager, moderate e conservative.

  • immediate: Usado para especular o mais rápido possível, assim que as speculation rules forem observadas.
  • eager: No desktop, isso é acionado após passar o mouse (hover) sobre um link por 10 milissegundos. Em dispositivos móveis (a partir de janeiro de 2026), é acionado 50ms depois que um link entra na viewport.
  • moderate: Realiza as especulações se você passar o mouse sobre um link por 200 milissegundos (ou no evento pointerdown, se ocorrer antes, e em dispositivos móveis onde não há evento hover).
  • conservative: Especula no clique (pointer) ou toque na tela (touch down).

Limites do Chrome

O Chrome aplica limites a especulações simultâneas para evitar abusos e proteger os recursos do dispositivo:

  • immediate / eager: Até 50 prefetches e 10 prerenders.
  • moderate / conservative: Até 2 prefetches e 2 prerenders (FIFO: novas especulações substituem as mais antigas).

O Chrome também desativa a especulação por completo quando o modo Economia de Dados (Save Data) está ativado, o dispositivo está no modo de Economia de Energia com bateria fraca ou o usuário desativou a configuração "Pré-carregar páginas" (Preload pages).

Prefetch ou Prerender

A Speculation Rules API suporta duas formas principais de carregamento especulativo: prefetching e prerendering. Embora ambas as técnicas possam resultar em carregamentos de página mais rápidos, elas diferem em sua complexidade e consumo de recursos.

  • Prefetching é a forma mais leve de carregamento especulativo. Ele faz o download e o cache do HTML da URL de destino sem renderizar a página ou seus subrecursos. Essa abordagem melhora principalmente o Time to First Byte. Um Time to First Byte melhorado levará a melhores métricas de renderização como o Largest Contentful Paint e First Contentful Paint.
  • Prerendering faz muito mais do que apenas baixar o HTML. Ele baixa o HTML, todos os subrecursos e renderiza a página inteira em uma guia oculta e invisível. Ao navegar para essa página, isso resulta em uma exibição quase instantânea. Essa técnica melhora o Largest Contentful Paint de mais maneiras do que apenas melhorando o Time to First Byte. Ela também faz o download e renderiza o elemento do LCP. O Prerendering também pode eliminar o Cumulative Layout Shift porque as dimensões dos recursos já são conhecidas após o prerendering.

Há também uma terceira opção: prerender until script. Este novo recurso (Chrome 144, janeiro de 2026) busca o HTML, começa a renderização e o carregamento de subrecursos, mas pausa a execução do JavaScript na primeira tag de script de bloqueio. Isso elimina os efeitos colaterais de scripts (como o disparo de analytics) enquanto ainda pré-carrega CSS, imagens e fontes.

Então o que é melhor? Prerendering ou Prefetching? Isso depende da página e do visitante médio. Enquanto o prerendering pode ser mais rápido por design, ele também usa muito mais recursos, tanto no cliente quanto no servidor. A escolha por prerendering ou prefetching depende de:

  • Capacidades do dispositivo do usuário: O prerendering pode não ser a melhor escolha se uma alta porcentagem de visitantes acessar através de dispositivos com memória limitada.
  • Especificidade da regra de prerender ou prefetch. Alguns links têm maior probabilidade de serem clicados e algumas páginas têm maior probabilidade de converter. Essas páginas são as candidatas perfeitas para uma regra de prerender. Outras páginas podem ser mais adequadas para prefetch.

Eu alertaria contra o uso excessivo de prerendering devido à sua demanda por recursos, particularmente em dispositivos móveis ou conexões mais lentas. Os benefícios potenciais do prerendering devem ser pesados contra o risco de degradação de desempenho e desperdício de recursos.

Definindo o eagerness correto

Qual configuração de eagerness usar depende do seu site. Para um site estático muito simples, especular com mais eagerness pode ter um baixo custo e ser benéfico para os usuários. Sites com arquiteturas mais complexas e payloads de página mais pesados podem preferir reduzir o desperdício especulando com menos frequência até obterem um sinal positivo de intenção mais claro dos usuários, para limitar o desperdício.

A configuração de eagerness na Speculation Rules API influencia quando um navegador deve fazer prefetch ou prerender de conteúdo com base na navegação prevista do usuário. Essa configuração oferece um compromisso entre maximizar os benefícios de pré-carregamento e minimizar o desperdício de recursos.

O eagerness padrão para regras de lista é immediate. As opções moderate e conservative podem ser usadas para limitar regras de lista às URLs com as quais um usuário interage em uma lista específica. Em muitos casos, regras de documento com uma condição where apropriada podem ser mais adequadas.

O eagerness padrão para regras de documento é conservative. Dado que um documento pode consistir de muitas URLs, o uso de immediate ou eager para regras de documento deve ser feito com cautela.

Ao configurar o eagerness, os desenvolvedores devem levar em consideração a user experience, os custos de recursos e as limitações do navegador. O excesso de especulação pode sobrecarregar a largura de banda, a memória e a CPU do usuário, possivelmente degradando o desempenho, especialmente em redes ou dispositivos com restrições. Além disso, fatores como modos de Economia de Dados (Save Data) configurados pelo usuário, condições de bateria fraca ou extensões do navegador podem anular as speculation rules, priorizando a conservação de recursos.

Verificando e depurando speculation rules

Para verificar qualquer speculation rule em uma página, abra o Chrome DevTools, vá até o painel Application e navegue até Background Services > Speculative Loads > Speculations. (abra o painel Speculations antes de carregar a página que você deseja depurar). Este painel fornece informações sobre:

  • O número de especulações bem-sucedidas.
  • URLs individuais sofrendo prerender ou prefetch.
  • O status de cada especulação.

A faixa de Network no painel Performance exibe a atividade de rede relacionada aos recursos com prerender sem a necessidade de trocar o contexto do DevTools. Além disso, você pode mudar o contexto do DevTools para uma página com prerender para inspecioná-la como uma página normal.

Monitorando e analisando Speculation Rules

  • Real User Monitoring (RUM): Use ferramentas de RUM para medir a user experience real. Observe métricas como o Largest Contentful Paint (LCP) para avaliar o impacto das speculation rules nos tempos de carregamento da página. Procure por melhorias no LCP para páginas com prerender em comparação com páginas sem prerender.
  • Teste A/B: Conduza testes A/B para comparar diferentes configurações de speculation rules e identificar a configuração ideal para o seu site e base de usuários específicos.

Considerações

Consumo de Recursos: O uso excessivo de especulação pode impactar negativamente o uso de largura de banda, memória e CPU. Comece com um eagerness conservative ou moderate e monitore os resultados antes de aumentar.

Compatibilidade de Navegadores: Nem todos os navegadores suportam totalmente a Speculation Rules API. Use o código de detecção de recursos acima para fornecer um fallback para navegadores não baseados em Chromium.

Privacidade: Os desenvolvedores devem estar atentos a como as speculation rules podem revelar padrões de navegação do usuário e implementar medidas de privacidade apropriadas. Para prefetch de origem cruzada (cross-origin), use o requisito "anonymous-client-ip-when-cross-origin" para mascarar o IP do cliente através do proxy de prefetch privado do Chrome.

Analytics: Páginas com prerender executam JavaScript, o que significa que os scripts de analytics serão disparados antes de o usuário realmente navegar. O Google Analytics e a Google Publisher Tag lidam com isso automaticamente. Para outras ferramentas de analytics, atrase a inicialização até que a página seja ativada:

if (document.prerendering) {
  document.addEventListener('prerenderingchange', function() {
    initAnalytics();
  }, { once: true });
} else {
  initAnalytics();
}

A Speculation Rules API oferece uma abordagem poderosa para aprimorar o desempenho e a user experience de aplicações web. Ao entender sua mecânica, benefícios e considerações, os desenvolvedores podem usar esta API para construir sites mais rápidos e envolventes.

Speculation Rules e WordPress

Desde o WordPress 6.8 (abril de 2025), as speculation rules estão integradas no núcleo (Core) do WordPress. A configuração padrão usa prefetch com eagerness conservative, aplicada a todas as páginas de frontend quando o visitante não está logado e os permalinks estão ativados.

A equipe de WordPress Core Performance também mantém um plugin de Speculative Loading independente (mais de 40.000 instalações ativas) que oferece mais controle. O plugin fornece dois grupos de configurações:

  • Speculation Mode: Escolha entre prefetch e prerender. O prerendering resultará em tempos de carregamento mais rápidos do que o prefetching. No entanto, o prefetching pode ser uma escolha mais segura para conteúdo interativo.
  • Eagerness: Escolha entre conservative (tipicamente no clique), moderate (tipicamente no hover), ou eager (na menor sugestão). A configuração de eagerness determina quão rapidamente os carregamentos especulativos são acionados.

Você pode excluir caminhos específicos da especulação usando um filtro PHP:

add_filter(
  'plsr_speculation_rules_href_exclude_paths',
  function($paths) {
    $paths[] = '/cart/*';
    $paths[] = '/checkout/*';
    return $paths;
  }
);

Para mais maneiras de adiar scripts e otimizar o carregamento, veja nosso guia completo.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

Fiz o CoreDash pras minhas próprias auditorias.

Menos de 1KB. Hospedado na UE. Sem banner de cookies. Agora com suporte a MCP.

Testa o CoreDash grátis
Páginas com Carregamento Instantâneo usando Speculation RulesCore Web Vitals Páginas com Carregamento Instantâneo usando Speculation Rules