O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Pré-renderizar páginas no Chrome para navegação instantânea

Barry Pollard

Publicado em 2 de dezembro de 2022. Última atualização: 29 de outubro de 2026

Browser Support

Source

A equipe do Chrome trouxe de volta a pré-renderização completa de páginas futuras que um usuário provavelmente vai acessar.

Uma breve história da pré-renderização

No passado, o Chrome oferecia suporte à dica de recurso <link rel="prerender" href="/next-page">, mas ela não era amplamente aceita fora do Chrome e não era uma API muito expressiva.

Essa pré-renderização legada que usa a dica de link rel=prerender foi descontinuada em favor da pré-busca sem estado, que busca os recursos necessários para a página futura, mas não pré-renderiza totalmente a página nem executa o JavaScript. A pré-busca NoState ajuda a melhorar o desempenho da página ao otimizar o carregamento de recursos, mas não oferece um carregamento de página instantâneo como uma pré-renderização completa.

A equipe do Chrome reintroduziu a pré-renderização completa no Chrome. Para evitar complicações com o uso atual e permitir a expansão futura da pré-renderização, esse novo mecanismo não vai usar a sintaxe <link rel="prerender"...>, que permanece em vigor para a pré-busca NoState, com o objetivo de desativá-la no futuro.

Como uma página é pré-renderizada?

Uma página pode ser pré-renderizada de quatro maneiras, todas com o objetivo de acelerar as navegações:

Quando você digita um URL na barra de endereço do Chrome (também conhecida como "omnibox"), o navegador pode pré-renderizar automaticamente a página se tiver alta confiança de que você vai acessá-la, com base no seu histórico de navegação anterior.
Quando você usa a barra de favoritos, o Chrome pode pré-renderizar automaticamente a página ao manter o ponteiro sobre um dos botões de favoritos.
Quando você digita um termo de pesquisa na barra de endereço do Chrome, o navegador pode pré-renderizar automaticamente a página de resultados da pesquisa, se instruído pelo mecanismo de pesquisa.
Os sites podem usar a API Speculation Rules para informar ao Chrome de forma programática quais páginas devem ser pré-renderizadas. Isso substitui o que o <link rel="prerender"...> costumava fazer e permite que os sites pré-renderizem uma página de forma proativa com base em regras de especulação na página. Eles podem existir de forma estática nas páginas ou ser injetados dinamicamente pelo JavaScript, conforme o proprietário da página achar melhor.

Em cada um desses casos, uma pré-renderização se comporta como se a página tivesse sido aberta em uma guia invisível em segundo plano e, em seguida, é "ativada" substituindo a guia em primeiro plano por essa página pré-renderizada. Se uma página for ativada antes de ser totalmente pré-renderizada, o estado atual dela será "em primeiro plano" e continuará carregando, o que significa que você ainda pode ter uma boa vantagem.

Como a página pré-renderizada é aberta em um estado oculto, várias APIs que causam comportamentos intrusivos (por exemplo, solicitações) não são ativadas nesse estado e são atrasadas até que a página seja ativada. Nos poucos casos em que isso ainda não é possível, a pré-renderização é cancelada. A equipe do Chrome está trabalhando para expor os motivos de cancelamento da pré-renderização como uma API e também para melhorar os recursos do DevTools para facilitar a identificação desses casos extremos.

Observação: as páginas pré-renderizadas precisam ser tratadas como uma dica e um aprimoramento progressivo. Ao contrário de preload, a pré-renderização é uma dica especulativa, e o navegador pode optar por não agir com base nela, dependendo das configurações do usuário, do uso atual da memória ou de outras heurísticas.

Impacto da pré-renderização

A pré-renderização permite um carregamento de página quase instantâneo, como mostrado no vídeo a seguir:

Exemplo de impacto da pré-renderização.

O site de exemplo já é rápido, mas, mesmo assim, é possível notar como a pré-renderização melhora a experiência do usuário. Isso também pode ter um impacto direto nas Core Web Vitals de um site, com LCP quase zero, CLS reduzida (já que qualquer CLS de carregamento acontece antes da visualização inicial) e INP melhorada (já que o carregamento deve ser concluído antes que o usuário interaja).

Mesmo quando uma página é ativada antes de ser totalmente carregada, ter uma vantagem inicial no carregamento de página deve melhorar a experiência de carregamento. Quando um link é ativado enquanto a pré-renderização ainda está acontecendo, a página de pré-renderização é movida para o frame principal e continua carregando.

No entanto, a pré-renderização usa mais memória e largura de banda de rede. Tome cuidado para não fazer pré-renderizações em excesso, o que pode consumir recursos do usuário. Só faça a pré-renderização quando houver uma alta probabilidade de a página ser acessada.

Consulte a seção Como medir o desempenho para mais informações sobre como medir o impacto real do desempenho nas suas análises.

Ver as previsões da barra de endereço do Chrome

No primeiro caso de uso, é possível conferir as previsões do Chrome para URLs na página chrome://predictors:

A página de preditores do Chrome filtrada para mostrar previsões baixas (cinza), médias (âmbar) e altas (verde) com base no texto inserido. — Página de preditores do Chrome.

As linhas verdes indicam que há confiança suficiente para acionar a pré-renderização. Neste exemplo, digitar "s" dá uma confiança razoável (âmbar), mas, quando você digita "sh", o Chrome tem confiança suficiente de que você quase sempre navega para https://sheets.google.com.

