Melhorias na API Speculation Rules

Barry Pollard

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

Essas mudanças tornam a pré-busca e a pré-renderização de páginas consideravelmente mais fáceis de implantar e menos desperdício, e esperamos que elas incentivem uma maior adoção.

Outros recursos

A primeira é uma explicação das novas adições que adicionamos à 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

Antes, 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, em que novos scripts de regras de especulação podiam ser adicionados e scripts antigos removidos para descartar essas especulações. Observe que atualizar a lista urls de um script de regras de especulação existente não aciona uma mudança nas especulações. No entanto, ainda deixava a escolha dos 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 continuam sendo uma opção para casos de uso mais simples, em que a próxima navegação vem de um pequeno conjunto de opções óbvias, ou mais avançadas, em que a lista de URLs é calculada dinamicamente com base na heurística que o proprietário do site quer usar e, em seguida, é inserida na página.

Como alternativa, oferecemos uma nova opção para a descoberta automática de links usando as regras de documentos. Isso funciona extraindo URLs do próprio documento com base em uma condição where. Isso pode ser feito com base 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>

Assim, é possível usar um único conjunto de regras de especulação em todo o site, em vez de regras específicas por página. Isso facilita a implantação dessas regras 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, introduzimos uma configuração eagerness.

Ansiedade

Com qualquer tipo de especulação, há uma compensação entre precisão e recall e tempo de lead. Pré-renderizar todos os links no carregamento da página significa que você provavelmente vai pré-renderizar um link em que um usuário clica (supondo que ele clique em um link do mesmo site na página) e com o máximo de tempo de lead possível, mas com um desperdício potencialmente enorme de largura de banda.

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

A configuração eagerness permite definir quando as especulações devem ser executadas, separando quando para especular de quais URLs devem ser feitas. A configuração eagerness está disponível para as regras de origem list e document e tem quatro configurações, para as quais 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 forem observadas.
• eager:atualmente, isso se comporta de maneira idêntica à configuração da immediate, mas, no futuro, queremos colocar isso em algum lugar entre immediate e moderate.
• moderate:faz especulações quando você passa o cursor sobre um link por 200 milissegundos (ou no evento pointerdown, se isso acontecer antes, e em dispositivos móveis, onde não há um evento hover).
• conservative:especifica o ponteiro ou o toque para baixo.

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

O eagerness padrão para regras document é conservative. Dado que um documento pode conter muitos URLs, o uso de immediate ou eager para regras de document deve ser usado com cuidado. Consulte também a seção Limites do Chrome a seguir.

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

A opção moderate é um meio termo, e muitos sites podem se beneficiar da seguinte regra de especulação simples, que pré-renderiza todos os links ao passar o cursor ou ao ponteiro para baixo 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 maneira First In, First Out (FIFO, na sigla em inglês). Depois de atingir o limite, uma nova especulação fará com que a especulação mais antiga seja cancelada e substituída pela mais recente para conservar memória.

O fato de que as especulações moderate e conservative são 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 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 do FIFO pode ser acionada novamente, por exemplo, passando o cursor mais uma vez sobre o link, o que resultará em uma nova especulação do URL. Nesse caso, a especulação anterior provavelmente terá feito com que o navegador armazene em cache alguns recursos no Cache HTTP desse URL, portanto, repetir a especulação deve ter uma rede muito menor 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 que usa esses níveis de ansiedade vai criar capacidade ao cancelar essas especulações removidas. Esses URLs também poderão ser especulados novamente se forem incluídos em um novo script de URL e o limite não tiver sido atingido.

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

• Save-Data.
• Economia de energia.
• Restrições de memória.
• Quando a opção "Páginas pré-carregadas" estiver desativada, o que também é explicitamente desativado 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 isso seria prejudicial para os usuários.

source opcional

O Chrome 122 torna a chave source opcional, já que ela pode ser inferida com base na 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 fornecidas usando um cabeçalho HTTP Speculation-Rules, em vez de incluí-las diretamente no HTML do documento. Isso facilita a implantação por CDNs sem a necessidade de alterar o conteúdo dos documentos.

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

Speculation-Rules: "/speculationrules.json"

Esse recurso precisa usar o tipo MIME correto e, se for um recurso de origem cruzada, passar em uma verificação de CORS.

Content-Type: application/speculationrules+json
Access-Control-Allow-Origin: *

Se você quiser usar URLs relativos, inclua a chave "relative_to": "document" nas regras de especulação. Caso contrário, os URLs relativos serão relativos ao URL do arquivo JSON das regras de especulação. Isso pode ser particularmente útil se você precisar selecionar alguns ou todos os links de mesma origem.

Melhor reutilização de cache

Fizemos várias melhorias no armazenamento em cache do 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 essa especulação não seja usada.

Isso também torna a nova especulação (por exemplo, para regras de documentos com uma configuração de adiantamento moderate) consideravelmente mais barata, já que o Chrome usará o cache HTTP para recursos armazenáveis em cache.

