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

Barry Pollard

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

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

No passado, o Chrome oferecia suporte à sugestão de recurso <link rel="prerender" href="/next-page">, mas não tinha suporte amplo além 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 buscava os recursos necessários para a página futura, mas não fazia a pré-renderização completa nem executava o JavaScript. A pré-busca sem estado ajuda a melhorar o desempenho da página, 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 sem estado, com a intenção de descontinuar esse recurso no futuro.

Como uma página é pré-renderizada?

Uma página pode ser pré-renderizada de quatro maneiras, todas com o objetivo de 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, com base no seu histórico de navegação anterior.
2. Quando você usa a barra de favoritos, o Chrome pode pré-renderizar a página automaticamente se você mantiver o ponteiro sobre um dos botões de favoritos.
3. 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, quando instruído a fazer isso pelo mecanismo de pesquisa.
4. Os sites podem usar a API Speculation Rules para informar programaticamente ao Chrome quais páginas pré-renderizar. Isso substitui o que o <link rel="prerender"...> costumava fazer e permite que os sites pré-renderizem proativamente uma página com base nas regras de especulação. Elas podem existir de forma estática nas páginas ou ser injetadas dinamicamente pelo JavaScript conforme o proprietário da página achar melhor.

Em cada um desses casos, o 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á sendo carregado, 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, prompts) não são ativadas nesse estado e são adiadas 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 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.