Essa captura de tela foi feita em uma instalação relativamente nova do Chrome, filtrando as previsões com confiança zero. No entanto, se você visualizar seus próprios preditores, provavelmente verá muito mais entradas e, possivelmente, mais caracteres necessários para atingir um nível de confiança alto o suficiente.

Esses preditores também são o que impulsiona as opções sugeridas na barra de endereço que você pode ter notado:

O recurso "Preenchimento automático" da barra de endereço do Chrome — Recurso de preenchimento automático da barra de endereço.

O Chrome vai atualizar continuamente os preditores com base na sua digitação e nas suas seleções.

Para um nível de confiança maior que 30% (mostrado em âmbar), o Chrome se conecta proativamente ao domínio, mas não pré-renderiza a página.
Para um nível de confiança maior que 50% (mostrado em verde), o Chrome vai pré-renderizar o URL.

API Speculation Rules

Para a opção de pré-renderização da API Speculation Rules, os desenvolvedores web podem inserir instruções JSON nas páginas para informar ao navegador quais URLs devem ser pré-renderizados.

Listas de URLs

As regras de especulação podem ser baseadas em listas de URLs:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Regras de documentos

As regras de especulação também podem ser "regras de documento" usando a sintaxe where. Isso especula links encontrados no documento com base em seletores href (com base na API Padrão do URL) ou seletores de CSS:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"href_matches": "/wp-admin"}},
        { "not": {"href_matches": "/*\\?*(^|&)add-to-cart=*"}},
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel~=nofollow]"}}
      ]
    }
  }]
}
</script>

Ansiedade

Browser Support

Source

Uma configuração eagerness é usada para indicar quando as especulações devem ser acionadas, o que é particularmente útil para regras de documentos:

conservative: especula no ponteiro ou no toque.
moderate: no computador, realiza especulações se você mantiver o cursor sobre um link por 200 milissegundos (ou no evento pointerdown se for antes, e no dispositivo móvel onde não há evento hover). Em dispositivos móveis, mudamos para basear isso em heurísticas complexas de janela de visualização a partir de agosto de 2025. As heurísticas complexas de janela de visualização são acionadas 500 ms depois que o usuário para de rolar, para âncoras dentro de 30% da distância vertical do ponteiro anterior para baixo, em que as âncoras são pelo menos 0,5 vez maiores que a maior âncora na janela de visualização. Conforme descrito neste documento.
eager: essa prioridade se comportava de maneira idêntica a immediate, mas mudou no Chrome 143. No computador, isso realiza especulações se você mantiver o ponteiro sobre um link por 10 milissegundos. Em dispositivos móveis, mudamos para basear isso em heurísticas simples de janela de visualização a partir de janeiro de 2026. A heurística simples da janela de visualização é acionada 50 ms depois que a âncora entra na janela de visualização.
immediate: usada para especular o mais rápido possível, isto é, assim que as regras de especulação forem observadas.

O eagerness padrão para regras list é immediate. As opções eager, moderate e conservative podem ser usadas para limitar as regras de list aos URLs com que um usuário interage em uma lista específica. No entanto, em muitos casos, as regras document com uma condição where adequada podem ser mais apropriadas.

O eagerness padrão para regras document é conservative. Como um documento pode consistir em muitos URLs, o uso de immediate para regras de document deve ser feito com cautela (consulte também a seção Limites do Chrome a seguir).

A configuração de eagerness a ser usada depende do seu site. Para um site estático e leve, fazer mais especulações pode ter um custo baixo 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é receberem um sinal de intenção mais positivo dos usuários para limitar o desperdício.

A opção moderate é um meio-termo, e muitos sites podem se beneficiar da seguinte regra de especulação, que pré-renderiza um link ao manter o ponteiro sobre ele por 200 milissegundos ou no evento pointerdown como uma implementação básica, mas poderosa, de regras de especulação:

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

Pré-busca

As regras de especulação também podem ser usadas para pré-buscar páginas, sem uma pré-renderização completa. Essa pode ser uma boa primeira etapa no caminho para a pré-renderização:

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Observação: ao contrário da dica de recurso <link rel="prefetch"> mais antiga, que apenas pré-buscava o cache HTTP, os documentos carregados usando regras de especulação são processados da mesma forma que as navegações (mas não renderizados) e são mantidos na memória para que fiquem disponíveis mais rapidamente para o navegador quando necessário. Isso também permite que documentos que não podem ser armazenados em cache HTTP sejam pré-buscados.

Devido a problemas com a pré-busca de documentos usando <link rel="prefetch">, recomendamos o uso de regras de especulação para navegações futuras, com <link rel="prefetch"> usado apenas para pré-buscar sub-recursos. Por outro lado, as regras de especulação devem ser usadas para especulações de navegação de documentos, e não para pré-buscas de subrecursos, principalmente devido às restrições entre origens da API Speculation Rules.

Prerender until script

A equipe do Chrome também está trabalhando para adicionar prerender_until_script à API Speculation Rules (consulte o bug de implementação). Essa seria uma etapa entre a pré-busca e a pré-renderização e seria usada de maneira semelhante:

<script type="speculationrules">
{
  "prerender_until_script": [{
    "urls": ["next.html", "next2.html"]
  }]
}
</script>

Semelhante a NoState prefetch, isso pré-carregaria o documento HTML e os sub-recursos disponíveis nele. No entanto, ele vai além disso e também começa a pré-renderizar a página, parando quando o primeiro script é encontrado.

