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

Barry Pollard

Compatibilidade com navegadores

• 109
• 109
• x
• x

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

Prefere o vídeo ao ler? Confira este vídeo do Google I/O (em inglês) para ver um resumo do conteúdo da página.

Um breve histórico da pré-renderização

No passado, o Chrome era compatível com a dica de recurso <link rel="prerender" href="/next-page">, mas não havia suporte além do Chrome e não era uma API muito expressiva.

A pré-renderização legada usando a dica rel=prerender de link foi descontinuada e substituída por NoState Prefetch, que buscava os recursos necessários para a página futura, mas não pré-renderizou totalmente a página nem executou o JavaScript. A pré-busca NoState ajuda a melhorar o desempenho da página, melhorando o carregamento de recursos, mas não fornece 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 já existente e permitir a expansão futura da pré-renderização, esse novo mecanismo de pré-renderização não vai usar a sintaxe <link rel="prerender"...>, que permanece em vigor para a pré-busca NoState, com o objetivo de descontinuá-la em algum momento no futuro.

Como uma página é pré-renderizada?

Uma página pode ser pré-renderizada de quatro maneiras, que visam tornar a navegação mais rápida:

1. Quando você digita um URL na barra de endereço do Chrome (também conhecida como "omnibox"), o Chrome pode pré-renderizar automaticamente a página para você, se tiver alta confiança de que você visitará essa página.
2. Quando você usa a barra de favoritos, o Chrome pode pré-renderizar automaticamente a página mantendo o ponteiro sobre um dos botões de favoritos.
3. Quando você digita um termo de pesquisa na barra de endereço do Chrome, ele pode pré-renderizar automaticamente a página de resultados da pesquisa, quando instruído pelo mecanismo de pesquisa.
4. Os sites podem usar a API Speculation Rules para informar programaticamente ao Chrome 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 nas regras de especulação dela. Eles podem existir estaticamente nas páginas ou ser injetados dinamicamente pelo JavaScript, conforme o proprietário da página julgar necessário.

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, fosse "ativada" pela substituição da 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 estará "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 invasivos (por exemplo, solicitações) não são ativadas nesse estado. Elas são atrasadas até que a página seja ativada. No pequeno número de casos em que isso ainda não é possível, a pré-renderização é cancelada. A equipe do Chrome está trabalhando para expor os motivos do cancelamento de pré-renderização como uma API e também aprimorando 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 como uma melhoria progressiva. Ao contrário de preload, a pré-renderização é uma dica especulativa, e o navegador pode optar por não agir com base na dica com base nas configurações do usuário, no uso atual da memória ou em 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 abaixo:

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

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

Mesmo quando uma página é ativada antes de ser totalmente carregada, ter uma vantagem inicial no carregamento da 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 sendo carregada.

No entanto, a pré-renderização usa mais memória e largura de banda de rede. Tenha cuidado para não pré-renderizar demais, à custa de recursos do usuário. Pré-renderize somente quando houver uma grande probabilidade de a página ser acessada.

Consulte a seção Como medir o desempenho para mais informações sobre como avaliar o impacto real no desempenho na sua análise.

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

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

Página de Previsões do Chrome

.

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

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

Estes preditores também são o que orienta as opções sugeridas da barra de endereço que você pode ter notado:

Recurso "Typeahead" da barra de endereço

.

O Chrome atualiza continuamente os preditores com base na sua digitação e seleções.

