O que é Speculative Loading? Como o WordPress carrega páginas antes do clique

Você clica em um link e a próxima página simplesmente já está lá. Nada de tela branca, nada de espera. Por trás disso, muitas vezes não há um servidor mais rápido, e sim um navegador que se antecipou. É exatamente isso o Speculative Loading: o navegador tenta adivinhar qual página você vai abrir em seguida e já começa a carregar essa página de antemão. Se acertar, a troca de página parece instantânea. Se errar, baixou alguns kilobytes à toa. Desde o WordPress 6.8, essa técnica faz parte do próprio WordPress, e muitos donos de sites nem sabem que o site deles já usa esse recurso. Aqui você descobre como tudo isso funciona, o que o WordPress configura por padrão e quando vale a pena fazer ajustes.

O que é Speculative Loading? Uma explicação simples

Speculative Loading, em português algo como carregamento especulativo, é o termo geral para as técnicas que permitem ao navegador solicitar páginas antes que alguém de fato as abra. Especulativo porque ninguém sabe ao certo se o visitante vai mesmo clicar no link. O navegador faz uma aposta.

Imagine a atendente atenta daquela cafeteria onde você sempre toma café. Ela vê você entrando pela porta e já começa a preparar o seu cappuccino antes mesmo de você pedir. Na maioria das vezes ela acerta, e você recebe o café sem esperar. Se um dia você resolve pedir um chá, o cappuccino foi feito à toa. O Speculative Loading funciona mais ou menos assim.

A ideia não é nova. Há anos já existiam <link rel="prefetch"> e <link rel="prerender">, dicas com as quais os sites podiam recomendar ao navegador páginas para carregar antecipadamente, e bibliotecas como instant.page ou Quicklink faziam o mesmo via JavaScript. Nada disso era realmente confiável. O Chrome inclusive substituiu há muito tempo o antigo rel="prerender" por uma variante simplificada que nem renderiza mais nada. Por isso, quando se fala hoje em Speculative Loading, quase sempre o assunto é a Speculation Rules API, que o Google introduziu no Chrome.

E por que todo esse esforço? Porque o tempo de carregamento entra diretamente nas Core Web Vitals. Se uma página é preparada por completo em segundo plano, o Largest Contentful Paint (LCP) para o visitante fica praticamente em zero. Mais rápido que isso, impossível.

Como funciona a Speculation Rules API?

O site passa ao navegador algumas regras. Elas ficam em formato JSON dentro de um bloco do tipo speculationrules. Veja como fica uma regra simples:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ]
}
</script>

Traduzindo: todos os links deste site podem ser renderizados previamente assim que o visitante demonstrar interesse, por exemplo ao deixar o mouse parado sobre o link por um instante. Regras desse tipo, que se referem aos links do documento, se chamam Document Rules. Além delas, existem as List Rules, em que você passa ao navegador uma lista fixa de URLs, como a próxima página de uma série de artigos.

Duas coisas tornam a API agradavelmente descomplicada. Primeiro, quem decide no fim se segue a regra é o navegador. Se a bateria estiver quase no fim ou a memória estiver apertada, ele simplesmente deixa para lá. Segundo, navegadores que não conhecem a API apenas ignoram esse bloco. Ou seja, nada pode quebrar. Aliás, em vez de ficarem no HTML, as regras também podem ser entregues por um cabeçalho na resposta do servidor (Speculation-Rules), algo que os CDNs usam bastante.

Prefetch ou prerender: qual é a diferença?

A Speculation Rules API tem dois modos, e a diferença entre eles é maior do que os nomes sugerem.

No prefetch, o navegador busca apenas o HTML puro da página de destino e o guarda por alguns instantes. Imagens, folhas de estilo e scripts ficam de fora, e nada é executado. Quando o visitante clica, ele economiza o tempo de espera pelo servidor, ou seja, basicamente o Time to First Byte. O resto o navegador carrega normalmente. O prefetch é barato e quase não tem efeitos colaterais.

No prerender, o navegador vai com tudo. Ele carrega a página completa, com imagens, CSS e JavaScript, em uma aba invisível e monta tudo por inteiro. No clique, ele simplesmente troca a página visível. Para o visitante, é como se a página sempre tivesse estado ali. O preço: mais consumo de dados, mais poder de processamento, e o JavaScript roda mesmo que o visitante talvez nunca chegue a ver a página. Por motivos de segurança, o prerender por padrão só funciona para páginas do mesmo domínio.

Como regra prática, vale o seguinte: o prefetch é a configuração básica segura, e o prerender é o turbo para páginas com grande chance de serem abertas em seguida.

Não confunda nenhum dos dois com preload e preconnect. Essas dicas aceleram arquivos da página atual, como fontes ou a maior imagem. O uso correto delas está explicado no nosso artigo sobre preload e preconnect para fontes e assets no WordPress.

Quando o navegador carrega antecipadamente? Os quatro níveis de eagerness

