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

Barry Pollard

Compatibilidade com navegadores

• 109
• 109
• x
• x

A equipe do Chrome está trabalhando em opções para recuperar a pré-renderização completa de futuras páginas que um usuário provavelmente acessará.

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

No passado, o Chrome oferecia suporte à dica de recurso <link rel="prerender" href="/next-page">. No entanto, ela não tinha ampla compatibilidade além do Chrome e não era uma API muito expressiva.

Esta pré-renderização legada usando a dica de link rel=prerender foi descontinuada e substituída pelo NoState Prefetch, que buscou os recursos necessários para a página futura, mas não pré-renderiza totalmente a página nem executava o JavaScript. A NoState Prefetch ajuda a melhorar o desempenho da página, melhorando o carregamento de recursos, mas não entregará um carregamento de página instantâneo como uma pré-renderização completa.

A equipe do Chrome reintroduziu a pré-renderização completa de volta no navegador. Para evitar complicações com o uso existente e permitir expansão futura da pré-renderização, esse novo mecanismo de pré-renderização não usa a sintaxe <link rel="prerender"...>, que permanece em vigor para NoState Prefetch, com uma visão de desativação disso em algum momento no futuro

Como uma página é pré-renderizada?

Uma página pode ser pré-renderizada de uma das quatro maneiras, todas com o objetivo de agilizar a navegação:

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 certeza de que você vai visitar essa página.
2. 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 pelo mecanismo de pesquisa a fazer isso.
3. 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 proativamente uma página com base em regras de especulação. Eles podem existir estaticamente nas páginas ou injetados dinamicamente por JavaScript conforme o proprietário da página achar adequado.

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. Depois, ela é "ativada" substituindo a guia em primeiro plano por essa página pré-renderizada. Se uma página for ativada antes da pré-renderização totalmente, o estado atual dela vai ficar "em primeiro plano" e continuar a carregar, o que significa que você ainda pode ter uma vantagem inicial.

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. Em vez disso, elas 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 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 de acordo com a 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 o carregamento de uma página quase instantâneo, conforme 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 ver 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 quase zero LCP, CLS reduzida (já que qualquer CLS de carga acontece antes da visualização inicial) e INP aprimorada (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 no carregamento de página já pode melhorar a experiência. Quando um link é ativado durante a pré-renderização, 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, já que isso prejudica os recursos do usuário. Faça a pré-renderização somente quando houver alta probabilidade de a página ser acessada.

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

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

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

Página de Preditores do Chrome.

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

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

Estes preditores também são o que impulsionam as opções sugeridas pela 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 maior que 50% (mostrado em âmbar), o Chrome pré-conecta ao domínio, mas não pré-renderiza a página.
• Quando o 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 da 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 de acordo com as regras do documento (disponíveis no Chrome 121), que pré-renderiza os links encontrados no documento com base em seletores de CSS ou href:

<script type="speculationrules">
{
  "prerender": [{
    "where": {
      "and": [
        { "href_matches": "/*" },
        { "not": {"selector_matches": ".do-not-prerender"}},
        { "not": {"selector_matches": "[rel=nofollow]"}}
      ]
    }
  }]
}
</script>

Observação :a API Speculation Rules usada para incluir uma chave source que estava definida como list para URLs de lista ou document para URLs de documentos, mas como isso pode ser implícito pela presença de uma chave urls ou where (que são mutuamente exclusivas), esse requisito foi removido do Chrome 121. Ainda será possível ver a chave source usada em alguns sites ou exemplos de código.

Ansiedade

Compatibilidade com navegadores

• 121
• 121
• x
• x

Uma configuração eagerness é usada para indicar quando as especulações precisam 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 são observadas.
• eager:se comporta de maneira idêntica à configuração immediate, mas no futuro vamos colocá-la em algum lugar entre immediate e moderate.
• moderate:realiza especulações se você passar o cursor sobre um link por 200 milissegundos (ou no evento pointerdown, se esse período for anterior) e em dispositivos móveis em que não há evento hover.
• conservative:especula sobre ponteiro ou toque para baixo.

O eagerness padrão para regras list é immediate. As opções moderate e conservative podem ser usadas para limitar regras list a URLs com que um usuário interage com 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 ter vários URLs, use immediate ou eager para regras document com cuidado. Consulte também a seção Limites do Chrome a seguir.

A configuração do eagerness a ser usada depende do site. Para um site leve e estático, especular com mais ansiedade pode ter pouco custo e ser benéfico para os usuários. Sites com arquiteturas mais complexas e payloads de páginas mais pesados podem preferir reduzir o desperdício especulando com menos frequência até que você receba um sinal mais positivo da intenção dos usuários para limitar o desperdício.

Cuidado :a especulação tem um custo claro para os usuários em termos de largura de banda, memória e CPU, mas também para os próprios sites. Esteja ciente do impacto que está colocando sobre seus usuários ao implementar especulações. As configurações de eagerness permitem reduzir a probabilidade de desperdício de especulações. 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é-renderia todos os links ao passar o cursor ou apontar para baixo como uma implementação básica, mas eficiente, 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 apenas para pré-buscar páginas, sem uma pré-renderização completa. 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"> antiga, que acabou de ser pré-buscada para o cache HTTP, os documentos carregados usando regras de especulação são processados da mesma forma que as navegações (mas não renderizadas) e são mantidos na memória. Portanto, ficam disponíveis mais rapidamente ao navegador quando necessário. Isso também permite a pré-busca de documentos que não são armazenados em cache no cache HTTP. 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, com <link rel="prefetch"> usado apenas para pré-buscar subrecursos.

Limites do Chrome

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

ânsia	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 "primeiro a entrar, primeiro a sair" (FIFO, na sigla em inglês): quando o limite é atingido, uma nova especulação fará com que a especulação mais antiga seja cancelada e substituída pela mais recente para economizar memória. Uma especulação cancelada pode ser acionada novamente (por exemplo, ao passar o cursor sobre o link novamente), o que fará com que o URL seja especulado novamente, apagando a especulação mais antiga. Nesse caso, a especulação anterior armazenará todos os recursos armazenáveis em cache no cache HTTP para esse URL, de modo que a especulação mais tarde 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. Portanto, têm um limite maior, já que o navegador não consegue saber quais são necessárias e quando.

Os limites de 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 impede 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 "Páginas pré-carregadas" está desativada (que também é explicitamente desativada 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 ela seria 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 mídia de notícias ou um blog pode pré-renderizar o artigo mais recente se essa geralmente for a próxima navegação para 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 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.

Aqueles que preferem a inserção dinâmica com base em ações como passar o cursor ou clicar em um link, como muitas bibliotecas já fizeram com <link rel=prefetch>, são recomendadas para analisar as regras do documento, porque elas permitem que o navegador processe 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 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 exibidas 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 por conta própria.

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

Speculation-Rules: "/speculationrules.json"

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

O recurso precisa usar o tipo MIME correto e, se for de origem cruzada, 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 principalmente quando você precisa 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 a navegação em página completa gerenciada pelo navegador, e não com páginas de apps de página única (SPA, na sigla em inglês) ou de shell do app. Essas arquiteturas não usam buscas de documentos, mas fazem buscas de API ou parciais de dados ou páginas, que são então processadas e apresentadas na página atual. Os dados necessários para essas chamadas "navegações flexíveis" 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 dedicada a depuração de regras de especulação para conhecer novos recursos do Chrome DevTools que ajudam na visualização e depuração dessa nova API.

Várias regras de especulação

Também é possível adicionar várias regras de especulação à mesma página e elas são anexadas às regras existentes. Portanto, as diferentes maneiras abaixo 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 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 exibida pelo servidor e são usados somente pelo JavaScript do lado do cliente.

Por exemplo, os parâmetros do UTM são usados pelo Google Analytics para a medição de campanhas, mas geralmente não resultam na exibição de páginas diferentes pelo servidor. Isso significa que page1.html?utm_content=123 e page1.html?utm_content=456 enviarão 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 tratados apenas no lado do cliente.

A proposta No-Variá-Pesquisa permite que um servidor especifique parâmetros que não resultem em uma diferença no recurso enviado. Assim, o navegador reutiliza as versões de um documento armazenadas em cache que diferem apenas por esses parâmetros. Isso é compatível com o Chrome (e navegadores baseados no Chromium) apenas para especulações de navegação de pré-busca.

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 vai 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 muda com base na renderização do lado do cliente usando JavaScript para buscar dados do produto usando o parâmetro de pesquisa id. Portanto, pré-buscamos esse URL com antecedência e ele precisa 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, o navegador pode não ter recebido a página /products. Nesse caso, o navegador não sabe se terá 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 ele contém um cabeçalho HTTP No-Vary-Search. Com a configuração expects_no_vary_search, o navegador pode saber que a resposta da página precisa conter um cabeçalho HTTP No-Vary-Search e aguardar a conclusão da 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, a pré-renderização é restrita a páginas da mesma origem.

Pré-renderizar páginas de origem cruzada do mesmo site (por exemplo, https://a.example.com poderia pré-renderizar uma página em https://b.example.com). Para usar isso, a página pré-renderizada (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 cancelará a pré-renderização.

As versões futuras também podem permitir a pré-renderização para páginas de origem cruzada (em que o site aceita um cabeçalho HTTP Supports-Loading-Mode: uncredentialed-prerender semelhante) e ativar a pré-renderização em novas guias.

Detectar suporte à API Speculation Rules

Você pode 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 por JavaScript

Este é um exemplo de adição de 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.

Cancelar regras de especulação

A remoção das regras de especulação resultará no cancelamento da pré-renderização. No entanto, quando isso acontecer, os recursos provavelmente já terão sido gastos para iniciar a pré-renderização. Por isso, recomendamos não fazer a pré-renderização se houver uma probabilidade de precisar 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, seja com um hash ou valor de uso único.

Um novo inline-speculation-rules pode ser adicionado a script-src, permitindo que elementos <script type="speculationrules"> injetados por scripts não gerados ou hash sejam compatíveis. Isso não suporta 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 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 melhor experiência do usuário, que talvez fosse difícil de alcançar de outra forma.

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

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

A pré-renderização só está ativada para os usuários do Chrome com a configuração "Páginas pré-carregadas" 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 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 este 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údo diferente ou evitar que uma pré-renderização aconteça. Se um código de resposta sem sucesso for retornado (ou seja, não um 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, recomendamos permitir a pré-renderização, mas atrasar as ações que só acontecerão depois que a página for realmente visualizada, usando JavaScript.

Detectar a pré-renderização em JavaScript

A API document.prerendering vai retornar true enquanto a página está pré-renderizada. Isso pode ser usado pelas páginas para evitar (ou atrasar) determinadas 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 período entre o início da pré-renderização e o momento em que o documento foi realmente ativado.

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

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 é abrir o DevTools após a pré-renderização 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:

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 Como depurar regras de especulação para saber mais.

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

Com essas APIs, o JavaScript de front-end pode detectar e agir corretamente 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"...> original e mais antigo. 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 já foram ativadas.

Impacto nas análises

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

As páginas só devem ser pré-renderizadas quando há 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 (maior que 80% das vezes).

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

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

Isso pode ser feito usando um Promise que aguarda o evento prerenderingchange se um documento estiver pré-renderizado ou é resolvido imediatamente se 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);
  } else {
    resolve();
  }
});

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