Também aceitamos a 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 realmente exibida pelo servidor e usados apenas pelo JavaScript do lado do cliente.

Por exemplo, os parâmetros de UTM (monitor de tráfego do Urchin) são usados pelo Google Analytics para a medição de campanhas, mas geralmente não resultam na exibição de páginas diferentes do servidor. Isso significa que page1.html?utm_content=123 e page1.html?utm_content=456 fornecerão a mesma página do servidor, de modo que a mesma página poderá ser reutilizada do cache.

Da mesma forma, os aplicativos podem usar outros parâmetros de URL que são processados apenas no lado do cliente.

A proposta No-Vary-Search permite que um servidor especifique parâmetros que não resultem em diferença em relação ao recurso enviado. Isso permite que o navegador reutilize versões armazenadas em cache de um documento que diferem apenas nesses parâmetros. Observação: no momento, isso só é compatível com o Chrome (e 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 precisa ser retornado. Isso pode ajudar a evitar downloads desnecessários.

<script type="speculationrules">
{
  "prefetch": [{
    "urls": ["/products*"],
    "expects_no_vary_search": "params=(\"id\")"
  }]
}
</script>

<a href="/products?id=123">Product 123</a>
<a href="/products?id=124">Product 124</a>

Neste exemplo, o HTML da página inicial /products é o mesmo para os IDs do produto 123 e 124. No entanto, o conteúdo da página será diferente com base na renderização do lado do cliente usando JavaScript para buscar dados do produto usando o parâmetro de pesquisa id. Portanto, fazemos a pré-busca desse URL, e ele retornará um cabeçalho HTTP No-Vary-Search mostrando que a página pode ser usada para qualquer parâmetro de pesquisa id.

No entanto, se o usuário clicar em qualquer um dos links antes da conclusão da pré-busca, talvez o navegador não tenha recebido a página /products. Nesse caso, o navegador não saberá se conterá o cabeçalho HTTP No-Vary-Search. O navegador pode escolher se quer buscar o link novamente ou aguardar a conclusão da pré-busca para ver se contém um cabeçalho HTTP No-Vary-Search. A configuração expects_no_vary_search permite que o navegador saiba que a resposta da página precisa conter um cabeçalho HTTP No-Vary-Search e aguarde a conclusão dessa pré-busca.

Demonstração

Criamos uma demonstração em https://speculative-rules.glitch.me/common-fruits.html para ver as regras de documentos com a configuração de ansiedade moderate em ação:

Abra o DevTools e clique no painel Application. Na seção Serviços em segundo plano, clique em Carregamentos especulativos, acesse o painel Especulações e classifique pela coluna Status.

Ao passar o cursor sobre as frutas, você verá as páginas sendo pré-renderizadas. Clicar neles mostrará 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 (link em inglês) para saber mais 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 injetando-as em um elemento <script type="speculationrules">, o suporte da plataforma pode fazer com que isso aconteça com apenas um clique. Estamos trabalhando com várias plataformas e parceiros para facilitar a implementação de regras de especulação.

Também estamos trabalhando duro para padronizar a API por meio do Web Incubator Community Group (WICG) para permitir que outros navegadores também implementem essa incrível API, se quiserem.

WordPress

A equipe de desempenho principal do WordPress (incluindo desenvolvedores do Google) criou um plug-in de regras de especulação. Com esse plug-in, é possível adicionar o suporte a regras de documentos a qualquer site WordPress com apenas um clique. A instalação também está disponível pelo plug-in do WordPress Performance Lab, que você também deve instalar, porque ele manterá você atualizado sobre os plug-ins de desempenho relacionados da equipe.

Dois grupos de configurações estão disponíveis: Modo de especulação e Atenção:

Para configurações mais complicadas, por exemplo, para impedir que determinados URLs sejam pré-buscados ou pré-renderizados, leia a documentação.

Akamai

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

NitroPack

A NitroPack é uma solução de otimização de desempenho que usa uma 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 saber mais. Essa solução inovadora mostra que as regras de lista mais antigas ainda oferecem muito mais quando combinadas com insights específicos dos sites.

A equipe do Chrome também trabalhou com a NitroPack em um webinar sobre a API Speculation Rules para quem busca mais informações, incluindo uma boa discussão sobre as considerações necessárias entre especular com antecedência e frequência, bem como tardias 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, mas voltem para uma pré-busca padrão para navegadores que não oferecem suporte a essa API. 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 incrível para sites, com menos risco de desperdiçar recursos com especulações não utilizadas. É empolgante ver as plataformas já usarem essa API. Esperamos ver uma adoção maior dessa API em 2024 e, como resultado, uma melhoria na 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 isso criará. View Transitions é uma nova API que permite que os desenvolvedores especifiquem transições entre as 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 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 atrasos, o que impediria a melhoria da experiência do usuário que a transição pretende fornecer. Já já vimos sites testando essa combinação.

Esperamos que a API Speculation Rules continue sendo adotada em 2024 e vamos enviar atualizações sobre melhorias.

Agradecimentos

Miniatura de Robbie Down no Unsplash