Com eagerness (em português, algo como avidez) você define com que antecedência o navegador pode começar. Quanto mais cedo, maior o ganho de tempo, mas também mais vezes ele erra o palpite.

• immediate: na hora, assim que o navegador lê a regra. Só faz sentido para um punhado de URLs sobre as quais você tem muita certeza.
• eager: quase tão cedo quanto. Nas versões mais recentes, o Chrome refinou esse comportamento, de modo que este nível fica entre immediate e moderate.
• moderate: no desktop, a especulação começa quando o ponteiro do mouse fica cerca de 200 milissegundos sobre um link, ou antes, se o botão do mouse for pressionado. Em smartphones, onde não existe hover, o Chrome usa outros sinais, como o toque na tela.
• conservative: só quando o visitante realmente clica, ou, mais precisamente, no momento em que o botão do mouse ou o dedo desce. Até o clique terminar, passa só uma fração de segundo. A vantagem é pequena, mas em compensação quase nenhuma especulação é desperdiçada.

Além disso, o próprio Chrome cuida para que ninguém exagere. Com moderate e conservative, o navegador mantém no máximo duas especulações ao mesmo tempo e descarta a mais antiga assim que surge uma nova. Com immediate e eager, são permitidos até 50 prefetches e 10 prerenders. No modo de economia de energia, com a economia de dados ativada, com pouca memória disponível ou quando o usuário desativou o carregamento antecipado de páginas nas configurações, o Chrome não especula de jeito nenhum. O Google descreve os detalhes na documentação do Chrome.

Speculative Loading no WordPress: o que acontece automaticamente desde a versão 6.8

O Performance Team do WordPress testou o recurso primeiro como um plugin independente chamado Speculative Loading. Ele rodava em mais de 50.000 sites e, segundo dados do HTTP Archive e do Chrome UX Report, a taxa de aprovação desses sites no Largest Contentful Paint melhorou cerca de 1,9% na mediana. Parece pouco, mas para um recurso que não dá trabalho nenhum é um ganho respeitável. Com o WordPress 6.8, em abril de 2025, tudo isso passou para o core. A configuração padrão é propositalmente cautelosa:

• Modo prefetch, eagerness conservative. Ou seja, só o HTML é carregado, e apenas quando um clique já começou.
• Só para visitantes não logados. Quem está logado vê a barra de ferramentas e muitas vezes conteúdo personalizado. Páginas assim não vão para nenhum cache e sairiam caras para carregar antecipadamente.
• Só com Pretty Permalinks. Se em Configurações › Links permanentes ainda estiver marcada a opção Simples, o recurso fica desligado.
• Nenhuma URL com parâmetros. Tudo que tem ponto de interrogação no endereço fica de fora, como a busca ou um link como ?add-to-cart=123 numa loja virtual. A área administrativa, a página de login e links com rel="nofollow" também estão excluídos.
• Exceções por classe. Links com a classe no-prefetch, ou links dentro de um bloco com essa classe, nunca são carregados antecipadamente. A classe no-prerender exclui apenas a renderização prévia.

Por que tanta cautela? O plugin ainda usava prerender com moderate como padrão e, com isso, conseguia mais velocidade. Mas com milhões de sites e incontáveis combinações de temas e plugins, a equipe considerou alto demais o risco de JavaScript rodar em páginas que ninguém nunca visita. É assim que a equipe justifica a decisão no anúncio oficial. Se você quiser mais, ainda pode instalar o plugin Speculative Loading. Ele adiciona em Configurações › Leitura uma interface na qual você muda o modo e a eagerness sem código e, se quiser, ativa o recurso também para usuários logados.

Como ajustar ou desativar o Speculative Loading no WordPress

Sem o plugin, o caminho são os filtros. Os trechos a seguir vão no functions.php do seu Child Theme ou, melhor ainda, em um pequeno plugin próprio, para que sobrevivam a uma troca de tema.

Usar prerender em vez de prefetch:

add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
	if ( is_array( $config ) ) {
		$config['mode']      = 'prerender';
		$config['eagerness'] = 'moderate';
	}
	return $config;
} );

A verificação com is_array() é importante. Para usuários logados e sites sem Pretty Permalinks, o WordPress passa null aqui, e graças a essa verificação o recurso continua desligado nesses casos.

Excluir determinadas seções:

add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
	$paths[] = '/go/*';
	if ( 'prerender' === $mode ) {
		$paths[] = '/carrinho/*';
	}
	return $paths;
}, 10, 2 );

Candidatos típicos são redirecionamentos de links de afiliados que contam um clique quando são acessados, um carrinho de compras ou páginas cujo conteúdo muda o tempo todo. Você informa os caminhos relativos à página inicial, e o WordPress acrescenta um subdiretório por conta própria. Com o segundo parâmetro, você pode excluir caminhos só para um modo, no exemplo o carrinho apenas para a renderização prévia.

Excluir links individuais: Dê ao link ou ao bloco ao redor a classe no-prefetch. No editor de blocos, isso fica em Avançado, no campo de classes CSS adicionais, sem precisar de nenhum código.