• Para um nível de confiança acima de 50% (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 80% (mostrado em verde), o Chrome pré-renderiza o URL.

API Speculation Rules

Para a terceira opção de pré-renderização, os desenvolvedores Web podem inserir instruções JSON nas páginas para informar ao navegador quais URLs devem ser pré-renderizados:

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

Ou pelas regras do documento (disponíveis no Chrome 121), que pré-renderiza os links encontrados no documento com base em seletores href (com base na API URL Pattern) 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>

Observação: a API Speculation Rules era usada para incluir uma chave source que era definida como list para URLs de lista ou document para URLs de documentos. No entanto, como isso pode ser implícito pela presença de uma chave urls ou where (mutuamente exclusiva), esse requisito foi removido do Chrome 121. A chave source ainda pode ser usada em alguns sites ou no exemplo de código.

A equipe do Chrome preparou um codelab sobre regras de especulação que vai ajudar você a adicionar regras de especulação a um site.

Ansiedade

Compatibilidade com navegadores

• 121
• 121
• x
• x

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

• immediate:é usado para especular o mais rápido possível, ou seja, assim que as regras de especulação forem observadas.
• eager:se comporta de maneira idêntica à configuração da immediate, mas, no futuro, vamos colocar isso em algum lugar entre immediate e moderate.
• moderate:faz especulações se você mantém o ponteiro sobre um link por 200 milissegundos (ou no evento pointerdown, se isso acontecer antes) e em dispositivos móveis, onde não há um evento hover.
• conservative:especifica o ponteiro ou o toque para baixo.

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

O eagerness padrão para regras document é conservative. Dado que um documento pode conter muitos URLs, o uso de immediate ou eager para regras de document deve ser usado com cuidado. 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 leve e estático, especular com mais antecipação pode ter pouco custo e ser benéfico para os usuários. Sites com arquiteturas mais complexas e payloads de página mais pesados podem preferir reduzir o desperdício especulando com menos frequência até que você receba sinais mais positivos de intenção dos usuários em limitar o desperdício.

Cuidado: a especulação excessiva tem um custo claro para os usuários em relação aos custos de largura de banda, memória e CPU, mas também para os próprios sites. Esteja ciente do impacto que você está causando nos usuários ao implementar especulações. As configurações eagerness permitem reduzir a probabilidade de especulações desperdiçadas. O Chrome também limita as especulações para reduzir o impacto do uso excessivo.

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 o link por 200 milissegundos ou no evento de ponteirodown 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. Muitas vezes, esse pode ser um bom primeiro passo 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 acabou de ser pré-buscada no cache HTTP, os documentos carregados usando regras de especulação são processados da mesma forma que as navegações (mas não são renderizadas) e são mantidos na memória para que sejam disponibilizados mais rapidamente ao navegador quando necessário. Isso também permite que os documentos que não são armazenáveis em cache no cache HTTP sejam pré-buscados. Devido a problemas com a pré-busca de documentos usando <link rel="prefetch">, é recomendável usar regras de especulação para isso daqui em diante. O <link rel="prefetch"> é usado apenas para pré-busca de sub-recursos.

Limites do Chrome

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

entusiasmo	Pré-busca	Pré-renderizar
immediate / eager	50	10
moderate / conservative	2 (FIFO)	2 (FIFO)

Limites de especulação no Chrome.

As configurações moderate e conservative, que dependem da interação do usuário, funcionam de maneira First In, First Out (FIFO, na sigla em inglês): depois de atingir o limite, uma nova especulação fará com que a especulação mais antiga seja cancelada e substituída pela mais recente para conservar memória. Uma especulação cancelada pode ser acionada novamente, por exemplo, passando o cursor mais uma vez sobre esse link, o que resultará na nova especulação do URL, empurrando a especulação mais antiga. Nesse caso, a especulação anterior armazenará em cache todos os recursos armazenáveis em cache no Cache HTTP desse URL. Portanto, especular mais um tempo deve ter um custo reduzido. É por isso que o limite é definido como o modesto limite de 2. 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 o navegador não sabe quais são necessárias e quando.

Os limites immediate e eager também são dinâmicos. Portanto, a remoção de um elemento de script de URL list criará capacidade ao cancelar essas especulações removidas.

O Chrome também impedirá o uso de especulações em determinadas condições, incluindo:

• Save-Data.
• Economia de energia quando ativada e com bateria fraca.
• Restrições de memória.
• Quando a configuração "Pré-carregar páginas" está desativada, o que também é explicitamente desativado 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 de origem cruzada em páginas pré-renderizadas até a ativação.

Todas essas condições visam reduzir o impacto da especulação excessiva quando isso seria prejudicial para os 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 dinamicamente inseridas na página pelo JavaScript:

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

As que favorecem a inserção dinâmica com base em ações como passar o cursor ou clicar em um link (como muitas bibliotecas fizeram antes com <link rel=prefetch>) são recomendadas para analisar as regras de documentos, porque elas permitem que o navegador lide com muitos dos seus casos de uso.

As regras de especulação podem ser adicionadas na <head> ou na <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 acionadas depois que a página é ativada.

Cabeçalho HTTP Speculation-Rules

Compatibilidade com navegadores

• 121
• 121
• x
• x

Origem

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

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

Speculation-Rules: "/speculationrules.json"

Aviso :como esse cabeçalho é estruturado, as aspas são importantes e precisam ser incluídas no valor do cabeçalho.

Esse recurso precisa usar o tipo MIME correto e, se for um recurso de origem cruzada, passar em 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 particularmente útil se você precisar selecionar alguns ou todos os links de mesma origem.

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 para páginas de apps de página única (SPA) ou de shell do app. Essa arquitetura não usa buscas de documentos, mas faz buscas parciais ou de API de dados ou páginas, que são então processados e apresentados na página atual. Os dados necessários para isso, as chamadas "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 a postagem sobre depuração de regras de especulação (link em inglês) para conhecer os novos recursos do Chrome DevTools que ajudam a visualizar e depurar essa nova API.

Várias regras de especulação

Várias regras de especulação também podem ser adicionadas à mesma página e anexadas às regras existentes. 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

Compatibilidade com navegadores

• 121
• 121
• x
• x

Origem

Ao fazer a pré-busca ou pré-renderização de 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 exibida pelo servidor e usados apenas pelo JavaScript do lado do cliente.

Por exemplo, os parâmetros de UTM (monitor de tráfego do Urchin) são usados pelo Google Analytics para a medição de campanhas, mas geralmente não resultam na exibição de páginas diferentes do servidor. Isso significa que page1.html?utm_content=123 e page1.html?utm_content=456 fornecerão a mesma página do servidor, de modo que a mesma página poderá 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 resultem em diferença em relação ao recurso enviado. Isso permite que o navegador reutilize versões armazenadas em cache de um documento que diferem apenas nesses parâmetros. Essa opção é compatível com o Chrome (e navegadores baseados no Chromium) para especulações de navegação de pré-busca (também queremos oferecer suporte para a pré-renderização).

As regras de especulação são compatíveis com o uso de expects_no_vary_search para indicar onde um cabeçalho HTTP No-Vary-Search precisa ser retornado. Isso pode ajudar a evitar downloads desnecessários.

<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 da página inicial /products é o mesmo para os IDs do produto 123 e 124. No entanto, o conteúdo da página será diferente com base na renderização do lado do cliente usando JavaScript para buscar dados do produto usando o parâmetro de pesquisa id. Portanto, fazemos a pré-busca desse URL, e ele 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 da conclusão da pré-busca, talvez o navegador não tenha recebido a página /products. Nesse caso, o navegador não saberá se conterá o cabeçalho HTTP No-Vary-Search. O navegador pode escolher se quer buscar o link novamente ou aguardar a conclusão da pré-busca para ver se 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 precisa conter um cabeçalho HTTP No-Vary-Search e aguarde a conclusão dessa pré-busca.

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

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

Por padrão, as especulações são restritas às páginas de mesma origem. Especulação de páginas de origem cruzada 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 aceitar incluindo 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 para páginas de origem cruzada que não são do mesmo site, desde que não existam cookies na página pré-renderizada e a página pré-renderizada ative com um cabeçalho HTTP Supports-Loading-Mode: uncredentialed-prerender semelhante.

As regras de especulação já aceitam pré-buscas de origem cruzada, mas apenas quando não existem cookies para o domínio de origem cruzada. Se existirem cookies do usuário que visitou esse site antes, a especulação não será acionada e exibirá uma falha no DevTools.

Considerando as limitações atuais, um padrão que pode melhorar a experiência dos usuários com links internos e externos sempre que possível é pré-renderizar URLs de mesma origem e tentar pré-buscar URLs de origem cruzada:

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

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

As regras de especulação não são compatíveis com a pré-busca de páginas controladas por service workers. Estamos trabalhando para adicionar esse suporte. Siga este problema com o service worker de suporte para atualizações. A pré-renderização tem suporte para páginas controladas pelo service worker.

Compatibilidade com a API Detect Speculation Rules

Você pode detectar o suporte da 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 de forma dinâmica com o JavaScript

Este é 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 com a inserção de JavaScript nesta página de demonstração de pré-renderização.

Inserir um elemento <script type = "speculationrules"> diretamente no DOM não registra as regras de especulação, já que ele precisa ser adicionado conforme mostrado anteriormente. Por exemplo, a edição direta do painel Elements no Chrome DevTools para adicionar o elemento <script type = "speculationrules"> não registra as regras de especulação. Em vez disso, o script para adicioná-la dinamicamente ao DOM precisa ser executado no console para inserir as regras.

Adicionar regras de especulação por meio de um Gerenciador de tags

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

Como adicionar regras de especulação com o Gerenciador de tags do Google.

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

Cancelar regras de especulação

A remoção de regras de especulação fará com que a pré-renderização seja cancelada, mas, quando isso acontecer, os recursos provavelmente já terão sido gastos para iniciar a pré-renderização. Por isso, é recomendável não pré-renderizar se houver a possibilidade de cancelar a pré-renderização.

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 Política de Segurança de Conteúdo do script-src se o site usar isso, usando um hash ou um valor de uso único.

Um novo inline-speculation-rules pode ser adicionado a script-src, permitindo o suporte a elementos <script type="speculationrules"> injetados de scripts hash ou não cedidos. Ele não é compatível com as regras incluídas no HTML inicial. Por isso, elas 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 a renderização rápida da página, geralmente instantânea. Isso beneficia o usuário e o proprietário do site, já que as páginas pré-renderizadas permitem uma experiência do usuário melhor que seria 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 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 está nos modos Salvar dados ou Economia 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 com a API Speculation Rules terão esse cabeçalho definido como apenas prefetch:

Sec-Purpose: prefetch

Os servidores podem responder com base nesse cabeçalho para registrar solicitações de especulação, retornar conteúdos diferentes ou impedir que uma pré-renderização aconteça. Se um código de resposta sem sucesso for retornado (ou seja, não 200 ou 304), a página não será pré-renderizada, e qualquer página de pré-busca será descartada.

Se você não quiser que uma página específica seja pré-renderizada, essa é a melhor maneira de garantir que isso não aconteça. No entanto, para oferecer a melhor experiência, é recomendável permitir a pré-renderização, mas atrasar as ações que só devem acontecer quando a página for realmente visualizada, usando JavaScript.

Detectar a pré-renderização em JavaScript

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

Quando um documento pré-renderizado é ativado, o activationStart de PerformanceNavigationTiming também é definido como um horário diferente de zero, representando o momento 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 pré-renderizadas, como as seguintes:

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

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

Como testar a pré-renderização no console.

Dica:outros recursos de depuração do Chrome DevTools estão disponíveis para depurar páginas pré-buscadas e pré-renderizadas. Consulte a postagem Depuração de regras de especulação para saber mais.

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

Com o uso dessas APIs, o JavaScript de front-end pode detectar e agir adequadamente sobre as páginas pré-renderizadas.

Aviso:o PerformanceNavigationTiming.type não usa o valor prerender, que era 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 desde então.

Impacto na análise

O Analytics mede o uso do site, por exemplo, o Google Analytics para medir visualizações de página e eventos. Ou avaliando as métricas de desempenho das páginas usando o Monitoramento real de usuários (RUM, na sigla em inglês).

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

No entanto, especialmente ao usar a API Speculation Rules, as páginas pré-renderizadas podem afetar a análise, e os proprietários do site talvez precisem adicionar um código extra para permitir a análise apenas de páginas pré-renderizadas na ativação, já que nem todos os provedores de análise podem fazer isso por padrão.

Observação:por padrão, o Google Analytics processa a pré-renderização atrasando a ativação. A Tag do editor do Google (GPT) e o Google AdSense também atrasam até a ativação.

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

// 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 até que a página fique visível, o que cobriria tanto o caso de pré-renderização quanto quando as guias forem abertas em segundo plano (por exemplo, ao clicar 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 whenActivated = new Promise((resolve) => {
  if (document.hidden) {
    document.addEventListener('visibilitychange', resolve, {once: true});
  } else {
    resolve();
  }
});

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