initAnalytics();

Avaliar o desempenho

Para medir as métricas de desempenho, a análise deve considerar se é melhor fazer com base no tempo de ativação, e não no tempo de carregamento da página que as APIs do navegador informarão.

Nas Core Web Vitals, medidas pelo Chrome com o Chrome User Experience Report, elas avaliam a experiência do usuário. Eles são medidos com base no tempo de ativação. Isso geralmente resulta em uma LCP de 0 segundos, por exemplo, mostrar que essa é uma ótima maneira de melhorar suas Core Web Vitals.

Na versão 3.1.0 e mais recentes, a biblioteca web-vitals foi atualizada para lidar com 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.

Medir pré-renderizações

É possível ver 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 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 permite que sua análise mostre quantas navegação são pré-renderizadas em comparação com outros tipos de navegação e também permite correlacionar quaisquer métricas de desempenho ou de negócios com esses diferentes tipos de navegação. Páginas mais rápidas significam usuários mais satisfeitos, o que geralmente pode ter um impacto real nas medidas dos 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 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 sugerir que você está fazendo a pré-renderização em excesso e usando recursos valiosos do usuário em troca de pouco benefício.

Isso pode ser medido pelo acionamento de um evento de análise quando 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 simples fato de uma pré-renderização foi solicitada não indica que ela foi iniciada ou concluída, já que, conforme observado anteriormente, ela é uma dica para o navegador e 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, é possível comparar o número desses eventos com as visualizações de página pré-renderizadas reais. Também é possível disparar outro evento na ativação se isso facilitar a comparação.