Isso significa que, para páginas sem JavaScript ou apenas com JavaScript no rodapé, a página pode ser quase totalmente pré-renderizada com antecedência. As páginas com scripts no <head> não poderiam ser pré-renderizadas, mas ainda se beneficiariam da busca de sub-recursos.

Isso evitaria os riscos de efeitos colaterais não intencionais da execução do JavaScript, mas permitiria um ganho de desempenho muito maior do que apenas prefetch.

Limites do Chrome

O Chrome tem limites para evitar o uso excessivo da API Speculation Rules:

entusiasmo	Pré-busca	Pré-renderizar
`immediate`	50	10
`eager` / `moderate` em dispositivos móveis	6 (PEPS)	2 (PEPS)
`eager` / `moderate` no computador	2 (PEPS)	2 (PEPS)
`conservative`	2 (PEPS)	2 (FIFO)

Limites de especulação no Chrome.

As configurações eager, moderate e conservative, que dependem da interação do usuário, funcionam de maneira FIFO (primeiro a entrar, primeiro a sair): depois de atingir o limite, uma nova especulação vai fazer com que a mais antiga seja cancelada e substituída pela mais recente para conservar a memória.

Uma especulação cancelada pode ser acionada de novo, por exemplo, ao passar o cursor sobre o link novamente. Isso vai resultar na reespeculação do URL, eliminando a especulação mais antiga. Nesse caso, a especulação anterior terá armazenado em cache todos os recursos que podem ser armazenados em cache no cache HTTP para esse URL. Portanto, uma nova especulação terá um custo reduzido. Por isso, o limite é definido como o limite modesto de 2 por padrão. Usamos um limite maior de 6 para pré-busca em dispositivos móveis, já que não há "passagem do cursor", as heurísticas alternativas de janela de visualização para dispositivos móveis são menos precisas e a pré-busca é menos dispendiosa do que a pré-renderização (mantemos o limite de 2 para pré-renderização em dispositivos móveis).

As regras de lista estática não são acionadas por uma ação do usuário e, portanto, têm um limite maior, já que não é possível para o navegador saber quais são necessárias e quando são necessárias.

O Chrome também está considerando aumentar o limite para 5 em dispositivos móveis para eager e moderate, pelo menos para pré-busca, já que essa é uma heurística menos precisa. Os desenvolvedores que usam eager podem considerar o uso de regras conservative quando vários links estão disponíveis na janela de visualização para que eles ainda especulem, mesmo que não sejam selecionados como um dos dois primeiros links.

O limite de immediate também é dinâmico. Portanto, remover um elemento de script de URL list vai criar capacidade ao cancelar as especulações removidas.

O Chrome também impede que as especulações sejam usadas em determinadas condições, incluindo:

Save-Data.
Economia de energia quando ativada e com pouca bateria.
Restrições de memória.
Quando a configuração "Pré-carregar páginas" está desativada (o que também é feito explicitamente por extensões do Chrome, como o uBlock Origin).
Páginas abertas em guias em segundo plano.

O Chrome também não renderiza iframes entre origens em páginas pré-renderizadas até a ativação.

Todas essas condições visam reduzir o impacto da especulação excessiva quando ela é prejudicial aos usuários.

Como incluir regras de especulação em uma página

As regras de especulação podem ser incluídas estaticamente no HTML da página ou inseridas dinamicamente na página pelo JavaScript:

Regras de especulação incluídas estaticamente: por exemplo, um site de notícias ou um blog pode pré-renderizar o artigo mais recente, se essa for a próxima navegação para uma grande proporção de usuários. Como alternativa, as regras de documento com um moderate ou conservative podem ser usadas para especular conforme os usuários interagem com os links.
Regras de especulação inseridas dinamicamente: podem ser baseadas na lógica do aplicativo, personalizadas para o usuário ou baseadas em outras heurísticas.

Para quem prefere a inserção dinâmica com base em ações como passar o cursor ou clicar em um link, como muitas bibliotecas fizeram no passado com <link rel=prefetch>, recomendamos analisar as regras de documento, já que elas permitem que o navegador lide com muitos dos seus casos de uso.

As regras de especulação podem ser adicionadas no <head> ou no <body> do frame principal. As regras de especulação em subframes não são aplicadas, e as regras de especulação em páginas pré-renderizadas só são aplicadas quando essa página é ativada.

Cabeçalho HTTP `Speculation-Rules`

Browser Support

Source

As regras de especulação também podem ser enviadas usando um cabeçalho HTTP Speculation-Rules, em vez de serem incluídas diretamente no HTML do documento. Isso facilita a implantação por CDNs sem a necessidade de alterar o conteúdo do documento.

O cabeçalho HTTP Speculation-Rules é retornado com o documento e aponta para um local de um arquivo JSON que contém as regras de especulação:

Speculation-Rules: "/speculationrules.json"

Esse recurso precisa usar o tipo MIME correto e, se for um recurso entre origens, passar por uma verificação de CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Se você quiser usar URLs relativos, inclua a chave "relative_to": "document" nas regras de especulação. Caso contrário, os URLs relativos serão relativos ao URL do arquivo JSON das regras de especulação. Isso pode ser útil se você precisar selecionar alguns ou todos os links de mesma origem.

Campo de tag de regras de especulação

Browser Support

Source

Também é possível adicionar "tags" na sintaxe JSON das regras de especulação no nível geral para todas as regras de especulação em um conjunto de regras:

{
  "tag": "my-rules",
  "prefetch": [{
      "urls": ["next.html"]
  }],
  "prerender": [{
      "urls": ["next2.html"]
  }]
}

Ou no nível de regra individual:

