Melhorias na API Speculation Rules

Barry Pollard

A equipe do Chrome está trabalhando em algumas atualizações interessantes da API Speculation Rules, usada para melhorar o desempenho de navegação com pré-busca ou até mesmo pré-renderização de navegações futuras. Essas melhorias adicionais agora estão disponíveis no Chrome 122 (com alguns recursos disponíveis em versões anteriores).

Com essas mudanças, o pré-carregamento e a pré-renderização de páginas ficam muito mais fáceis de implantar e menos desperdiçadas, o que esperamos que incentive a adoção.

Outros recursos

Primeiro, vamos explicar as novas adições que fizemos à API Speculation Rules e como usá-las. Depois disso, vamos mostrar uma demonstração para você conferir como elas funcionam.

Regras de documentos

Anteriormente, a API Speculation Rules funcionava especificando uma lista de URLs para pré-carregar ou pré-renderizar:

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

As regras de especulação eram semidinâmicas, porque novos scripts de regras de especulação podiam ser adicionados e os antigos removidos para descartar essas especulações. Atualizar a lista urls de um script de regras de especulação não aciona uma mudança nas especulações. No entanto, a escolha dos URLs ainda dependia do site, que os enviava do servidor no momento da solicitação da página ou criava dinamicamente essa lista usando JavaScript do lado do cliente.

As regras de lista continuam sendo uma opção para casos de uso mais simples (em que a próxima navegação é de um pequeno conjunto de navegações óbvias) ou mais avançados (em que a lista de URLs é calculada dinamicamente com base em qualquer heurística que o proprietário do site queira usar e, em seguida, inserida na página).

Como alternativa, oferecemos uma nova opção para encontrar links automaticamente usando as regras de documentos. Isso funciona extraindo URLs do próprio documento com base em uma condição where. Isso pode ser baseado nos próprios links:

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

Os seletores de CSS também podem ser usados como uma alternativa ou em conjunto com correspondências de href para encontrar links na página atual:

<script type="speculationrules">
{
  "prerender": [{
    "source": "document",
    "where": {
      "and": [
        { "selector_matches": ".prerender" },
        { "not": {"selector_matches": ".do-not-prerender"}}
      ]
    },
    "eagerness": "moderate"
  }]
}
</script>

Isso permite que uma única regra de especulação seja usada em todo o site, em vez de ter regras específicas por página, facilitando a implantação das regras de especulação.

É claro que a pré-renderização de todos os links em uma página seria um desperdício. Por isso, com essa nova capacidade, introduzimos uma configuração eagerness.

Ansiedade

Com qualquer tipo de especulação, há uma compensação entre precisão e recuperação e lead time. A pré-renderização de todos os links no carregamento da página significa que você quase certamente vai pré-renderizar um link em que o usuário clica (assumindo que ele clique em um link do mesmo site na página) e com o maior tempo de lead possível, mas com um potencial grande desperdício de largura de banda.

Por outro lado, a pré-renderização só depois que o usuário clica em um link evita o desperdício, mas com o custo de um tempo de lead muito reduzido. Isso significa que é improvável que a pré-renderização seja concluída antes que o navegador mude para essa página.

A configuração eagerness permite definir quando as especulações devem ser executadas, separando when para especular em quais URLs realizar as especulações. A configuração eagerness está disponível para regras de origem list e document e tem quatro configurações, para as quais o Chrome tem as seguintes heurísticas:

• immediate:é usada para especular o mais rápido possível, isto é, assim que as regras de especulação forem observadas.
• eager:atualmente, se comporta de maneira idêntica à configuração immediate, mas, no futuro, vamos procurar situar entre immediate e moderate.
• moderate:realiza especulações se você passar o cursor sobre um link por 200 milissegundos (ou no evento pointerdown se for antes, e no dispositivo móvel onde não há evento hover).
• 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 estático muito simples, especular com mais entusiasmo pode ter um custo baixo e ser benéfico para os usuários. Sites com arquiteturas mais complexas e payloads de página mais pesados podem preferir reduzir o desperdício especulando com menos frequência até 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 simples, que renderizaria todos os links ao passar o cursor ou clicar com o mouse como uma implementação básica, mas poderosa, de regras de especulação:

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

Limites do Chrome

Mesmo com a opção de eagerness, o Chrome tem limites para evitar o uso excessivo dessa API:

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 fará com que a mais antiga seja cancelada e substituída pela mais recente para economizar memória.

O fato de as especulações moderate e conservative serem acionadas pelos usuários nos permite usar um limite mais modesto de 2 para economizar memória. As configurações immediate e eager 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.

Uma especulação que é cancelada ao ser removida da fila FIFO pode ser acionada novamente, por exemplo, passando o cursor sobre o link, o que vai resultar na especulação do URL. Nesse caso, a especulação anterior provavelmente fez com que o navegador armazenasse alguns recursos no cache HTTP para esse URL. Portanto, a repetição da especulação deve ter uma rede muito reduzida e, portanto, custos de tempo.

Os limites de immediate e eager também são dinâmicos. A remoção de um elemento de script de regras de especulação usando esses níveis de prontidão vai criar capacidade ao cancelar as especulações removidas. Esses URLs também podem ser usados novamente se forem incluídos em um novo script de URL e o limite não tiver sido atingido.

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

• Save-Data.
• Economia de energia.
• 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.

Todas essas condições têm como objetivo reduzir o impacto de especulações excessivas quando isso é prejudicial aos usuários.

Opcional source

O Chrome 122 torna a chave source opcional, já que ela pode ser inferida pela presença das chaves url ou where. Portanto, essas duas regras de especulação são idênticas:

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

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

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.

