Speculation Rules API para WordPress e WooCommerce

Em 2026, os utilizadores esperam navegação abaixo de 2 segundos. Cada segundo adicional de carregamento custa cerca de 4,42% das conversões (Portent); os 7% que circulam são da Akamai e medem 100 milissegundos. O Google sabe disto e recompensa sites rápidos com melhores posições.

Este guia não é teoria. É código funcional e uma checklist que pode implementar hoje no seu site WordPress ou loja WooCommerce. As Speculation Rules ajudam depois de o checkout e os cart fragments já estarem controlados. Para essa sequência, veja o estudo de caso de recuperação de performance WooCommerce e a otimização de performance WooCommerce em 2026.

#Como o tempo de carregamento afeta a taxa de saída

#Probabilidade de saída por tempo de carregamento

Fonte: Google e SOASTA, benchmarks de velocidade em móvel. Os números são o aumento da probabilidade de saída face a um segundo de carregamento, não taxas de saída absolutas. Think with Google

O Google confirmou: Core Web Vitals são um fator de classificação. Em 2024, o FID foi substituído pelo INP (Interaction to Next Paint), uma métrica que mede a capacidade de resposta da página às interações do utilizador.

#O que é a velocidade percebida

Pode ter um servidor lento (TTFB 800ms), mas se o utilizador vê conteúdo instantaneamente e a navegação parece instantânea, a performance percebida é excelente.

É exatamente isso que a Speculation Rules API faz, pré-carrega as próximas páginas em segundo plano antes do utilizador clicar.

#Defer de JavaScript, AVIF e TTFB no WordPress

Antes de avançar para técnicas avançadas, garanta que a base está sólida.

#Como fazer defer de JavaScript no functions.php

// functions.php - Adiar JS não-crítico
add_filter('script_loader_tag', function($tag, $handle) {
    $defer_scripts = ['jquery', 'wp-embed', 'comment-reply'];
    if (in_array($handle, $defer_scripts)) {
        return str_replace(' src', ' defer src', $tag);
    }
    return $tag;
}, 10, 2);

#Suporte a AVIF no WordPress 6.5+

WordPress 6.5+ suporta AVIF nativamente. AVIF oferece 20-30% melhor compressão que WebP.

<img 
  src="product.avif" 
  srcset="product-400.avif 400w, product-800.avif 800w"
  sizes="(max-width: 600px) 400px, 800px"
  loading="lazy"
  decoding="async"
  alt="Product"
>

#Como baixar o TTFB para menos de 200 ms

#Como corrigir INP e CLS no WordPress

#Como corrigir o INP dividindo tarefas longas

O INP piora quando a thread principal está bloqueada. Os culpados habituais:

• Page builders pesados (Elementor, Divi)
• Scripts de chat (Intercom, Zendesk)
• Pixels de tracking (Facebook, Google Ads)

Solução: dividir tarefas longas

// Dividir tarefas longas em blocos menores < 50ms
async function longTask(items) {
    for (const item of items) {
        await processItem(item);
        // Ceder a thread principal
        await new Promise(resolve => setTimeout(resolve, 0));
    }
}

#Como evitar CLS causado por imagens e anúncios

/* Reservar espaço para imagens */
img {
    aspect-ratio: 16 / 9;
    width: 100%;
    height: auto;
}

/* Reservar espaço para anúncios */
.ad-slot {
    min-height: 250px;
}

#Speculation Rules API com prefetch e prerender

Este é o núcleo do guia. A Speculation Rules API é uma funcionalidade nativa do navegador que permite pré-carregar páginas em segundo plano.

#Regra de prefetch para todos os links internos