{
  "prefetch": [{
    "tag": "my-prefetch-rules",
    "urls": ["next.html"]
  }],
  "prerender": [{
    "tag": "my-prerender-rules",
    "urls": ["next2.html"]
  }]
}

Essa tag é refletida no cabeçalho HTTP Sec-Speculation-Tags, que pode ser usado para filtrar regras de especulação no servidor. O cabeçalho HTTP Sec-Speculation-Tags pode incluir várias tags se a especulação for coberta por várias regras, como mostra o exemplo a seguir:

Sec-Speculation-Tags: null
Sec-Speculation-Tags: null, "cdn-prefetch"
Sec-Speculation-Tags: "my-prefetch-rules"
Sec-Speculation-Tags: "my-prefetch-rules", "my-rules", "cdn-prefetch"

Algumas CDNs injetam regras de especulação automaticamente, mas bloqueiam especulações para páginas que não estão em armazenamento em cache de borda para evitar que esse recurso resulte em um aumento no uso do servidor de origem. As tags permitem identificar as especulações iniciadas pelo conjunto de regras padrão, mas ainda permitem que as regras adicionadas pelo site sejam transmitidas para a origem.

As tags de conjunto de regras também são mostradas no Chrome DevTools.

Campo `target_hint` das regras de especulação

Browser Support

Source

As regras de especulação também podem incluir um campo target_hint, que contém um nome ou palavra-chave de contexto de navegação válido indicando onde a página espera que o conteúdo pré-renderizado seja ativado:

<script type=speculationrules>
{
  "prerender": [{
    "target_hint": "_blank",
    "urls": ["next.html"]
  }]
}
</script>

Essa dica permite que as especulações de pré-renderização sejam processadas para links target="_blank":

<a target="_blank" href="next.html">Open this link in a new tab</a>

Por enquanto, apenas "target_hint": "_blank" e "target_hint": "_self" (o padrão, se não especificado) são compatíveis com o Chrome e apenas para pré-renderização. A pré-busca não é compatível.

target_hint só é necessário para regras de especulação urls, já que para regras de documentos, o target é conhecido pelo próprio link.

Regras de especulação e SPAs

As regras de especulação só são compatíveis com navegações de página inteira gerenciadas pelo navegador, e não com apps de página única (SPA, na sigla em inglês) ou páginas de shell do app. Essas arquiteturas não usam buscas de documentos, mas fazem buscas parciais ou de API de dados ou páginas, que são processadas e apresentadas na página atual. Os dados necessários para essas "navegações suaves" podem ser pré-buscados pelo app fora das regras de especulação, mas não podem ser pré-renderizados.

As regras de especulação podem ser usadas para pré-renderizar o próprio aplicativo de uma página anterior. Isso pode ajudar a compensar alguns dos custos extras de carregamento inicial que alguns SPAs têm. No entanto, as mudanças de rota no app não podem ser pré-renderizadas.

Depurar regras de especulação

Consulte o post dedicado à depuração de regras de especulação para conhecer os novos recursos do Chrome DevTools que ajudam a visualizar e depurar essa nova API.

Várias regras de especulação

Também é possível adicionar várias regras de especulação à mesma página, que são anexadas às regras atuais. Portanto, as diferentes maneiras a seguir resultam na pré-renderização de one.html e two.html:

Lista de URLs:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html", "two.html"]
  }]
}
</script>

Vários scripts speculationrules:

<script type="speculationrules">
{
  "prerender": [{
    "urls": ["one.html"]
  }]
}
</script>
<script type="speculationrules">
{
  "prerender": [{
    "urls": ["two.html"]
  }]
}
</script>

Várias listas em um conjunto de speculationrules

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["one.html"]
    },
    {
      "urls": ["two.html"]
    }
  ]
}
</script>

Suporte a `No-Vary-Search`

Browser Support

Source

Ao pré-buscar ou pré-renderizar uma página, alguns parâmetros de URL (tecnicamente conhecidos como parâmetros de pesquisa) podem não ser importantes para a página realmente entregue pelo servidor e usados apenas pelo JavaScript do lado do cliente.

Por exemplo, os parâmetros UTM são usados pelo Google Analytics para medição da campanha, mas geralmente não resultam em páginas diferentes sendo entregues pelo servidor. Isso significa que page1.html?utm_content=123 e page1.html?utm_content=456 vão exibir a mesma página do servidor, que pode ser reutilizada do cache.

Da mesma forma, os aplicativos podem usar outros parâmetros de URL que são processados apenas no lado do cliente.

A proposta No-Vary-Search permite que um servidor especifique parâmetros que não resultam em uma diferença para o recurso entregue e, portanto, permite que um navegador reutilize versões armazenadas em cache de um documento que diferem apenas por esses parâmetros. Isso é compatível com o Chrome (e navegadores baseados no Chromium) para especulações de navegação de pré-busca e pré-renderização.

Atenção: ao usar a pré-renderização com No-Vary-Search, a página pode ser pré-renderizada com um parâmetro de pesquisa diferente (ou sem nenhum parâmetro de pesquisa). Inicialmente, o URL (conforme retornado por location.href, por exemplo) será o URL pré-renderizado, mas quando um link for clicado com parâmetros de pesquisa diferentes cobertos por No-Vary-Search, o navegador usará essa página pré-renderizada e substituirá o URL pelo URL final (incluindo os parâmetros de pesquisa corretos).