A "taxa de hits bem-sucedidos" pode ser aproximada ao observar a diferença entre esses dois valores. Para páginas em que você usa a API Speculation Rules para pré-renderizar as páginas, é possível ajustar as regras adequadamente para manter uma taxa de hits alta e manter o equilíbrio entre usar os recursos dos usuários para ajudá-los em relação ao uso desnecessário.

Saiba que algumas pré-renderizações podem ocorrer devido à pré-renderização da barra de endereço e não apenas às suas regras de especulação. Você pode conferir a document.referrer, que vai estar em branco na navegação da barra de endereço, incluindo navegações pré-renderizadas da barra de endereço, se quiser diferenciá-las.

Analise também as páginas que não têm pré-renderização, porque isso pode indicar que elas não estão qualificadas para pré-renderização, mesmo na barra de endereço. Isso significa que você não está se beneficiando dessa melhoria de desempenho. A equipe do Chrome está tentando adicionar mais ferramentas para testar a qualificação para pré-renderização, semelhantes à ferramenta de teste bfcache, e possivelmente adicionar uma API para expor o motivo da falha na 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. Agradecemos qualquer feedback sobre o repositório do GitHub ou sobre o uso do nosso rastreador de problemas e estamos ansiosos para conhecer e compartilhar estudos de caso dessa nova API incrível.

Links relacionados

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

Agradecimentos

Imagem em miniatura por Marc-Olivier Jodoin no Unsplash (link em inglês)