Páginas de carregamento instantâneo com Speculation Rules
Aprenda como melhorar os Core Web Vitals fazendo com que as páginas carreguem instantaneamente com a nova API speculation rules
Melhore instantaneamente os Core Web Vitals com a 'Speculation Rules API'
Já se perguntou por que algumas páginas parecem carregar instantaneamente? Isso provavelmente acontece porque essa página implementou Speculation Rules!
A Speculation Rules API melhora a velocidade de carregamentos futuros de páginas em aplicativos de várias páginas (MPAs) por meio de prefetch ou até mesmo prerender. Os desenvolvedores podem configurar como as speculation rules sugerem ao navegador para fazer o prefetch ou prerender de documentos para carregamentos de página mais rápidos (ou instantâneos). As speculation rules substituem técnicas mais antigas como `<link rel="prefetch">` para prefetching de recursos ou o recurso obsoleto exclusivo do Chrome `<link rel="prerender">`.
As speculation rules funcionam em nível de documento, tornando-as adequadas para MPAs que envolvem navegações de página inteira. Aplicativos de página única (SPAs) que usam principalmente chamadas de API ou atualizações parciais de conteúdo não se beneficiariam tanto dessa API para suas mudanças de rota internas. No entanto, as Speculation Rules ainda podem beneficiar as SPAs ao fazer o prerender do estado inicial do aplicativo a partir de uma landing page, potencialmente compensando o tempo de carregamento inicial.
QuickStart de Speculation rules
Já sabe o que são as speculation rules? Incrível! Aqui estão alguns trechos prontos para você começar imediatamente. Basta escolher o trecho certo para você e colocá-lo no <head> da sua página (sinta-se à vontade para alterar preload para prefetch e ou a eagerness)!
<!--
WordPress speculation rules by corewebvitals.io
prefetches all internal links
skips links that match wp-login, wp-admin, wp content
skips links that have the nofollow attribute
skips links that have a questy string for example: /search->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"and": [{ "href_matches": "\/*"},{ "not": { "href_matches": [ "\/wp-login.php", "\/wp-admin\/*", "\/*\\?*", "\/wp-content\/*", ] }
},{ "not": { "selector_matches": "a[rel~=\"nofollow\"]" }
}]
},
"eagerness": "moderate"
}]
}
</script> <!-- Data-preload triggered speculation rules by corewebvitals.io -->
<script type="speculationrules">
{
"prefetch": [{
"source": "document",
"where": {
"selector_matches": "a[data-preload]"
},
"eagerness": "moderate"
}]
}
</script> Dica: se você precisa construir rapidamente suas próprias speculation rules, por que não experimenta o gerador de speculation rules
Benefícios das Speculation Rules
Experiência do usuário aprimorada (UX): Ao prever e pré-carregar conteúdo, as Speculation Rules garantem carregamentos de página quase instantâneos, fazendo com que a navegação pareça contínua para os usuários. Isso rivaliza com o desempenho de aplicativos de página única, mesmo para sites tradicionais de várias páginas, sem a complexidade e a dependência de JavaScript. Tempos de carregamento mais rápidos significam uma melhor experiência de navegação, provavelmente aumentando o engajamento do usuário e reduzindo as taxas de rejeição.
Vantagens de SEO: Como a velocidade da página melhorada é um fator direto de ranqueamento e um melhor Time to First Byte resultará em um melhor Largest Contentful Paint, a implementação de speculation rules certamente melhorará os Core Web Vitals e dará a você aquele bônus de pagespeed.
Complexidade reduzida: Carregamentos de página quase instantâneos costumavam ser possíveis usando um SPA ou escrevendo lógica de prefetch personalizada para MPAs.
Para muitos casos de uso, a desvantagem de um SPA é o tempo de inicialização, que pode ser considerável, já que dependem fortemente de JavaScript e a complexidade aumentada se compara a um MPA. As speculation rules não têm esse problema. Isso torna o carregamento rápido alcançável para uma gama mais ampla de sites, especialmente os focados em conteúdo.
A API também simplifica o processo de decidir quais páginas devem sofrer prerender delegando grande parte da lógica ao navegador. Esta é uma grande melhoria em relação aos métodos anteriores que dependiam do JavaScript para fazer essas verificações e injetar páginas para preload. Os navegadores podem considerar nativamente o contexto do usuário, como pouca memória em dispositivos móveis ou modo de economia de bateria, ao decidir se devem fazer o prerender. Essa adaptação dinâmica ajuda a conservar os recursos do usuário e garante uma experiência mais suave mesmo sob restrições.
Outros benefícios: O cabeçalho HTTP Speculation-Rules permite uma implantação mais fácil via Content Delivery Networks (CDNs), eliminando a necessidade de modificar o conteúdo do documento diretamente. O Controle Granular com Regras de Documento permite que os desenvolvedores definam condições precisas para prefetching ou prerendering com base em padrões de URL ou seletores CSS. Isso reduz a especificação manual de URL e permite conjuntos de speculation rules em todo o site. A configuração de "eagerness" fornece controle refinado sobre quando a especulação ocorre, equilibrando a velocidade de pré-carregamento com o consumo de recursos. Isso ajuda a reduzir o pré-carregamento desnecessário e evita o desperdício de recursos.
Mecânica das Speculation Rules
As speculation rules são definidas usando uma estrutura JSON e podem ser implementadas de duas maneiras:
- Script Inline: Inclua o JSON dentro de uma tag `<script type="speculationrules">` no `<head>` ou no `<body>` do documento HTML principal.
- Cabeçalho HTTP: Entregue as regras usando o cabeçalho HTTP `Speculation-Rules` na resposta do documento. Esse cabeçalho aponta para um arquivo JSON que contém as regras, facilitando implantações CDN mais fáceis sem modificar o conteúdo HTML diretamente.
A estrutura JSON usa os arrays "prefetch" e "prerender" para conter regras para cada tipo de carregamento especulativo. Cada regra pode usar diferentes fontes: seja uma lista de URLs ou regras de documento
- urls (uma lista de URLs) Um array de URLs para prefetch ou prerender.
- where (regras de documento) Um objeto que usa condições para determinar quais links na página devem sofrer prefetch ou prerender.
Cada regra é definida como um objeto que inclui propriedades como:
- requires Um array de strings para definir restrições nas especulações. Atualmente, a única string válida é "anonymous-client-ip-when-cross-origin", indicando que um prefetch de origem cruzada deve anonimizar o endereço IP do cliente.
- target_hint Uma string fornecendo uma dica sobre o nome do destino navegável, permitindo que o agente do usuário otimize o processo de carregamento. Não tem implicações normativas além de ser uma dica.
- referrer_policy Uma política de referenciador a ser aplicada às URLs em prefetch ou prerender.
- relative_to (Apenas para fonte "list") Especifica se as URLs fornecidas no array "urls" são relativas à URL base do documento ("document") ou à localização do arquivo JSON das speculation rules ("ruleset").
- eagerness Controla o quão agressivamente o navegador deve fazer o prefetch ou prerender. As configurações disponíveis são "immediate", "eager", "moderate" e "conservative", cada uma com gatilhos diferentes.
- expects_no_vary_search Uma string usada para fornecer uma dica de variância de pesquisa de URL, permitindo que os desenvolvedores sinalizem se a URL especulada deve ter uma resposta diferente com base nos parâmetros de pesquisa. .
Por fim, cada regra tem uma configuração de eagerness que permite definir quando as especulações devem ser executadas, separando quando especular de quais URLs realizar especulações. A configuração de eagerness está disponível para regras de fonte de lista e de documento e tem quatro configurações: immediate, eager, moderate, e conservative.
- immediate: Isso é usado para especular o mais rápido possível, assim que as speculation rules forem observadas.
- eager: Atualmente, isso se comporta de forma idêntica à configuração immediate, mas no futuro, será colocado em algum lugar entre immediate e moderate.
- moderate: Isso executa especulações se você passar o mouse sobre um link por 200 milissegundos (ou no evento pointerdown, se for antes, e em dispositivos móveis onde não há evento de hover).
- conservative: Isso especula em ponteiro ou toque para baixo (pointer ou touch down).
Prefetch ou Prerender
A Speculation Rules API suporta duas formas principais de carregamento especulativo: prefetching e prerendering. Embora ambas as técnicas possam resultar em carregamentos de página mais rápidos, elas diferem em sua complexidade e consumo de recursos.
- Prefetching, é a 'forma mais leve' de carregamento especulativo. Ele baixa e armazena em cache o HTML da URL de destino sem renderizar a página ou seus sub-recursos. Essa abordagem melhora principalmente o Time To First Byte. Um Time to First Byte melhorado levará a melhores métricas de pintura, como o Largest Contentful Paint e o First Contentful Paint.
- Prerendering faz muito mais do que apenas baixar o HTML. Ele baixa o HTML, todos os sub-recursos e renderiza a página inteira em uma aba oculta e invisível. Ao navegar para esta página, isso resulta em uma exibição quase instantânea. Esta técnica melhora o Largest Contentful Paint de mais maneiras do que apenas melhorando o Time to First Byte, ela também baixa e renderiza o elemento LCP. O Prerendering também pode eliminar o Cumulative Layout Shift porque as dimensões dos recursos já são conhecidas após o prerender
Então, o que é melhor? Prerendering ou Prefetching? Isso depende da página e do 'visitante médio'. Embora o prerendering possa ser mais rápido, por design ele também usa muito mais recursos, tanto no cliente quanto no servidor. A escolha por prerendering ou prefetching depende de:
- Capacidades do dispositivo do usuário: Prerendering pode não ser a melhor escolha se uma alta porcentagem de visitantes acessa em dispositivos com memória limitada
- Especificidade da regra de prerender ou prefetch. 'Alguns links têm mais probabilidade de serem clicados e algumas páginas têm mais probabilidade de converter'. Essas páginas são candidatas perfeitas para uma regra de prerender. Outras páginas podem ser mais adequadas para prefetch.
CoreWebVitals.io gostaria de alertar contra o prerendering excessivo devido às suas demandas de recursos, particularmente em dispositivos móveis ou conexões mais lentas. Os potenciais benefícios do prerendering devem ser pesados em relação ao risco de degradação do desempenho e desperdício de recursos.
Definindo a 'Eagerness' certa - o ato de equilíbrio
Qual configuração de eagerness usar depende do seu site. Para um site estático muito simples, especular com mais eagerness pode ter pouco custo e ser benéfico para os usuários. Sites com arquiteturas mais complexas e cargas de página mais pesadas podem preferir reduzir o desperdício especulando com menos frequência até que você obtenha um sinal de intenção mais positivo dos usuários para limitar o desperdício.
A configuração de eagerness na Speculation Rules API influencia quando um navegador deve fazer o prefetch ou prerender de conteúdo com base na navegação prevista do usuário. Essa configuração oferece um compromisso entre maximizar os benefícios do pré-carregamento e minimizar o desperdício de recursos.
A eagerness padrão para regras de lista é immediate. As opções moderate e conservative podem ser usadas para limitar regras de lista a URLs com os quais um usuário interage para uma lista específica. Em muitos casos, regras de documento com uma condição where apropriada podem ser mais adequadas.
A eagerness padrão para regras de documento é conservative. Como um documento pode consistir em muitas URLs, o uso de immediate ou eager para regras de documento deve ser usado com cautela.
A escolha da eagerness depende da estrutura do site, dos padrões de comportamento do usuário e da avaliação do desenvolvedor sobre o potencial consumo de recursos versus os benefícios da experiência do usuário. Por exemplo, um site estático simples pode se beneficiar de uma configuração "eager", levando a tempos de carregamento mais rápidos. Por outro lado, sites com arquiteturas complexas e cargas de página exigentes podem optar por uma abordagem "moderate" ou "conservative" menos agressiva para limitar o uso de recursos até que uma intenção de usuário mais clara seja detectada.
Ao configurar a eagerness, os desenvolvedores devem levar em consideração a experiência do usuário, os custos de recursos e as limitações do navegador. A especulação excessiva pode sobrecarregar a largura de banda, a memória e a CPU do usuário, possivelmente degradando o desempenho, especialmente em redes ou dispositivos restritos. O Chrome impõe limites em páginas em prefetch e prerender simultâneas para mitigar o uso excessivo. Além disso, fatores como modos de Economia de Dados (Data Saver) configurados pelo usuário, condições de bateria fraca ou extensões de navegador podem substituir as speculation rules, priorizando a conservação de recursos.
Verificar e depurar speculation rules
Para verificar quaisquer speculation rules em uma página, abra o Chrome DevTools, vá para o painel Application, e navegue até Background Services > Speculative Loads > Speculations. (abra o painel Speculations antes de carregar a página que você deseja depurar) Este painel fornece informações sobre:
- O número de especulações bem-sucedidas.
- URLs individuais sendo feitas em prerender ou prefetch.
- O status de cada especulação.
A guia Network no painel Performance exibe a atividade de rede relacionada a recursos prerendered sem precisar mudar o contexto do DevTools. Além disso, você pode mudar o contexto do DevTools para uma página prerendered para inspecioná-la como uma página normal.
Monitoramento e Análise de Speculation Rules
- Real User Monitoring (RUM): Utilize ferramentas RUM para medir a experiência real do usuário. Observe métricas como Largest Contentful Paint (LCP) para avaliar o impacto das speculation rules nos tempos de carregamento da página. Procure melhorias no LCP para páginas prerendered em comparação com páginas não prerendered.
- Testes A/B: Realize testes A/B para comparar diferentes configurações de speculation rules e identificar a configuração ideal para seu site e base de usuários específicos.
Considerações - a parte ruim
Consumo de Recursos: O uso excessivo de especulação pode impactar negativamente a largura de banda, a memória e o uso da CPU.
Compatibilidade do Navegador: Nem todos os navegadores suportam totalmente a Speculation Rules API, portanto, verifique a compatibilidade do navegador antes da implementação.
Privacidade: Os desenvolvedores devem estar atentos a como as speculation rules podem revelar os padrões de navegação do usuário e implementar medidas de privacidade apropriadas.
A Speculation Rules API oferece uma abordagem poderosa para aprimorar o desempenho e a experiência do usuário de aplicativos web. Ao compreender sua mecânica, benefícios e considerações, os desenvolvedores podem aproveitar essa API para criar sites mais rápidos e envolventes.
Código WordPress de Speculation Rules
A equipe de WordPress Core Performance criou um plugin de Speculation Rules que torna a adição de suporte a regras de documento em qualquer site WordPress uma questão de um clique. O plugin oferece dois grupos de configurações:
- Modo de Especulação (Speculation Mode): Escolha entre prefetch e prerender. O Prerendering resultará em tempos de carregamento mais rápidos do que o prefetching. No entanto, o prefetching pode ser uma escolha mais segura para conteúdo interativo.
- Eagerness: Escolha entre conservative (normalmente ao clicar), moderate (normalmente ao passar o mouse), ou eager (na menor sugestão). A configuração eagerness determina a rapidez com que os carregamentos especulativos são acionados.