Portanto, qualquer JavaScript que dependa dos parâmetros de pesquisa só deve ser executado após a ativação da página. Para parâmetros UTM, isso pode não ser um problema se o código de análise não for executado até depois da ativação. No entanto, para páginas renderizadas do lado do cliente que mostram conteúdo diferente com base em parâmetros de pesquisa, isso pode ser um problema, e é preciso ter cuidado para garantir que o conteúdo renderizado do lado do cliente seja atualizado na ativação.

As regras de especulação permitem usar expects_no_vary_search para indicar onde um cabeçalho HTTP No-Vary-Search deve ser retornado. Isso pode ajudar a evitar downloads desnecessários antes que as respostas sejam vistas.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

Neste exemplo, o HTML inicial da página /products é o mesmo para os IDs de produto 123 e 124. No entanto, o conteúdo da página acaba sendo diferente com base na renderização do lado do cliente, que usa JavaScript para buscar dados do produto usando o parâmetro de pesquisa id. Por isso, fazemos uma pré-busca desse URL, que deve retornar um cabeçalho HTTP No-Vary-Search mostrando que a página pode ser usada para qualquer parâmetro de pesquisa id.

No entanto, se o usuário clicar em qualquer um dos links antes que a pré-busca seja concluída, talvez o navegador não tenha recebido a página /products. Nesse caso, o navegador não sabe se ele vai conter o cabeçalho HTTP No-Vary-Search. O navegador precisa escolher entre buscar o link novamente ou esperar que a pré-busca seja concluída para ver se ele contém um cabeçalho HTTP No-Vary-Search. A configuração expects_no_vary_search permite que o navegador saiba que a resposta da página deve conter um cabeçalho HTTP No-Vary-Search e aguarde a conclusão da pré-busca.

Observação: usar apenas expects_no_vary_search não é suficiente para garantir que uma página com um parâmetro de pesquisa diferente seja reutilizada. É mais uma dica para o navegador sobre o que esperar. O servidor também precisa retornar um cabeçalho HTTP No-Vary-Search para que o navegador saiba que pode usar a página do cache, mesmo quando o parâmetro de pesquisa não corresponder.

Também é possível adicionar vários parâmetros a expects_no_vary_search com um espaço entre eles (já que No-Vary-Search é um cabeçalho estruturado HTTP):

    "expects_no_vary_search": "params=(\"param1\" \"param2\" \"param3\")"

Restrições das regras de especulação e melhorias futuras

As regras de especulação são restritas às páginas abertas na mesma guia, mas estamos trabalhando para reduzir essa restrição.

Por padrão, as pré-renderizações são restritas a páginas de mesma origem. É possível ativar a pré-renderização de páginas entre origens do mesmo site (por exemplo, https://a.example.com pode pré-renderizar uma página em https://b.example.com). Para usar isso, a página especulada (https://b.example.com neste exemplo) precisa ativar a inclusão de um cabeçalho HTTP Supports-Loading-Mode: credentialed-prerender. Caso contrário, o Chrome vai cancelar a especulação.

As versões futuras também podem permitir a pré-renderização de páginas entre origens que não são do mesmo site, desde que não haja cookies para a página pré-renderizada e que ela use um cabeçalho HTTP Supports-Loading-Mode: uncredentialed-prerender semelhante.

As regras de especulação já são compatíveis com pré-buscas entre origens. Para pré-buscas entre origens do mesmo site, não há restrições. As pré-buscas entre origens de sites diferentes só são aceitas quando não há cookies para o domínio de origem cruzada. Se houver cookies de visitas anteriores do usuário, a especulação não será usada e vai mostrar uma falha no DevTools.

Considerando essas limitações, um padrão que pode melhorar as experiências dos usuários para Links internos e link externo, quando possível, é pré-renderizar URLs de origem e tentar pré-buscar URLs entre origens:

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

A restrição para evitar especulações entre origens para links entre origens por padrão é necessária para a segurança. É uma melhoria em relação a <link rel="prefetch"> para destinos entre origens, que também não enviam cookies, mas ainda tentam a pré-busca, o que resulta em uma pré-busca desperdiçada que precisa ser reenviada ou, pior ainda, no carregamento incorreto da página.

Detectar suporte à API Speculation Rules

É possível detectar o suporte à API Speculation Rules com verificações HTML padrão:

if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
  console.log('Your browser supports the Speculation Rules API.');
}

Adicionar regras de especulação dinamicamente usando JavaScript

Veja um exemplo de como adicionar uma regra de especulação prerender com JavaScript:

if (HTMLScriptElement.supports &&
    HTMLScriptElement.supports('speculationrules')) {
  const specScript = document.createElement('script');
  specScript.type = 'speculationrules';
  specRules = {
    prerender: [
      {
        urls: ['/next.html'],
      },
    ],
  };
  specScript.textContent = JSON.stringify(specRules);
  console.log('added speculation rules to: next.html');
  document.body.append(specScript);
}

Confira uma demonstração da pré-renderização da API Speculation Rules, usando a inserção de JavaScript, nesta página de demonstração de pré-renderização.

Inserir um elemento <script type = "speculationrules"> diretamente no DOM usando innerHTML não vai registrar as regras de especulação por motivos de segurança, e isso precisa ser adicionado conforme mostrado anteriormente. No entanto, o conteúdo inserido dinamicamente usando innerHTML que contém novos links será selecionado pelas regras atuais na página.

Da mesma forma, a edição direta do painel Elementos no Chrome DevTools para adicionar o elemento <script type = "speculationrules"> não registra as regras de especulação. Em vez disso, o script para adicionar isso dinamicamente ao DOM precisa ser executado no console para inserir as regras.