initAnalytics();

Embora isso faça sentido para análises e casos de uso semelhantes, em outros casos, pode ser necessário carregar mais conteúdo. Portanto, use document.prerendering e prerenderingchange para segmentar especificamente as páginas de pré-renderização.

Medir o desempenho

Para avaliar as métricas de desempenho, o Google Analytics deve considerar se é melhor medi-las com base no tempo de ativação em vez do tempo de carregamento da página que as APIs do navegador informam.

As Core Web Vitals, medidas pelo Chrome no Chrome User Experience Report, têm como objetivo avaliar a experiência do usuário. Portanto, elas são medidas com base no tempo de ativação. Isso geralmente resulta em uma LCP de 0 segundos, por exemplo, o que mostra 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 maneira que o Chrome mede as Core Web Vitals. Ela também sinaliza navegações pré-renderizadas para essas métricas no atributo Metric.navigationType se a página foi total ou parcialmente pré-renderizada.

Medir pré-renderizações

Se uma página for pré-renderizada, isso pode ser visto com uma entrada activationStart diferente de zero de PerformanceNavigationTiming. Isso pode ser registrado usando uma dimensão personalizada ou 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 permitirá que sua análise mostre quantas navegação são pré-renderizadas em comparação com outros tipos de navegação e também permitirá que você correlacione métricas de desempenho ou de negócios com esses diferentes tipos de navegação. Páginas mais rápidas deixam os usuários mais satisfeitos, o que pode ter um impacto real nas medidas de negócios, como mostram nossos estudos de caso.

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

