Melhorias na API Speculation Rules

Barry Pollard

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

Essas mudanças tornam a pré-busca e pré-renderização de páginas consideravelmente mais fácil de implantar e com menos desperdício, o que esperamos que incentive a adoção.

Mais recursos

A primeira é uma explicação das novas adições à API Speculation Rules e como usá-las. Depois disso, vamos mostrar uma demonstração para que você possa vê-los em ação.

Regras do documento

Anteriormente, a API Speculation Rules funcionava especificando uma lista de URLs para pré-busca ou pré-renderização:

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

As regras de especulação eram semidinâmicas, ou seja, novos scripts de regra de especulação poderiam ser adicionados e scripts antigos removidos para descartar essas especulações. A atualização da lista de urls de um script de regras de especulação existente não aciona uma mudança nas especulações. No entanto, ele ainda deixava a escolha de URLs para o site, seja enviando-os do servidor no momento da solicitação da página ou criando dinamicamente essa lista por meio do JavaScript do lado do cliente.

As regras de lista permanecem como uma opção para casos de uso mais simples (em que a próxima navegação é de um pequeno conjunto de óbvios) ou mais avançados (em que a lista de URLs é calculada dinamicamente com base em qualquer heurística que o proprietário do site quer usar e depois inserida na página).

Como alternativa, oferecemos uma nova opção de localização automática de links usando as regras do documento. Isso funciona buscando 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 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 um único conjunto de regras de especulação seja usado em todo o site, em vez de ter regras de especulação específicas por página, facilitando muito a implementação de regras de especulação pelos sites.

É claro que pré-renderizar todos os links em uma página seria um desperdício de tempo. Por isso, com esse novo recurso, apresentamos uma configuração eagerness.

Ansiedade

Em qualquer tipo de especulação, há uma troca entre precisão e recall e tempo de lead. Com a pré-renderização de todos os links no carregamento de página, você certamente vai pré-renderizar um link em que um usuário clicar (supondo que ele clique em um link do mesmo site na página) e com o maior tempo de lead possível, mas com um grande desperdício de largura de banda.

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

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

• immediate:é usado para especular o mais rápido possível, ou seja, assim que as regras de especulação são observadas.
• eager:no momento, isso se comporta de maneira idêntica à configuração immediate, mas no futuro vamos colocá-lo 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 estático muito simples, 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.

A opção moderate é um meio termo, e muitos sites podem se beneficiar da seguinte regra de especulação simples, 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": [{
    "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 da maneira "primeiro a entrar, primeiro a sair" (FIFO, na sigla em inglês). Ao atingir o limite, uma nova especulação fará com que a especulação mais antiga seja cancelada e substituída pela mais recente para economizar memória.

Como as especulações moderate e conservative são acionadas pelos usuários, podemos 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. Portanto, têm um limite maior, já que o navegador não consegue saber quais são necessárias e quando.

Uma especulação que é cancelada ao ser empurrada para fora da fila FIFO pode ser acionada novamente, por exemplo, passando o mouse sobre esse link novamente, o que resultará na nova especulação do URL. Nesse caso, a especulação anterior provavelmente fará com que o navegador armazene em cache alguns recursos no cache HTTP para esse URL, portanto, repetir a especulação deverá reduzir muito a rede e, portanto, os custos de tempo.

Os limites 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 ansiedade criará capacidade ao cancelar essas especulações removidas. Esses URLs também podem ser especulados novamente caso sejam incluídos em um novo script de URL e o limite não tenha sido atingido.

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

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

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

Opcional source

O Chrome 122 torna a chave source opcional, porque isso pode ser inferido pela presença das chaves url ou where. Essas duas regras de especulação são, portanto, 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 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"

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.

Melhor reutilização do cache

Fizemos uma série de melhorias no armazenamento em cache no Chrome para que a pré-busca (ou 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 essa especulação não seja usada.

Isso também torna a reespeculação (por exemplo, para regras de documentos com uma configuração de eagerness moderate) consideravelmente mais barata, já que o Chrome vai usar o cache HTTP para recursos armazenáveis 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 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 e, portanto, permite que um navegador reutilize versões previamente armazenadas em cache de um documento que diferem apenas por esses parâmetros. Observação: no momento, isso só é compatível com o Chrome e com navegadores baseados no Chromium 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.

Demonstração

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

Abra o DevTools e clique no painel Application. Depois, na seção Serviços em segundo plano, clique em Carregamentos especulativos e depois no painel Especulações. Em seguida, classifique pela coluna Status.

Ao passar o cursor sobre as frutas, você vê as páginas de pré-renderização. Clicar neles mostra um tempo de LCP muito mais rápido do que uma das receitas, que não são pré-renderizadas. Essa demonstração também é explicada no vídeo a seguir:

Confira também a postagem anterior do blog sobre regras de especulação de depuração para mais informações sobre como usar o DevTools 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 ao injetar as regras em um elemento <script type="speculationrules">, o suporte da plataforma pode fazer isso com um clique. Estamos trabalhando com várias plataformas e parceiros para facilitar a implementação de regras de especulação.

Também estamos trabalhando para padronizar a API por meio do Web Incubator Community Group (WICG) para permitir que outros navegadores também implementem essa API.

WordPress

A equipe do WordPress Core Performance (incluindo os desenvolvedores do Google) criou um plug-in de regras de especulação. Esse plug-in permite adicionar, com um clique, regras de documentos compatíveis com qualquer site do WordPress. Também é possível instalar esse plug-in usando o WordPress Performance Lab, que pode ser instalado porque ajuda a ficar por dentro dos plug-ins de desempenho da equipe.

Dois grupos de configurações estão 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, há algum tempo, já vem experimentando ativamente a API Speculation Rules. A Akamai publicou uma documentação sobre como os clientes podem ativar essa API nas configurações da CDN. Eles também já compartilharam os resultados impressionantes possíveis com essa nova API.

NitroPack

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

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

Astro

A 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 usassem o Astro para ativar esse recurso com facilidade, ao mesmo tempo que recuavam a uma pré-busca padrão para navegadores que não são compatíveis com a 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 e empolgante recurso de desempenho para sites, com menos risco de desperdiçar recursos com especulações não utilizadas. É incrível ver que as plataformas já usam essa API. Esperamos que ela seja mais adotada em 2024 e, consequentemente, uma melhor performance para os usuários finais.

Além dos ganhos de desempenho que a API Speculation Rules oferece, também estamos animados para ver as novas oportunidades que ela criará. View Transitions é uma nova API que permite que os desenvolvedores especifiquem transições entre navegações com mais facilidade. No momento, essa opção está disponível para aplicativos de página única (SPAs), mas a versão de várias páginas está em andamento e está disponível atrás de uma sinalização no Chrome. A pré-renderização é um complemento natural desse recurso para garantir que não haja atraso, o que, de outra forma, impediria a melhoria da experiência do usuário oferecida pela transição. Já já vimos alguns sites testando essa combinação.

Esperamos que a API Speculation Rules seja ainda mais adotada ao longo de 2024 e vamos atualizar você sobre qualquer outra melhoria que fizermos na API.

Agradecimentos

Miniatura de Robbie Down no Unsplash (link em inglês)