Adicionar regras de especulação usando um Tag Manager

Para adicionar regras de especulação usando um gerenciador de tags, como o Google Tag Manager (GTM), é necessário inseri-las usando JavaScript, em vez de adicionar o elemento <script type = "speculationrules"> pelo GTM diretamente, pelos mesmos motivos mencionados anteriormente:

Configuração de tag HTML personalizada no Google Tag Manager — Adicionar regras de especulação pelo Google Tag Manager.

Este exemplo usa var porque o GTM não é compatível com const.

Cancelar regras de especulação

A remoção das regras de especulação vai resultar no cancelamento da pré-renderização. No entanto, quando isso acontecer, é provável que os recursos já tenham sido gastos para iniciar a pré-renderização. Portanto, recomendamos não pré-renderizar se houver a probabilidade de precisar cancelar a pré-renderização. Por outro lado, os recursos armazenados em cache ainda podem ser reutilizados, então os cancelamentos podem não ser completamente desperdiçados e ainda podem beneficiar futuras especulações e navegações.

Browser Support

Source

As especulações também podem ser canceladas usando o cabeçalho HTTP Clear-Site-Data com as diretivas prefetchCache e prerenderCache.

Isso pode ser útil quando o estado é alterado no servidor. Por exemplo, ao chamar uma API de "adicionar ao carrinho" ou de login/logout.

O ideal é que essas atualizações de estado sejam propagadas para páginas pré-renderizadas usando APIs como a API Broadcast Channel. No entanto, quando isso não for possível ou até que essa lógica seja implementada, cancelar a especulação pode ser mais fácil.

Regras de especulação e Política de Segurança de Conteúdo

Como as regras de especulação usam um elemento <script>, mesmo que contenham apenas JSON, elas precisam ser incluídas na Content-Security-Policy script-src se o site usar isso, seja com um hash ou um nonce.

Um novo inline-speculation-rules pode ser adicionado a script-src, permitindo que elementos <script type="speculationrules"> injetados de scripts de hash ou nonce sejam aceitos. Isso não é compatível com as regras incluídas no HTML inicial. Portanto, as regras precisam ser injetadas pelo JavaScript para sites que usam uma CSP rigorosa.

Detectar e desativar a pré-renderização

A pré-renderização geralmente é uma experiência positiva para os usuários, porque permite uma renderização rápida da página, muitas vezes instantânea. Isso beneficia tanto o usuário quanto o proprietário do site, já que as páginas pré-renderizadas permitem uma melhor experiência do usuário que pode ser difícil de alcançar de outra forma.

No entanto, pode haver casos em que você não quer que a pré-renderização de páginas aconteça, por exemplo, quando as páginas mudam de estado, seja com base na solicitação inicial ou no JavaScript em execução na página.

Ativar e desativar a pré-renderização no Chrome

A pré-renderização só é ativada para os usuários do Chrome com a configuração "Pré-carregar páginas" em chrome://settings/performance/. Além disso, a pré-renderização também é desativada em dispositivos com pouca memória ou se o sistema operacional estiver nos modos de economia de dados ou de energia. Consulte a seção Limites do Chrome.

Detectar e desativar a pré-renderização do lado do servidor

As páginas pré-renderizadas serão enviadas com o cabeçalho HTTP Sec-Purpose:

Sec-Purpose: prefetch;prerender

As páginas pré-buscadas usando a API Speculation Rules terão esse cabeçalho definido como prefetch:

Sec-Purpose: prefetch

Os servidores podem responder com base nesse cabeçalho para registrar solicitações de especulação, retornar conteúdo diferente ou impedir que uma pré-renderização aconteça. Se um código de resposta final de falha for retornado, ou seja, não estiver no intervalo de 200 a 299 após os redirecionamentos, a página não será pré-renderizada, e qualquer página de pré-busca será descartada. Além disso, as respostas 204 e 205 não são válidas para pré-renderização, mas são válidas para pré-busca.

Se você não quiser que uma página específica seja pré-renderizada, retornar um código de resposta que não seja 2XX (como 503) é a melhor maneira de garantir que isso não aconteça. No entanto, para oferecer a melhor experiência, recomendamos permitir a pré-renderização, mas atrasar as ações que só devem acontecer quando a página for realmente visualizada, usando JavaScript.

Detectar pré-renderização em JavaScript

A API document.prerendering vai retornar true enquanto a página estiver sendo pré-renderizada. Isso pode ser usado pelas páginas para impedir ou atrasar determinadas atividades durante a pré-renderização até que a página seja realmente ativada.

Depois que um documento pré-renderizado é ativado, o activationStart de PerformanceNavigationTiming também é definido como um tempo diferente de zero, que representa o tempo entre o início da pré-renderização e a ativação do documento.

É possível ter uma função para verificar páginas pré-renderizadas e em pré-renderização, como esta:

function pagePrerendered() {
  return (
    document.prerendering ||
    self.performance?.getEntriesByType?.('navigation')[0]?.activationStart > 0
  );
}

A maneira mais fácil de conferir se uma página foi pré-renderizada (total ou parcialmente) é abrir o DevTools depois que a página for ativada e digitar performance.getEntriesByType('navigation')[0].activationStart no console. Se um valor diferente de zero for retornado, isso significa que a página foi pré-renderizada:

Console no Chrome DevTools mostrando um activationStart positivo que indica que a página foi pré-renderizada — Como testar a pré-renderização no console.