Desativar o Speculative Loading por completo:

add_filter( 'wp_speculation_rules_configuration', '__return_null' );

Você só deve desligar o recurso por completo se tiver um motivo concreto para isso. Na configuração padrão, ele praticamente não custa nada.

Quais são as desvantagens do Speculative Loading?

O ganho de velocidade não sai totalmente de graça. Estes são os pontos que você precisa conhecer:

Mais carga no servidor. Cada especulação é uma requisição de verdade. Se um Page Cache entrega a página pronta, o servidor quase não percebe. Sem cache, cada prefetch dispara PHP e consultas ao banco de dados como se um visitante real tivesse chegado. Por isso, em um Shared Hosting com recursos apertados, uma configuração agressiva como immediate ou eager pode fazer uma diferença perceptível. Para visitantes com plano de dados limitado, vale o mesmo em escala menor.

Links que disparam alguma ação. Em tese, um link simples nunca deveria alterar nada. Na prática, alguns alteram mesmo assim: links de logout, contadores de cliques em links de afiliados, avaliações com um clique ou um rápido “Adicionar ao carrinho”. Ao excluir todas as URLs com parâmetros, o WordPress pega muitos desses casos, mas não endereços amigáveis como /go/parceiro/. Esses você deve excluir de forma explícita.

Estatísticas distorcidas. O prefetch não executa JavaScript, então ferramentas de análise como Matomo ou Google Analytics nem ficam sabendo. Já estatísticas geradas a partir dos arquivos de log do servidor, como as que aparecem no painel de muitas empresas de hospedagem, podem contar essas requisições como visitas. No prerender, o JavaScript roda de verdade. Google Analytics e Google Publisher Tag esperam por conta própria até que a página seja de fato exibida. Ferramentas que não fazem isso contam visitas que nunca aconteceram. Para os seus próprios scripts existe uma verificação simples:

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

No servidor, você reconhece requisições especulativas pelo cabeçalho Sec-Purpose, que traz o valor prefetch ou prefetch;prerender.

O conteúdo pode estar um pouco desatualizado. O Chrome guarda as páginas carregadas antecipadamente por alguns minutos. Com conservative isso não importa, porque o clique vem logo em seguida. Com os níveis mais antecipados, uma página cujo conteúdo muda rápido, como uma cobertura ao vivo, pode já estar alguns minutos defasada quando for aberta.

Quais navegadores suportam Speculative Loading?

O Chrome suporta a Speculation Rules API por completo, assim como Edge, Opera e outros navegadores baseados no Chromium. O Safari está trabalhando em uma implementação própria, que nas versões mais recentes, porém, ainda fica escondida atrás de uma opção para desenvolvedores. O Firefox ainda não suporta a API.

Parece uma lacuna, mas na prática não é problema. Como os navegadores ignoram regras que não entendem, todo mundo que usa Chrome sai ganhando, e para o resto simplesmente nada muda. Na maioria dos sites, o Chrome já é de longe a maior fatia do tráfego. Já no início de 2025, ou seja, antes mesmo da estreia no WordPress, mais de 8% de todas as navegações de página no Chrome passavam pelas Speculation Rules, segundo o Performance Team do WordPress.

Como saber se o Speculative Loading está ativo no meu site?

Três jeitos rápidos:

1. Confira o código da página. Abra o seu site em uma janela anônima, para não estar logado, e procure no código da página por speculationrules. O WordPress coloca as regras no rodapé.
2. Use o Chrome DevTools. Na aba Application, em Background services, você encontra a seção Speculative loads. Lá aparecem as regras ativas, quais URLs foram carregadas antecipadamente e por que uma especulação não deu certo.
3. Verifique os cabeçalhos. Se um CDN inclui regras próprias, como a Cloudflare com o recurso Speed Brain, elas não ficam no HTML, e sim no cabeçalho Speculation-Rules da resposta. Nesse caso, pode haver dois conjuntos de regras rodando em paralelo. Isso não causa problema, mas é bom você saber antes de mexer em um lugar e ficar se perguntando por que nada muda.

Como o InspectWP ajuda você a acompanhar o tempo de carregamento e os Resource Hints

O relatório do InspectWP mostra primeiro qual versão do WordPress roda no seu site. A partir da 6.8, você já sabe que o Speculative Loading está ativo por padrão para visitantes não logados, desde que os Pretty Permalinks estejam ativados. Na seção HTML, o relatório também lista os Resource Hints clássicos, ou seja, Prefetch, DNS Prefetch, Preconnect e Prerender, e marca entradas que aparecem mais de uma vez no código da página. Isso costuma indicar plugins que estão atrapalhando uns aos outros. Se ainda aparecer ali um antigo rel="prerender", é um bom motivo para migrar para a Speculation Rules API. Como páginas carregadas antecipadamente custam bem menos com cache, também vale a pena dar uma olhada nos plugins de cache detectados e nos cabeçalhos da resposta do servidor. Um relatório gratuito mostra em pouco tempo em que pé está o seu site.