Medir as taxas de hits

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 visitadas depois. Isso pode significar 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. Observe que apenas porque uma pré-renderização foi solicitada, não indica que uma pré-renderização foi iniciada ou concluída, já que, como observado anteriormente, uma pré-renderização é uma dica para o navegador e ele pode optar por não pré-renderizar páginas nas configurações do usuário, uso atual da memória ou outras heurísticas.

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

A "taxa de hits bem-sucedidos" pode ser aproximada com base na diferença entre esses dois números. Nas páginas em que você usa a API Speculation Rules para pré-renderizar, é possível ajustar as regras de forma adequada para garantir que você mantenha uma taxa de hits alta e mantenha o equilíbrio entre usar os recursos dos usuários para ajudá-los em vez de usá-los sem necessidade.

Esteja ciente de que alguma pré-renderização pode estar ocorrendo devido à pré-renderização da barra de endereço, e não apenas às 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 da barra de endereço) se quiser diferenciá-los.

Analise também as páginas que não têm pré-renderizações, porque isso pode indicar que elas não estão qualificadas para a pré-renderização, mesmo na barra de endereço. Isso pode significar que você não está se beneficiando da melhoria de desempenho. A equipe do Chrome pretende adicionar outras ferramentas para testar a qualificação de pré-renderização, talvez semelhante à ferramenta de teste de bfcache (link em inglês), e também adicionar uma API para expor o motivo da falha de pré-renderização.

Impacto nas extensões

Consulte a postagem dedicada em 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 precisam 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 do Chrome 108. Agradecemos qualquer feedback no repositório do GitHub ou no nosso Issue Tracker e estamos ansiosos para ouvir e compartilhar estudos de caso dessa nova API incrível.

Links relacionados

• Codelab de regras de especulação
• Depuração de regras de especulação
• Introdução à pré-busca NoState
• Especificação da API Speculation Rules
• O repositório do GitHub de especulação de navegação (link em inglês)
• Extensões do Chrome: extensão da API para oferecer suporte à navegação instantânea

Agradecimentos

Imagem em miniatura de Marc-Olivier Jodoin no Unsplash