Melhor reutilização do cache

Fizemos várias melhorias no armazenamento em cache no Chrome para que a pré-busca (ou até mesmo a pré-renderização) de um documento armazene e reutilize recursos no cache HTTP. Isso significa que a especulação ainda pode ter benefícios futuros, mesmo que não seja usada.

Isso também torna a re-especulação (por exemplo, para regras de documentos com uma configuração de moderate eager) consideravelmente mais barata, já que o Chrome vai usar o cache HTTP para recursos que podem ser armazenados em cache.

Também oferecemos suporte à nova proposta No-Vary-Search para melhorar ainda mais a reutilização do cache.

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 diferentes páginas 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 em cache anteriores de um documento que diferem apenas por esses parâmetros. Observação: no momento, esse recurso só é compatível com o Chrome (e navegadores baseados no Chromium) para especulações de navegação de pré-carregamento.

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 de 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 de produtos com o parâmetro de pesquisa id. Portanto, fazemos o pré-carregamento desse URL 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 do pré-carregamento, o navegador poderá não ter 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 deve conter um cabeçalho HTTP No-Vary-Search e aguardar a conclusão desse pré-carregamento.

Demonstração

Criamos uma demonstração em https://speculative-rules.glitch.me/common-fruits.html que pode ser usada para conferir as regras de documentos com uma configuração de prontidão moderate em ação:

Abra o DevTools e clique no painel Application. Em seguida, na seção Serviços em segundo plano, clique em Cargas especulativas, depois no painel Especulação e classifique pela coluna Status.

Ao passar o cursor sobre as frutas, você vai notar que as páginas são renderizadas antes da exibição. Clicar neles mostra um tempo de LCP muito mais rápido do que uma das receitas, que não são pré-renderizadas. Esta demonstração também é explicada neste vídeo:

Confira também a postagem do blog sobre depuração de regras de especulação para mais informações sobre como usar as Ferramentas do desenvolvedor para depurar regras de especulação.

Suporte da plataforma para regras de especulação

Embora as regras de especulação sejam relativamente simples de implementar injetando-as em um elemento <script type="speculationrules">, o suporte à plataforma pode fazer com que isso seja feito com um clique. Temos trabalhado com várias plataformas e parceiros para facilitar o lançamento das regras de especulação.

Também estamos trabalhando muito para padronizar a API pelo Grupo da comunidade do Incubador da Web (WICG, na sigla em inglês) para permitir que outros navegadores também implementem essa API incrível, se quiserem.

WordPress

A equipe de desempenho do WordPress Core (incluindo desenvolvedores do Google) criou um plug-in de regras de especulação. Com esse plug-in, é possível adicionar suporte a regras de documentos a qualquer site do WordPress com um clique. Esse plug-in também está disponível para instalação pelo WordPress Performance Lab, que você também deve considerar instalar para ficar por dentro dos plug-ins de performance relacionados da equipe.

Há dois grupos de configurações disponíveis: o Modo de especulação e a configuração Eagerness:

Para configurações mais complicadas, por exemplo, para excluir determinados URLs da pré-busca ou pré-renderização, leia a documentação.

Akamai

A Akamai é um dos principais provedores de CDN do mundo e já está testando ativamente a API Speculation Rules há algum tempo. A Akamai lançou documentação sobre como os clientes podem ativar essa API nas configurações do CDN. Eles também compartilharam os resultados impressionantes possíveis com essa nova API.

NitroPack

O NitroPack é uma solução de otimização de desempenho que usa a IA de navegação personalizada para prever quais páginas adicionar às regras de especulação. O objetivo é fornecer um tempo de lead maior do que passar o cursor sobre um link, mas sem o desperdício de especular desnecessariamente sobre todos os links observados. Consulte a documentação da API Nitropack Speculation Rules para mais informações. Essa solução inovadora mostra que as regras de lista mais antigas ainda têm muito a oferecer quando combinadas com insights específicos do site.

A equipe do Chrome também trabalhou com a NitroPack em um webinar sobre a API Speculation Rules para quem procura mais informações, incluindo uma boa discussão sobre as considerações necessárias entre especular cedo e com frequência, bem como tarde e com menos frequência.

Astro

O Astro adicionou páginas de pré-renderização usando a API Speculation Rules na versão 4.2 de forma experimental, permitindo que os desenvolvedores que usam o Astro ativem esse recurso com facilidade, voltando para um pré-carregamento padrão para navegadores que não oferecem suporte à API Speculation Rules. Leia a documentação de pré-renderização do cliente para mais informações.

Conclusão

Essas adições à API Speculation Rules permitem um uso muito mais simples desse novo recurso de desempenho para sites, com menos risco de desperdício de recursos com especulações não utilizadas. É ótimo ver que as plataformas já estão usando essa API. Esperamos que essa API seja mais adotada em 2024 e que, como resultado, os usuários finais tenham uma performance melhor.

Além dos ganhos de performance que a API Speculation Rules oferece, também estamos empolgados com as novas oportunidades que ela traz. Transições de visualização é uma nova API que permite que os desenvolvedores especifiquem transições entre navegações com mais facilidade. No momento, esse recurso está disponível para aplicativos de página única (SPAs), mas a versão de várias páginas está em andamento (e disponível com uma flag no Chrome). A pré-renderização é um complemento natural para esse recurso, garantindo que não haja atraso, o que impediria a melhoria da experiência do usuário que a transição pretende oferecer. Já observamos sites que estão testando essa combinação.

Esperamos que a API Speculation Rules seja adotada ainda mais em 2024 e vamos manter você informado sobre as melhorias feitas nela.

Agradecimentos

Miniatura de Robbie Down no Unsplash