Impacto da pré-renderização

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

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. Isso também pode ter um impacto direto nas Principais métricas da Web de um site, com LCP quase zero, CLS reduzido (já que qualquer CLS de carregamento acontece antes da visualização inicial) e INP melhorado (já que o carregamento precisa 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 carregando.

No entanto, a pré-renderização usa mais memória e largura de banda de rede. Cuidado para não sobrecarregar os recursos do usuário. Só pré-carregue quando houver uma grande probabilidade de navegação para a página.

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

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

No primeiro caso de uso, você pode conferir as previsões de URLs do Chrome na página chrome://predictors:

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. 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 responsáveis pelas opções sugeridas na barra de endereço:

.

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

• Para um nível de confiança maior que 50% (mostrado em âmbar), o Chrome faz a pré-conexão proativa 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 vai pré-renderizar o URL.

A API Speculation Rules

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

<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>

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

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: comporta-se de maneira idêntica à configuração immediate, mas, no futuro, vamos procurar situar 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: especula no ponteiro ou no toque.

O eagerness padrão para regras list é immediate. As opções moderate e conservative podem ser usadas para limitar as regras list a URLs com os quais 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 adequadas.

O eagerness padrão para regras document é conservative. Como um documento pode consistir em muitos URLs, o uso de immediate ou eager para regras 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 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é receber um indicador mais positivo de intenção 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 renderizaria 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>

Limites do Chrome

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

As configurações moderate e conservative, que dependem da interação do usuário, funcionam de forma FIFO (first in, first out): depois de atingir o limite, uma nova especulação faz com que a mais antiga seja cancelada e substituída pela mais recente para economizar memória. Uma especulação cancelada pode ser acionada novamente, por exemplo, passando o cursor sobre o link. Isso vai resultar na especulação do URL novamente, substituindo a especulação mais antiga. Nesse caso, a especulação anterior vai ter armazenado em cache todos os recursos armazenáveis no cache HTTP para esse URL. Portanto, a especulação por mais tempo terá um custo reduzido. É por isso que o limite é definido como o limite modesto 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 não é possível para o navegador saber quais são necessárias e quando.

Os limites de immediate e eager também são dinâmicos. Portanto, remover um elemento de script de URL list vai criar capacidade ao cancelar as 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 pouca bateria.
• Limitações de memória.
• Quando a configuração "Pré-carregar páginas" está desativada (o que também é desativado 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 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 de forma estática no HTML da página ou inseridas dinamicamente na página pelo JavaScript:

• Regras de especulação incluídas de forma estática: por exemplo, um site de notícias ou um blog pode pré-render o artigo mais recente, se ele for a próxima navegação para uma grande proporção de usuários. Como alternativa, as regras de documentos com moderate ou conservative podem ser usadas para especular como os usuários interagem com links.
• Regras de especulação inseridas de maneira dinâmica: podem ser baseadas na lógica do aplicativo, personalizadas para o usuário ou baseadas em outras heurísticas.

Aqueles 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 no passado com <link rel=prefetch>, devem consultar as regras de documentos, já que elas permitem que o navegador processe muitos dos seus casos de uso.

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

Cabeçalho HTTP Speculation-Rules

As regras de especulação também podem ser enviadas 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 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 de origem cruzada, precisa passar por uma verificação do 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.

Regras de especulação e SPAs

As regras de especulação são compatíveis apenas com navegações de página completa gerenciadas pelo navegador, e não com apps de página única (SPA) ou páginas 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 essas chamadas "navegação suave" podem ser pré-carregados 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 aplicativo em uma página anterior. Isso pode ajudar a compensar alguns dos custos de carregamento inicial extras 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 dedicada sobre regras de especulação de depuração para conferir 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

Ao pré-carregar 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 do UTM são usados pelo Google Analytics para medir campanhas, mas geralmente não resultam em páginas diferentes sendo enviadas 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, para que ela possa 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 no 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é-carregamento, embora estejamos procurando oferecer suporte a isso também para pré-renderização.

As regras de especulação oferecem suporte ao uso de 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.

<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 pode ser diferente com base na renderização do lado do cliente usando JavaScript para buscar dados do produto com 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 sabe se ele vai conter o cabeçalho HTTP No-Vary-Search. O navegador pode escolher entre buscar o link novamente ou esperar a conclusão do pré-carregamento para verificar 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 precisa conter um cabeçalho HTTP No-Vary-Search e aguarde a conclusão dessa pré-busca.

Restrições das 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 a 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.

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

As regras de especulação já oferecem suporte a pré-carregamentos entre origens, mas apenas quando os cookies do domínio não existem. Se existirem cookies do usuário que visitou esse site antes, a especulação não será acionada e exibirá uma falha no DevTools.

Devido às 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 entre origens para links entre origens é necessária para a segurança. É uma melhoria em relação a <link rel="prefetch"> para destinos de origem cruzada, que também não envia cookies, mas ainda tenta o pré-carregamento, o que resultará em um pré-carregamento desperdiçado que precisa ser reenviado ou, pior ainda, no carregamento incorreto da página.

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

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 de forma dinâmica usando 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 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 registra 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 Elements nas Ferramentas do desenvolvedor do Chrome 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 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 essas regras em JavaScript, em vez de adicionar o elemento <script type = "speculationrules"> diretamente no GTM, pelos mesmos motivos mencionados anteriormente:

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 Content-Security-Policy script-src se o site usar isso, seja com um hash ou um valor de uso único.

Um novo inline-speculation-rules pode ser adicionado a script-src, permitindo que elementos <script type="speculationrules"> injetados de scripts hash ou nonced sejam aceitos. 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, muitas vezes 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 com base na solicitação inicial ou na execução do JavaScript na página.

Ativar e desativar o pré-render 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, o pré-render também é desativado em dispositivos com pouca memória ou se o sistema operacional estiver 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 que usam 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údos diferentes ou impedir que uma pré-renderização aconteça. Se um código de resposta final com falha for retornado, ou seja, não estiver no intervalo de 200 a 299 após os redirecionamentos, a página não será renderizada previamente, e qualquer página de pré-carregamento 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 diferente de 2XX (como 503) é 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 pré-renderização em JavaScript

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

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

Você pode ter uma função para verificar páginas de pré-renderização e pré-renderização, como esta:

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

A maneira mais fácil de saber 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, você saberá que a página foi pré-renderizada:

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 da 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 nas páginas pré-renderizadas.

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 desempenho das páginas usando o Monitoramento de usuários reais (RUM).

As páginas só devem ser pré-renderizadas quando houver 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 (mais de 80% do tempo).

No entanto, principalmente ao usar a API Speculation Rules, as páginas pré-renderizadas podem ter um impacto na análise, e os proprietários de sites podem precisar adicionar um código extra para ativar apenas a análise de 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 um Promise que aguarda o evento prerenderingchange se um documento estiver sendo pré-renderizado, ou é resolvido imediatamente se ele está agora:

// 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 tanto o caso de pré-renderização quanto quando as guias são abertas em segundo plano (por exemplo, com clique com o botão direito do mouse e abertura 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 seja necessário carregar mais conteúdo. Nesses casos, use document.prerendering e prerenderingchange para segmentar especificamente as páginas de pré-renderização.

Reter outros conteúdos 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 de JavaScript ou elementos de script inteiros que você prefere não executar durante a etapa de pré-renderização.

Por exemplo, considerando este script:

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

É possível mudar isso para um elemento de script inserido dinamicamente que só insere 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 diferentes que incluem análises ou renderizar conteúdo com base no estado ou em outras variáveis que podem mudar durante a visita. Por exemplo, recomendações, estado de login ou ícones de cesta de compras podem ser retidos para garantir que as informações mais atualizadas sejam apresentadas.

Embora isso seja mais provável com o uso da pré-renderização, essas condições também são válidas 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 do prerender, mas o prerender está apenas tornando um problema existente mais óbvio.

Uma maneira de o Chrome reduzir a necessidade de agrupar scripts ou funções manualmente é que certas APIs são retidas, conforme mencionado anteriormente, e também iframes de terceiros não são renderizados. Portanto, apenas o conteúdo acima é necessário reter manualmente.

Avaliar o desempenho

Para medir as métricas de performance, a análise precisa considerar se é melhor medir com base no tempo de ativação ou no tempo de carregamento da página que as APIs do navegador vão informar.

As Core Web Vitals, medidas pelo Chrome no Chrome User Experience Report, têm como objetivo avaliar a experiência do usuário. 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 (link em inglês) 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 totalmente ou parcialmente.

Medir pré-renderizações

É possível saber se uma página foi pré-renderizada com uma entrada activationStart diferente de zero de 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 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 significam usuários mais felizes, o que pode ter 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 que são visitadas após uma pré-renderização, também é importante medir as páginas que são pré-renderizadas e não visitadas posteriormente. Isso pode significar que você está fazendo muitas pré-renderizações e usando recursos valiosos do usuário com 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 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. Ou, se preferir, acione outro evento na ativação para facilitar a comparação.

A "taxa de sucesso" pode ser aproximada analisando a diferença entre esses dois números. Para 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 taxa de hits alta e manter o equilíbrio entre o uso dos recursos dos usuários para ajudar e o uso desnecessário.

Algumas pré-renderizações podem estar acontecendo 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 fica em branco para a navegação na barra de endereço, incluindo a navegação na barra de endereço pré-renderizada) se quiser diferenciar esses elementos.

Verifique 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 pré-renderizações, mesmo na barra de endereço. Isso pode significar que você não está se beneficiando da melhoria de desempenho. A equipe do Chrome quer adicionar ferramentas extras para testar a qualificação de pré-renderização, talvez semelhante à ferramenta de teste do bfcache, e também adicionar uma API para mostrar por que uma pré-renderização falhou.

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 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. Aceitamos qualquer feedback sobre o repositório do GitHub ou usando o rastreador de problemas. Além disso, queremos ouvir e compartilhar estudos de caso sobre essa nova API.

Links relacionados

• Codelab de regras de especulação
• Como depurar as regras de especulação
• Introdução à pré-busca sem estado
• Especificação da API Speculation Rules
• Repositório do GitHub da especulação de navegação
• Extensões do Chrome: como estender a API para oferecer suporte à navegação instantânea

Agradecimentos

Imagem em miniatura de Marc-Olivier Jodoin no Unsplash