<script type="speculationrules">
{
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/wp-admin/*" } },
          { "not": { "href_matches": "*.pdf" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Prerender do carrinho, checkout e páginas de produto

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/carrinho/", "/checkout/"],
      "eagerness": "immediate"
    },
    {
      "source": "document",
      "where": {
        "or": [
          { "href_matches": "/produto/*" },
          { "selector_matches": ".link-importante" }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

#Prefetch e prerender comparados

#O que significam os níveis de eagerness

• conservative: ao pressionar o ponteiro ou tocar no link, o valor por omissão para regras de documento
• moderate: no desktop, após 200 ms de hover (ou ao pressionar o ponteiro, se acontecer antes); no telemóvel, 500 ms depois de o scroll parar, para links grandes perto do último toque
• eager: desde o Chrome 143, após 10 ms de hover no desktop e 50 ms depois de um link entrar no viewport no telemóvel
• immediate: assim que o navegador lê as regras, o valor por omissão para regras de lista

Os tempos vêm do guia de prerender do Chrome. Antes do Chrome 143, eager comportava-se como immediate, por isso artigos mais antigos que o descrevem como “imediato e agressivo” referem-se ao comportamento anterior.

#O que o WordPress 6.8 faz com o carregamento especulativo por omissão

Desde o WordPress 6.8, a Speculation Rules API faz parte do core. A funcionalidade veio do plugin Speculative Loading, que corria em mais de 50 000 sites antes da integração, e a nota de desenvolvimento do core indica que os sites que o usavam melhoraram a taxa de aprovação do LCP em cerca de 1,9% na mediana, com base em dados do HTTP Archive e do CrUX. A mesma nota refere que mais de 8% das navegações no Chrome já usam speculation rules.

#Configuração por omissão do carregamento especulativo no core do WordPress

Sem qualquer configuração, o core imprime no frontend um único ruleset com modo prefetch e eagerness conservative. Ambos ficam guardados como auto, para que uma versão futura possa mudar aquilo que auto significa sem estragar a sua configuração. O prefetch começa quando o utilizador pressiona o ponteiro sobre um link, o que dá uma pequena vantagem de algumas centenas de milissegundos e quase não gera pedidos desperdiçados.

O core desliga a funcionalidade em três situações:

• para utilizadores com sessão iniciada, para que a barra de ferramentas, as pré-visualizações e os links do painel nunca sejam especulados,
• em sites sem permalinks amigáveis,
• para URLs com parâmetros de consulta, que ficam excluídos do prefetch e do prerender por omissão.

A última regra é importante para o WooCommerce. Os links de adicionar ao carrinho usam uma query string, por isso a configuração por omissão nunca faz prefetch deles. Um plugin que exponha outros “URLs de ação” (pedidos GET que alteram estado) continua a ter de os excluir por conta própria, sobretudo se aumentar a eagerness.

#Como alterar o carregamento especulativo com filtros do WordPress

O core disponibiliza dois filtros e uma action. wp_speculation_rules_configuration recebe um array com mode e eagerness, ou null quando a especulação está desativada para o pedido. Os modos válidos são auto, prefetch e prerender; os valores válidos de eagerness são auto, conservative, moderate e eager. immediate é rejeitado de propósito, porque é fortemente desaconselhado em regras ao nível do documento.

// Mudar a regra do core para prerender no hover
add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    if ( is_array( $config ) ) {
        $config['mode']      = 'prerender';
        $config['eagerness'] = 'moderate';
    }
    return $config;
} );

// Manter caminhos personalizados fora apenas do prerender
add_filter( 'wp_speculation_rules_href_exclude_paths', function ( $paths, $mode ) {
    if ( 'prerender' === $mode ) {
        $paths[] = '/my-account/*';
    }
    return $paths;
}, 10, 2 );

// Adicionar uma regra extra ao lado da regra do core
add_action( 'wp_load_speculation_rules', function ( WP_Speculation_Rules $rules ) {
    $rules->add_rule( 'prerender', 'shop-cart', array(
        'source'    => 'list',
        'urls'      => array( '/cart/' ),
        'eagerness' => 'moderate',
    ) );
} );

O filtro de caminhos excluídos aceita padrões na sintaxe URL Pattern, relativos ao frontend do site, e um argumento opcional $mode. A action wp_load_speculation_rules entrega um objeto WP_Speculation_Rules, e add_rule() aceita tanto regras de lista como regras de documento com uma condição where. Devolver null no filtro de configuração desliga a especulação para esse pedido.

#Como excluir links com as classes no-prefetch e no-prerender

Os editores podem excluir links individuais sem código. Basta adicionar no-prefetch no campo “Classe(s) CSS adicional(is)” do painel Avançado de um bloco para retirar os seus links do carregamento especulativo, ou no-prerender para permitir o prefetch mas bloquear o prerender. Como o prefetch faz parte do prerender, no-prefetch cobre os dois modos. É a correção mais rápida quando um widget, como um calendário de reservas, se comporta mal depois de um prerender.

#Definições do plugin Speculative Loading comparadas com o core

O plugin Speculative Loading da equipa de performance do WordPress continua a existir e é mais agressivo do que o core. Por omissão usa prerender com eagerness moderate, por isso uma página é renderizada em segundo plano quando o utilizador passa o cursor sobre um link. O modo e a eagerness configuram-se em Definições, Leitura.

O plugin avisa quando ativa a especulação para utilizadores com sessão iniciada sem uma object cache persistente, porque cada página especulada passa a custar um pedido PHP completo sem cache. O filtro de exclusão do plugin chama-se plsr_speculation_rules_href_exclude_paths. Numa loja WooCommerce com muito tráfego de utilizadores autenticados, mantenha a especulação para esses utilizadores desligada até ter uma object cache como o Redis em funcionamento.

#Como adicionar Speculation Rules no WordPress

#Método 1: adicionar as regras num plugin próprio

No WordPress 6.8 e versões mais recentes, o core já imprime o seu próprio script speculationrules. Um script personalizado no wp_head acrescenta um segundo ruleset ao lado desse, por isso use este método apenas em versões mais antigas, ou desligue primeiro a regra do core devolvendo null em wp_speculation_rules_configuration. Nas versões atuais, os filtros mostrados acima são o caminho mais limpo.

<?php
/**
 * Plugin Name: Speculation Rules API
 */
add_action('wp_head', function() {
    if (is_admin()) return;
    ?>
    <script type="speculationrules">
    {
      "prefetch": [
        {
          "source": "document",
          "where": {
            "and": [
              { "href_matches": "/*" },
              { "not": { "href_matches": "/wp-*" } }
            ]
          },
          "eagerness": "moderate"
        }
      ]
    }
    </script>
    <?php
});

#Método 2: regras dinâmicas para o carrinho e a paginação

add_action('wp_head', function() {
    $prerender_urls = [];
    
    // Prerender dos produtos que estão no carrinho
    if (function_exists('WC') && WC()->cart) {
        foreach (WC()->cart->get_cart() as $item) {
            $prerender_urls[] = get_permalink($item['product_id']);
        }
    }
    
    // Prerender da página seguinte do arquivo
    if (is_archive() || is_home()) {
        $next_link = get_next_posts_link();
        if ($next_link) {
            preg_match('/href="([^"]+)"/', $next_link, $matches);
            if (!empty($matches[1])) {
                $prerender_urls[] = $matches[1];
            }
        }
    }
    
    if (empty($prerender_urls)) return;
    
    $rules = [
        'prerender' => [[
            'source' => 'list',
            'urls' => array_unique($prerender_urls),
            'eagerness' => 'moderate'
        ]]
    ];
    
    echo '<script type="speculationrules">' . json_encode($rules) . '</script>';
});

#Resultados das Speculation Rules numa loja WooCommerce e num blog

#Estudo de caso 1: loja WooCommerce (500 produtos)

Problema: Navegação categoria para produto demorava vários segundos

Solução:

• Prefetch para links no viewport
• Prerender para “Adicionar ao Carrinho” e “Checkout”

Resultado:

• Antes: vários segundos de espera
• Depois: percebido como instantâneo
• Taxa de rejeição: desceu de forma notória

#Estudo de caso 2: blog WordPress (mais de 1000 artigos)

Problema: INP fora da faixa verde, os utilizadores sentiam “lag”

Solução:

• Defer de todos os scripts
• Prerender para “Ler mais”
• Object Cache (Redis)

Resultado:

• INP: entrou na faixa verde
• LCP: entrou na faixa verde
• Tráfego orgânico: cresceu

#Limitações das Speculation Rules e páginas a evitar

#Que páginas não devem ter prerender

• Páginas com autenticação (login, painel do utilizador)
• Páginas com efeitos colaterais (subscrições, pagamentos)
• URLs externos

#Data Saver, suporte de navegadores e limite de prerender

• Data Saver desativa a especulação, veja abaixo a lista completa de condições que a bloqueiam
• Navegadores sem suporte (Firefox, e Safari sem a flag experimental) ignoram as regras
• Limite de prerender: o Chrome permite 10 prerenders para regras immediate e apenas 2 para eager, moderate e conservative, sendo descartado primeiro o mais antigo

#Limites de especulação do Chrome por nível de eagerness

O Chrome limita quantas especulações uma página pode manter em simultâneo, e o limite depende da eagerness. Os valores abaixo vêm do guia de prerender do Chrome.

Nos três níveis baseados em interação, a fila funciona por ordem de chegada: uma nova especulação cancela a mais antiga. Um URL cancelado pode voltar a ser especulado mais tarde, e os seus recursos cacheáveis costumam continuar na cache HTTP. Remover da página um script com regras de lista liberta capacidade immediate, o que é útil quando uma regra do carrinho deve dar lugar a outra regra depois do checkout.

#Quando o Chrome ignora as speculation rules

As speculation rules são uma sugestão, e o Chrome descarta-as quando:

• o utilizador tem o Save-Data ativo,
• a Poupança de energia está ligada e a bateria está fraca,
• o dispositivo tem pouca memória,
• a definição “Pré-carregar páginas” está desligada, o que algumas extensões como o uBlock Origin fazem,
• a página está aberta num separador em segundo plano.

As páginas em prerender também adiam os iframes de outra origem até à ativação, por isso um mapa ou um leitor de vídeo incorporado só carrega quando o utilizador chega à página. As speculation rules dentro de uma página em prerender são processadas depois de essa página ser ativada, e as regras dentro de iframes são ignoradas.

#Fallback de prefetch para navegadores sem suporte

if (!HTMLScriptElement.supports?.('speculationrules')) {
    // Fallback: prefetch clássico
    document.querySelectorAll('a[href^="/"]').forEach(link => {
        link.addEventListener('mouseenter', () => {
            const prefetch = document.createElement('link');
            prefetch.rel = 'prefetch';
            prefetch.href = link.href;
            document.head.appendChild(prefetch);
        }, { once: true });
    });
}

#Como tornar as páginas WooCommerce seguras para prerender

Uma página em prerender executa o seu JavaScript antes de o utilizador a ver. É por isso que parece instantânea, e é também por isso que pode avariar uma loja se o código assumir que houve uma visita real.

#Que URLs do WooCommerce não são seguros para prefetch ou prerender

A MDN considera inseguros, tanto para prefetch como para prerender, os URLs com efeitos colaterais no servidor: terminar sessão, mudar de idioma, adicionar ao carrinho, enviar códigos SMS de uso único, consumir quotas de utilização e registar conversões de anúncios. Numa loja WooCommerce, isso inclui o link de terminar sessão em A minha conta, um seletor de moeda ou de idioma implementado como link GET e qualquer URL personalizado de “comprar já”. Há ainda páginas que não são seguras para prerender quando os seus scripts escrevem em armazenamento do lado do cliente que outros separadores abertos leem, ou quando enviam analytics ou impressões de anúncios antes de o utilizador ver a página.

As páginas em prerender também podem ficar desatualizadas. Uma página renderizada enquanto o visitante não tinha sessão iniciada continua a mostrar a vista sem sessão se o visitante entrar na conta noutro separador. O Chrome pode guardar uma página em prefetch durante cerca de cinco minutos, por isso o conteúdo pode ter até essa idade quando é mostrado.

#Como limpar páginas especuladas depois de adicionar ao carrinho

O cabeçalho de resposta Clear-Site-Data aceita os valores prefetchCache e prerenderCache. Enviado em qualquer pedido do mesmo site, por exemplo na chamada AJAX que adiciona um produto ao carrinho, descarta as especulações feitas antes de o carrinho mudar. O hover seguinte vai então buscar uma página de carrinho ou checkout nova, em vez de mostrar a antiga.

// Descartar especulações desatualizadas depois de o WooCommerce alterar o carrinho
add_action( 'woocommerce_add_to_cart', function () {
    if ( ! headers_sent() ) {
        header( 'Clear-Site-Data: "prefetchCache", "prerenderCache"' );
    }
} );

#Como detetar pedidos especulativos no servidor

O Chrome marca os pedidos especulativos com o cabeçalho de pedido Sec-Purpose. Um prefetch envia Sec-Purpose: prefetch e um prerender envia Sec-Purpose: prefetch;prerender. Qualquer resposta final fora do intervalo 200 a 299, depois de redirecionamentos, interrompe a especulação, e os códigos 204 ou 205 interrompem um prerender mas continuam a permitir um prefetch. Devolver um erro é a forma mais bruta de bloquear a especulação numa rota. A MDN recomenda antes permitir o pedido e adiar os efeitos colaterais em JavaScript, porque uma especulação bloqueada é um ganho de velocidade perdido.

#Como adiar o analytics até a página em prerender ser mostrada

document.prerendering vale true enquanto a página é renderizada em segundo plano, e o evento prerenderingchange dispara quando o utilizador a ativa. Envolva com esta verificação o analytics, as impressões de anúncios e tudo o que deva contar apenas uma visualização real:

function initTracking() {
    // analytics, impressões de anúncios, widgets de chat
}

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

Várias APIs do navegador esperam pela ativação por si próprias. Segundo a MDN, a geolocalização, os pedidos de permissão de notificações, o registo de service workers e o acesso à câmara devolvem uma promise pendente até a página ser mostrada, enquanto alert() regressa de imediato e confirm() devolve false. O código que depende desses resultados durante o carregamento da página precisa da mesma proteção.

#Suporte de navegadores para Speculation Rules em 2026

As versões vêm dos dados de compatibilidade de navegadores da MDN, que ainda marcam a funcionalidade como experimental e fora do Baseline. Na prática, as regras aceleram os utilizadores de Chromium e não fazem nada nos restantes navegadores, e é por isso que o core do WordPress as trata como melhoria progressiva.

#Como usar Speculation Rules com uma Content Security Policy

#Como permitir speculation rules com uma CSP restritiva

Um bloco de speculation rules é um elemento <script>, por isso uma política script-src restritiva bloqueia-o como qualquer script inline. A MDN indica três formas de o permitir: um nonce, um hash ou a palavra-chave 'inline-speculation-rules'. O guia do Chrome acrescenta que a palavra-chave cobre regras injetadas com hash ou nonce, por isso em sites com CSP restritiva as regras costumam ser inseridas com JavaScript. Se o painel Speculative loads não mostrar regras num site com um plugin de segurança, o cabeçalho CSP é a primeira coisa a verificar.

#Como servir speculation rules com o cabeçalho Speculation-Rules

As regras também podem ficar num ficheiro JSON referenciado por um cabeçalho de resposta HTTP, o que as mantém fora do HTML e fora do problema da CSP. O URL no cabeçalho tem de estar entre aspas, o ficheiro tem de usar o tipo MIME application/speculationrules+json e um ficheiro de outra origem tem de passar uma verificação CORS. Por omissão, os URLs relativos no ficheiro são resolvidos a partir do próprio ficheiro JSON, por isso acrescente "relative_to": "document" a uma regra se os seus caminhos forem relativos à página.

Speculation-Rules: "/speculationrules.json"

As regras vindas do cabeçalho e as regras inline juntam-se num único conjunto. O Chrome 136 acrescentou o campo tag, enviado no cabeçalho de pedido Sec-Speculation-Tags, para que uma CDN ou um servidor saiba que ruleset originou um pedido e o trate de forma diferente.

#Que especulações entre origens o Chrome permite

O prerender está limitado à mesma origem por omissão. Um subdomínio do mesmo site, como uma loja no seu próprio subdomínio, só pode receber prerender se responder com o cabeçalho Supports-Loading-Mode: credentialed-prerender, e o prerender entre sites diferentes não é possível de todo. O prefetch entre sites só funciona quando o utilizador não tem cookies do site de destino, o que impede o tracking. As especulações rejeitadas deste tipo aparecem no painel Speculative loads do DevTools.

#Como monitorizar os prefetches das Speculation Rules

#Ferramentas para verificar carregamentos especulativos

• Chrome DevTools: o painel Speculative loads, no separador Application
• Lighthouse CI: automatização de testes de performance
• WebPageTest: testes reais a partir de várias localizações
• DebugBear: Real User Monitoring (RUM)

#Como medir carregamentos especulativos no GA4

O Resource Timing não tem um tipo de iniciador “speculation”, por isso um carregamento especulativo não pode ser observado a partir da página que o desencadeou. Meça antes na página onde o utilizador chega: um activationStart acima de zero significa que a página teve prerender, e um deliveryType igual a navigational-prefetch significa que veio de um prefetch. Os dois campos estão documentados na MDN.

// Registar como a página atual foi entregue
const nav = performance.getEntriesByType('navigation')[0];
let delivery = 'normal';
if (nav.activationStart > 0) {
    delivery = 'prerender';
} else if (nav.deliveryType === 'navigational-prefetch') {
    delivery = 'prefetch';
}
gtag('event', 'page_delivery', { delivery_type: delivery });

Compare o número de visitas prerender e prefetch com o número de pedidos especulativos que aparecem nos logs do servidor (veja o cabeçalho Sec-Purpose acima). A diferença é o desperdício. Segundo o guia de prerender do Chrome, o Chrome mede as Core Web Vitals de uma página em prerender a partir da ativação, não do início do prerender, e a biblioteca web-vitals, a partir da versão 3.1.0, reporta essas navegações com um navigationType igual a prerender. Segmente os dados de campo por esse valor, caso contrário o LCP quase nulo das visualizações em prerender esconde uma navegação normal lenta.

#Checklist de Speculation Rules para WordPress

#Antes da implementação

• Medir score Lighthouse base
• Verificar TTFB < 200ms
• Object Cache está ativo
• Imagens são servidas como AVIF

#Durante a implementação

• Adicionar prefetch básico (moderate)
• Analisar heatmaps (Hotjar, Clarity)
• Identificar top 3 caminhos de navegação
• Adicionar prerender para links de alta intenção
• Testar em 10% do tráfego (A/B)
• Monitorizar prefetches “desperdiçados”

#Depois da implementação

• Comparar LCP, INP e tempo de navegação
• Verificar o Cache Hit Ratio
• A longo prazo: taxa de rejeição e taxa de conversão

#Resumo

Speculation Rules API é uma mudança importante para 2026. Ao pré-carregar páginas em segundo plano, a navegação torna-se instantânea, sem mudanças de infraestrutura.

Pontos-chave:

1. Comece com prefetch com moderate eagerness, é seguro
2. Adicione prerender para o fluxo de checkout em e-commerce
3. Monitorize métricas, não adivinhe, meça

Precisa de otimização profissional? Como especialista WordPress, ajudo a acelerar sites WordPress e WooCommerce. Veja também otimização de velocidade WordPress.