Prerender Until Script: O Meio-Termo Entre Prefetch e Prerender

Origin Trial: prerender_until_script está disponível como um Origin Trial no Chrome 144 a 150. Você precisa registrar-se para obter um token ou ativá-lo localmente via chrome://flags/#prerender-until-script. Nenhuma intenção de envio (Intent to Ship) foi registrada ainda.

Última revisão por Arjen Karel em março de 2026

Prerender Until Script: O Novo Modo para Speculative Loading

A latência é o gargalo. Digo isso há anos e continua sendo o maior problema isolado no desempenho web. Não importa o quanto otimizemos nosso Critical Rendering Path ou cortemos kilobytes de nossos bundles, estamos limitados em última análise pelas leis da física e pelo tempo de ida e volta (RTT) da rede.

Por muito tempo, tentamos enganar essas leis usando o Speculative Loading: adivinhando para onde o usuário irá em seguida e carregando isso antecipadamente. Até agora, tínhamos duas ferramentas principais e nenhuma era perfeita:

• prefetch: Seguro e leve, mas busca apenas o HTML. O navegador ainda precisa analisar (parse), construir o DOM e descobrir sub-recursos (CSS, imagens) após o clique do usuário. Isso resolve a espera da rede, mas não o trabalho de renderização.
• prerender: A opção nuclear. Ele carrega tudo, executa o JavaScript e renderiza a página em uma guia oculta em segundo plano. É instantâneo, mas é caro. Consome largura de banda, consome memória e dispara pixels de analytics e executa código para páginas que o usuário pode nunca ver.

Precisávamos de um meio-termo. A prontidão visual de um prerender sem o custo e o risco de executar a lógica da aplicação.

Como o prerender_until_script funciona

O prerender_until_script dissocia a análise (parsing) da execução. Ao usar esta Speculation Rule, você instrui o navegador a:

• Buscar o documento (como um prefetch).
• Analisar (parse) o fluxo HTML e construir o DOM.
• Executar o Preload Scanner. Esta é a parte crítica. O navegador descobre e faz o download de sub-recursos, como CSS de alta prioridade e a imagem de LCP.

No momento em que o analisador (parser) encontra um ponto de execução JavaScript, duas coisas podem acontecer:

• Scripts síncronos: O analisador para imediatamente.
• Scripts async/defer: Eles são baixados e colocados na fila, mas não executados.

O navegador constrói a casca visual da página: o layout, a tipografia, as imagens. Mas a lógica da aplicação permanece congelada. A página fica na memória, totalmente disposta, esperando o usuário clicar.

Quando o clique acontece, a página é trocada instantaneamente. O JavaScript é executado, os manipuladores de eventos são anexados e seu analytics dispara exatamente quando deveria.

Prefetch vs prerender_until_script vs prerender

* O prerender completo pode proteger contra analytics prematuros usando document.prerendering, mas você precisa adicionar esse código por conta própria.

É por isso que o prerender_until_script é importante. Você obtém o carregamento de sub-recursos e a construção do DOM de um prerender completo, mas sem a poluição do analytics e o custo de memória da execução do JavaScript. Para sites de conteúdo com scripts de terceiros pesados, este é o ponto ideal.

A Implementação

Implementamos isso usando a Speculation Rules API. Como o prerender_until_script é experimental (Origin Trial, Chrome 144 a 150), você precisa de compatibilidade com versões anteriores.

Os navegadores que não reconhecem a chave prerender_until_script a ignorarão. Adicione um fallback de prefetch para o mesmo conjunto de URLs. O Chrome desduplicará essas regras e aplicará a ação mais capaz disponível.

<script type="speculationrules">
{
  "prerender_until_script": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/cart" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "source": "document",
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/cart" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

O bloco prefetch é o fallback. Em navegadores que suportam prerender_until_script, o Chrome escolhe a ação mais capaz automaticamente. Em navegadores que não suportam, a regra de prefetch ainda é executada. Você obtém o melhor comportamento disponível sem detecção de user-agent.

Se você quiser gerar seu próprio conjunto personalizado de speculation rules, use o gerador de speculation rules.

Como ativar o prerender_until_script

Como este é um Origin Trial, você tem duas opções:

1. Registre-se para obter um token do Origin Trial no painel do Chrome Origin Trials. Adicione o token como uma tag <meta> no seu <head>: <meta http-equiv="origin-trial" content="SEU_TOKEN">
2. Teste localmente navegando até chrome://flags/#prerender-until-script e ativando a flag.

O Origin Trial ocorre do Chrome 144 (janeiro de 2026) ao Chrome 150 (aproximadamente meados de 2026). Se a equipe do Chrome o lançar como um recurso estável depois disso, o token não será mais necessário. A postagem oficial no blog do Chrome cobre todos os detalhes.

Desempenho no mundo real das speculation rules

Ninguém publicou benchmarks do prerender_until_script ainda (é muito novo). Mas a Speculation Rules API em geral tem dados concretos de grandes implementações:

• A Ray-Ban implementou prerender em speculation rules e viu uma melhoria de 43% no LCP em dispositivos móveis (de 4.69s para 2.66s). As taxas de conversão dobraram.
• A Shopify lançou prefetch em speculation rules em todas as lojas Liquid e mediu uma velocidade 130ms maior no desktop e 180ms maior no mobile em todas as métricas de carregamento.
• O Cloudflare Speed Brain usa speculation rules com um modelo de previsão de ML e relata uma redução de 45% no LCP em prefetches bem-sucedidos.

A adoção está crescendo rapidamente. De acordo com o Web Almanac de 2025, 35% dos sites móveis agora usam a Speculation Rules API. A maior parte desse crescimento vem do WordPress 6.8, que incorporou speculation rules em seu núcleo em março de 2025.

O prerender_until_script deve entregar resultados entre o prefetch e o prerender completo. Os sub-recursos já estão em cache e o DOM está construído. O único trabalho restante na ativação é a execução de scripts. Em sites monitorados pelo CoreDash, normalmente vejo as speculation rules cortarem o LCP de navegações subsequentes em 30 a 50%.

Considerações

Eagerness (Avidez): Eu recomendo quase exclusivamente moderate. Isso aciona a especulação ao passar o mouse (quando o ponteiro permanece por 200ms). immediate é muito agressivo para a maioria dos sites e corre o risco de desperdiçar largura de banda em conexões móveis.

Exclusões: Seja disciplinado aqui. Nunca especule em URLs que alteram o estado, como /logout ou /add-to-cart. Embora o prerender_until_script proteja contra a execução de scripts, você não deve nem mesmo buscar esses endpoints desnecessariamente.

Bloqueio do analisador (Parser blocking): O analisador (parser) para imediatamente ao encontrar uma tag <script> síncrona. Se você tiver scripts inline no início do DOM (por exemplo, <script>loadWhileIdle(chat.js)</script>), o prerender irá parar por aí. Mova os scripts para a parte inferior da página ou use defer para maximizar a quantidade do DOM que é pré-construída.

Manipuladores inline (Inline handlers): O prerender_until_script pausa apenas os elementos <script>. Manipuladores de eventos inline em outros elementos (como <img onload="track()">) ainda serão executados se o analisador os alcançar antes de um script de bloqueio. Certifique-se de que seu analytics e rastreamento não sejam acionados por manipuladores inline.

Você pode depurar as speculation rules no Chrome DevTools, no painel Application. O painel Network do Chrome DevTools também mostrará buscas especulativas com um ícone distinto. Use o Real User Monitoring (RUM) para verificar o impacto real no INP e no LCP após implantar as speculation rules em produção.