Quando a página é ativada pelo usuário que a visualiza, o evento prerenderingchange é enviado no document, que pode ser usado para ativar atividades que antes eram iniciadas por padrão no carregamento de página, mas que você quer atrasar até que a página seja realmente visualizada pelo usuário.

Com essas APIs, o JavaScript de front-end pode detectar e agir de forma adequada em páginas pré-renderizadas.

Aviso: o PerformanceNavigationTiming.type não usa o valor prerender, que era para o tipo de navegação <link rel="prerender"...> mais antigo e original. Isso pode mudar no futuro, mas, por enquanto, os clientes precisam usar a API document.prerendering para identificar páginas de pré-renderização e um campo PerformanceNavigationTiming.activationStart diferente de zero para identificar páginas pré-renderizadas que foram ativadas.

Impacto nas análises

As análises são usadas para medir o uso do site, por exemplo, usando o Google Analytics para medir visualizações de página e eventos. Ou medindo as métricas de performance das páginas usando o Monitoramento de Usuários Reais (RUM, na sigla em inglês).

As páginas só devem ser pré-renderizadas quando houver uma alta probabilidade de serem carregadas pelo usuário. Por isso, as opções de pré-renderização da barra de endereço do Chrome só acontecem quando há uma probabilidade tão alta (mais de 80% do tempo).

No entanto, principalmente ao usar a API Speculation Rules, as páginas pré-renderizadas podem ter um impacto nas análises, e os proprietários de sites podem precisar adicionar um código extra para ativar as análises apenas para páginas pré-renderizadas na ativação, já que nem todos os provedores de análise fazem isso por padrão.

Isso pode ser feito usando uma Promise que aguarda o evento prerenderingchange se um documento estiver sendo pré-renderizado ou que é resolvida imediatamente se estiver:

// Set up a promise for when the page is activated,
// which is needed for prerendered pages.
const whenActivated = new Promise((resolve) => {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenActivated;
  // Initialise your analytics
}

initAnalytics();

Uma abordagem alternativa é atrasar as atividades de análise até que a página seja mostrada pela primeira vez, o que abrangeria o caso de pré-renderização e também quando as guias são abertas em segundo plano (por exemplo, com o botão direito do mouse e abrir em uma nova guia):

// Set up a promise for when the page is first made visible
const whenFirstVisible = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

async function initAnalytics() {
  await whenFirstVisible;
  // Initialise your analytics
}

initAnalytics();

Embora isso possa fazer sentido para análises e casos de uso semelhantes, em outros casos, talvez você queira carregar mais conteúdo para esses casos e, portanto, usar document.prerendering e prerenderingchange para segmentar especificamente páginas de pré-renderização.

Reter outro conteúdo durante a pré-renderização

As mesmas APIs discutidas anteriormente podem ser usadas para reter outros conteúdos durante a fase de pré-renderização. Podem ser partes específicas do JavaScript ou elementos de script inteiros que você prefere não executar durante a fase de pré-renderização.

Por exemplo, considere este script:

<script src="https://example.com/app/script.js" async></script>

Você pode mudar isso para um elemento de script inserido dinamicamente que só é inserido com base na função whenActivated anterior:

async function addScript(scriptUrl) {
  await whenActivated;
  const script = document.createElement('script');
  script.src = 'scriptUrl';
  document.body.appendChild(script);
}

addScript('https://example.com/app/script.js');

Isso pode ser útil para reter scripts distintos que incluem análises ou renderizar conteúdo com base no estado ou em outras variáveis que podem mudar durante uma visita. Por exemplo, recomendações, estado de login ou ícones de carrinho de compras podem ser retidos para garantir que as informações mais atualizadas sejam apresentadas.

Embora isso seja mais provável de acontecer com o uso da pré-renderização, essas condições também são verdadeiras para páginas carregadas em guias em segundo plano mencionadas anteriormente. Portanto, a função whenFirstVisible pode ser usada no lugar de whenActivated.

Em muitos casos, o estado também precisa ser verificado em mudanças gerais de visibilitychange. Por exemplo, ao retornar a uma página que estava em segundo plano, todos os contadores de carrinho de compras precisam ser atualizados com o número mais recente de itens no carrinho. Portanto, esse não é um problema específico da pré-renderização, mas ela está tornando um problema existente mais óbvio.

Uma maneira de o Chrome reduzir a necessidade de encapsular manualmente scripts ou funções é reter determinadas APIs, como mencionado anteriormente, e também não renderizar iframes de terceiros. Assim, apenas o conteúdo acima disso precisa ser retido manualmente.

Avaliar o desempenho

Para medir as métricas de performance, as análises devem considerar se é melhor fazer isso com base no tempo de ativação, em vez do tempo de carregamento da página que as APIs do navegador vão informar.

As Core Web Vitals, medidas pelo Chrome usando o Chrome User Experience Report, têm como objetivo medir a experiência do usuário. Portanto, elas são medidas com base no tempo de ativação. Isso geralmente resulta em um LCP de 0 segundo, por exemplo, mostrando que essa é uma ótima maneira de melhorar suas Core Web Vitals.

A partir da versão 3.1.0, a biblioteca web-vitals foi atualizada para processar navegações pré-renderizadas da mesma forma que o Chrome mede as Core Web Vitals. Essa versão também sinaliza navegações pré-renderizadas para essas métricas no atributo Metric.navigationType se a página foi pré-renderizada total ou parcialmente.

Medir pré-renderizações

Para saber se uma página foi pré-renderizada, verifique se há uma entrada activationStart diferente de zero em PerformanceNavigationTiming. Isso pode ser registrado usando uma dimensão personalizada ou algo semelhante ao registrar as visualizações de página, por exemplo, usando a função pagePrerendered descrita anteriormente:

// Set Custom Dimension for Prerender status
gtag('set', { 'dimension1': pagePrerendered() });
// Initialise GA - including sending page view by default
gtag('config', 'G-12345678-1');

Isso vai permitir que as análises mostrem quantas navegações são pré-renderizadas em comparação com outros tipos de navegação, além de permitir que você correlacione qualquer métrica de performance ou de negócios a esses diferentes tipos de navegação. Páginas mais rápidas significam usuários mais felizes, o que geralmente tem um impacto real nas métricas de negócios, como mostram nossos estudos de caso.

Ao medir o impacto comercial da pré-renderização de páginas para navegações instantâneas, você pode decidir se vale a pena investir mais esforço no uso dessa tecnologia para permitir que mais navegações sejam pré-renderizadas ou investigar por que as páginas não estão sendo pré-renderizadas.

Medir as taxas de ocorrência

Além de medir o impacto das páginas visitadas após uma pré-renderização, também é importante medir as páginas que são pré-renderizadas e não são visitadas em seguida. Isso pode indicar que você está pré-renderizando demais e usando recursos valiosos do usuário para pouco benefício.

Isso pode ser medido disparando um evento de análise quando as regras de especulação são inseridas, depois de verificar se o navegador oferece suporte à pré-renderização usando HTMLScriptElement.supports('speculationrules'), para indicar que a pré-renderização foi solicitada. O fato de uma pré-renderização ter sido solicitada não indica que ela foi iniciada ou concluída. Como observado anteriormente, uma pré-renderização é uma dica para o navegador, que pode optar por não pré-renderizar páginas com base nas configurações do usuário, no uso atual da memória ou em outras heurísticas.

Em seguida, compare o número desses eventos com as visualizações de página de pré-renderização reais. Ou, se preferir, acione outro evento na ativação para facilitar a comparação.

A "taxa de acertos" pode ser aproximada analisando a diferença entre esses dois números. Nas páginas em que você usa a API Speculation Rules para pré-renderizar as páginas, é possível ajustar as regras adequadamente para garantir uma alta taxa de acertos e manter o equilíbrio entre usar os recursos dos usuários para ajudá-los e usá-los desnecessariamente.

Algumas pré-renderizações podem estar ocorrendo devido à pré-renderização da barra de endereço, e não apenas às suas regras de especulação. Você pode verificar o document.referrer (que ficará em branco para navegação na barra de endereço, incluindo navegações pré-renderizadas na barra de endereço) se quiser diferenciá-las.

Não se esqueça de analisar as páginas que não têm pré-renderizações, porque isso pode indicar que elas não estão qualificadas para pré-renderização, mesmo na barra de endereço. Isso pode significar que você não está se beneficiando dessa melhoria de desempenho. A equipe do Chrome quer adicionar mais ferramentas para testar a qualificação para pré-renderização, talvez semelhantes à ferramenta de teste do bfcache, e também adicionar uma API para expor o motivo da falha de uma pré-renderização.

Impacto nas extensões

Consulte a postagem dedicada sobre Extensões do Chrome: como estender a API para oferecer suporte à navegação instantânea, que detalha algumas considerações adicionais que os autores de extensões podem precisar considerar para páginas pré-renderizadas.

Feedback

A pré-renderização está em desenvolvimento ativo pela equipe do Chrome, e há muitos planos para expandir o escopo do que foi disponibilizado na versão 108 do Chrome. Seu feedback é muito importante para nós. Envie seus comentários no repositório do GitHub ou use nosso Issue Tracker. Estamos ansiosos para ouvir e compartilhar estudos de caso sobre essa nova API incrível.

Links relacionados

Agradecimentos

Imagem em miniatura de Marc-Olivier Jodoin no Unsplash

Pré-renderizar páginas no Chrome para navegação instantânea Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Uma breve história da pré-renderização

Como uma página é pré-renderizada?

Impacto da pré-renderização

Ver as previsões da barra de endereço do Chrome

API Speculation Rules

Listas de URLs

Regras de documentos

Ansiedade

Pré-busca

Prerender until script

Limites do Chrome

Como incluir regras de especulação em uma página

Cabeçalho HTTP Speculation-Rules

Campo de tag de regras de especulação

Campo target_hint das regras de especulação

Regras de especulação e SPAs

Depurar regras de especulação

Várias regras de especulação

Suporte a No-Vary-Search

Restrições das regras de especulação e melhorias futuras

Detectar suporte à API Speculation Rules

Adicionar regras de especulação dinamicamente usando JavaScript

Adicionar regras de especulação usando um Tag Manager

Cancelar regras de especulação

Regras de especulação e Política de Segurança de Conteúdo

Detectar e desativar a pré-renderização

Ativar e desativar a pré-renderização no Chrome

Detectar e desativar a pré-renderização do lado do servidor

Detectar pré-renderização em JavaScript

Impacto nas análises

Reter outro conteúdo durante a pré-renderização

Avaliar o desempenho

Medir pré-renderizações

Medir as taxas de ocorrência

Impacto nas extensões

Feedback

Links relacionados

Agradecimentos

Pré-renderizar páginas no Chrome para navegação instantânea

Cabeçalho HTTP `Speculation-Rules`

Campo `target_hint` das regras de especulação

Suporte a `No-Vary-Search`