Saiba por que as ferramentas que monitoram as métricas das Core Web Vitals talvez reportem números diferentes e como interpretar essas diferenças.
O Google oferece várias ferramentas para ajudar os proprietários de sites a monitorar as pontuações das Core Web Vitals. Essas ferramentas se enquadram em duas categorias principais:
- Ferramentas que informam dados de laboratório: dados coletados em um ambiente controlado com configurações de dispositivo e rede predefinidas.
- Ferramentas que informam dados de campo, coletados dos usuários reais que visitam seu site.
O problema é que, às vezes, os dados informados pelas ferramentas de laboratório podem ser bastante diferentes dos dados informados pelas ferramentas de campo. Seus dados de laboratório podem indicar que o site tem um bom desempenho, mas os dados de campo sugerem que ele precisa de melhorias. Como alternativa, os dados de campo podem dizer que todas as suas páginas são boas, mas os dados de laboratório podem informar uma pontuação muito baixa.
O exemplo real a seguir de um relatório do PageSpeed Insights do web.dev mostra que, em alguns casos, os dados de laboratório e de campo podem ser diferentes em todas as métricas das Core Web Vitals:
As diferenças entre as ferramentas são uma fonte de confusão compreensível para os desenvolvedores. Esta postagem explica os principais motivos dessas diferenças, com exemplos específicos que abrangem cada uma das métricas Core Web Vitals, e o que fazer quando você encontrar diferenças nas suas páginas.
Dados de laboratório e de campo
Para entender por que as ferramentas de laboratório e de campo podem informar valores diferentes, mesmo para a mesma página da Web, é necessário entender a diferença entre os dados de laboratório e de campo.
Dados do laboratório
Os dados do laboratório são determinados pelo carregamento de uma página da Web em um ambiente controlado com um conjunto predefinido de condições de rede e dispositivo. Essas condições são conhecidas como ambiente de laboratório, às vezes também chamado de ambiente sintético.
As ferramentas do Chrome que informam dados de laboratório geralmente executam o Lighthouse.
O objetivo de um teste de laboratório é controlar o máximo de fatores possível para que os resultados sejam (tanto quanto possível) consistentes e reproduzíveis de uma execução para outra.
Dados de campo
Os dados de campo são determinados monitorando todos os usuários que visitam uma página e medindo um determinado conjunto de métricas de performance para cada uma das experiências individuais desses usuários. Como os dados de campo são baseados em visitas de usuários reais, eles refletem os dispositivos, as condições de rede e as localizações geográficas dos usuários.
Os dados de campo também são conhecidos como dados de Monitoramento de usuário real (RUM). Os dois termos são intercambiáveis.
As ferramentas do Chrome que informam dados de campo geralmente recebem esses dados do Relatório de experiência do usuário do Chrome (CrUX). Também é comum (e recomendado) que os proprietários de sites coletem dados de campo por conta própria, porque isso pode fornecer insights mais úteis do que apenas usar o CrUX.
O mais importante a se entender sobre os dados de campo é que eles não são apenas um número, mas uma distribuição de números. Ou seja, para algumas pessoas que visitam seu site, ele pode carregar muito rápido, enquanto para outras, pode carregar muito lentamente. Os dados de campo do seu site são o conjunto completo de todos os dados de performance coletados dos usuários.
Por exemplo, os relatórios CrUX mostram uma distribuição de métricas de desempenho de usuários reais do Chrome em um período de 28 dias. Se você analisar quase qualquer relatório do CrUX, vai notar que alguns usuários que visitam um site podem ter uma experiência muito boa, enquanto outros podem ter uma experiência muito ruim.
Se uma ferramenta informar um único número para uma determinada métrica, ela geralmente representará um ponto específico na distribuição. As ferramentas que informam as pontuações de campo das Core Web Vitals fazem isso usando a 75ª percentila.
Analisando o LCP dos dados de campo na captura de tela acima, é possível ver uma distribuição em que:
- 88% das visitas tiveram um LCP de 2,5 segundos ou menos (bom).
- 8% das visitas tiveram um LCP entre 2,5 e 4 segundos (precisa de melhoria).
- 4% das visitas tiveram um LCP maior que 4 segundos (ruim).
No percentil 75, o LCP foi de 1,8 segundo:
Os dados do laboratório da mesma página mostram um valor de LCP de 3,0 segundos. Embora esse valor seja maior que os 1,8 segundos mostrados nos dados de campo, ele ainda é um valor de LCP válido para essa página.É um dos muitos valores que compõem a distribuição completa das experiências de carregamento.
Por que os dados de laboratório e de campo são diferentes
Como explicado na seção acima, os dados de laboratório e de campo medem coisas muito diferentes.
Os dados de campo incluem uma grande variedade de condições de rede e dispositivo, além de diversos tipos de comportamento do usuário. Ele também inclui outros fatores que afetam a experiência do usuário, como otimizações do navegador, como o cache de ida/volta (bfcache) ou otimizações de plataforma, como o cache do AMP.
Em contraste, os dados de laboratório limitam intencionalmente o número de variáveis envolvidas. Um teste de laboratório consiste em:
- Um único dispositivo…
- conectado a uma única rede…
- em um único local geográfico.
Os detalhes de qualquer teste de laboratório podem ou não representar com precisão o 75º percentil dos dados de campo de uma determinada página ou site.
O ambiente controlado do laboratório é útil para depurar problemas ou testar recursos antes da implantação na produção. No entanto, ao controlar esses fatores, você não representa explicitamente a variação que aparece no mundo real em todos os tipos de redes, recursos de dispositivo ou locais geográficos. Você geralmente não captura o impacto de desempenho do comportamento do usuário real, como rolagem, seleção de texto ou toque em elementos na página.
Além da possível desconexão entre as condições do laboratório e as condições da maioria dos usuários reais, há também uma série de diferenças mais sutis que são importantes para entender melhor os dados de laboratório e de campo, bem como quaisquer diferenças que você encontrar.
As próximas seções detalham os motivos mais comuns para as diferenças entre os dados de laboratório e de campo para cada uma das métricas do Core Web Vitals:
LCP
Elementos diferentes da LCP
O elemento LCP identificado em um teste de laboratório pode não ser o mesmo que os usuários veem ao acessar sua página.
Se você executar um relatório do Lighthouse para uma determinada página, ele vai retornar o mesmo elemento LCP sempre. No entanto, se você analisar os dados de campo da mesma página, geralmente vai encontrar vários elementos de LCP diferentes, que dependem de várias circunstâncias específicas de cada visita à página.
Por exemplo, os seguintes fatores podem contribuir para que um elemento LCP diferente seja determinado para a mesma página:
- Diferentes tamanhos de tela de dispositivos resultam em diferentes elementos visíveis na janela de visualização.
- Se o usuário estiver conectado ou se o conteúdo personalizado estiver sendo mostrado de alguma forma, o elemento LCP poderá ser muito diferente de um usuário para outro.
- Assim como no ponto anterior, se um teste A/B estiver sendo executado na página, ele poderá resultar na exibição de elementos muito diferentes.
- O conjunto de fontes instalado no sistema do usuário pode afetar o tamanho do texto na página e, portanto, qual elemento é o da LCP.
- Os testes de laboratório geralmente são executados no URL "base" de uma página, sem parâmetros de consulta ou fragmentos de hash adicionados. Mas, na prática, os usuários geralmente compartilham URLs que contêm um identificador de fragmento ou fragmento de texto. Portanto, o elemento LCP pode ser do meio ou da parte de baixo da página, e não "acima da dobra".
Como a LCP no campo é calculada como o percentil 75 de todas as visitas de usuários a uma página, se uma grande porcentagem desses usuários tiver um elemento de LCP que carregou muito rápido, por exemplo, um parágrafo de texto renderizado com uma fonte do sistema, mesmo que alguns desses usuários tenham uma imagem grande e de carregamento lento como elemento de LCP, isso pode não afetar a pontuação da página se isso acontecer com menos de 25% dos visitantes.
Alternativamente, o oposto pode ser verdadeiro. Um teste de laboratório pode identificar um bloco de texto como o elemento LCP porque ele emula um smartphone Moto G4 com uma janela de visualização relativamente pequena, e a imagem principal da página é renderizada fora da tela. No entanto, seus dados de campo podem incluir principalmente usuários do Pixel XL com telas maiores. Para eles, a imagem principal de carregamento lento é o elemento de LCP.
Efeitos do estado do cache no LCP
Os testes de laboratório geralmente carregam uma página com um cache frio, mas quando usuários reais visitam essa página, é possível que alguns dos recursos dela já estejam armazenados em cache.
Na primeira vez que um usuário carrega uma página, ela pode carregar lentamente, mas se a página tiver o armazenamento em cache configurado corretamente, na próxima vez que o usuário retornar, a página poderá ser carregada imediatamente.
Embora algumas ferramentas de laboratório ofereçam suporte a várias execuções da mesma página (para simular a experiência para visitantes recorrentes), não é possível que uma ferramenta de laboratório saiba qual porcentagem de visitas reais ocorre de usuários novos em comparação com usuários recorrentes.
Sites com configurações de cache bem otimizadas e muitos visitantes recorrentes podem descobrir que o LCP real é muito mais rápido do que indicam os dados do laboratório.
Otimizações de AMP ou trocas assinadas
Os sites criados com AMP ou que usam Signed Exchanges (SXG) podem ser pré-carregados por agregadores de conteúdo, como a Pesquisa Google. Isso pode resultar em uma performance de carregamento muito melhor para os usuários que visitam suas páginas nessas plataformas.
Além do pré-carregamento entre origens, os sites podem pré-carregar conteúdo para páginas subsequentes, o que também pode melhorar a LCP dessas páginas.
As ferramentas do laboratório não simulam os ganhos dessas otimizações. Mesmo que fossem capazes de fazer isso, elas não saberiam qual porcentagem do seu tráfego vem de plataformas como a Pesquisa Google em comparação com outras fontes.
Efeitos do bfcache no LCP
Quando as páginas são restauradas do bfcache, a experiência de carregamento é quase instantânea, e essas experiências são incluídas nos dados de campo.
Os testes de laboratório não consideram o bfcache. Portanto, se as suas páginas forem compatíveis com o bfcache, é provável que os resultados do LCP sejam mais rápidos.
Efeitos da interação do usuário no LCP
A LCP identifica o tempo de renderização da maior imagem ou bloco de texto na janela de visualização, mas esse elemento maior pode mudar à medida que a página é carregada ou se novo conteúdo for adicionado dinamicamente à janela de visualização.
No laboratório, o navegador vai esperar até que a página seja totalmente carregada antes de determinar qual foi o elemento LCP. No campo, o navegador para de monitorar elementos maiores depois que o usuário rola ou interage com a página.
Isso faz sentido (e é necessário) porque os usuários geralmente esperam para interagir com uma página até que ela "apareça" carregada, que é exatamente o que a métrica LCP visa detectar. Também não faz sentido considerar elementos adicionados à viewport depois que um usuário interage, porque esses elementos podem ter sido carregados por causa de algo que o usuário fez.
No entanto, isso implica que os dados de campo de uma página podem informar tempos de LCP mais rápidos, dependendo do comportamento dos usuários nessa página.
INP
A INP exige interação do usuário real
A métrica INP mede a capacidade de resposta de uma página às interações do usuário, no momento em que os usuários realmente escolheram interagir com ela.
A segunda parte dessa frase é fundamental porque os testes de laboratório, mesmo aqueles que oferecem suporte ao comportamento do usuário do script, não conseguem prever com precisão quando os usuários vão interagir com uma página e, portanto, não conseguem medir com precisão o FID.
A TBT não considera o comportamento do usuário
A métrica de laboratório Tempo total de bloqueio (TBT, na sigla em inglês) tem como objetivo ajudar a diagnosticar problemas com a INP porque quantifica o quanto a linha de execução principal é bloqueada durante o carregamento da página.
A ideia é que páginas com muito JavaScript síncrono ou outras tarefas intensivas de renderização têm mais probabilidade de ter uma linha de execução principal bloqueada quando o usuário interage pela primeira vez. No entanto, se os usuários esperarem para interagir com a página até que o JavaScript termine a execução, a INP poderá ser muito baixa.
O momento em que os usuários vão escolher interagir com uma página depende em grande parte de se ela parece interativa ou não, e isso não pode ser medido com a TBT.
O TBT não considera o tempo de espera para tocar
Se um site não for otimizado para visualização em dispositivos móveis, os navegadores adicionarão um atraso de 300 ms após qualquer toque antes de executar os manipuladores de eventos. Isso é necessário para determinar se o usuário está tentando tocar duas vezes para aplicar zoom antes de acionar eventos de mouse ou clique.
Esse atraso é contabilizado para o INP de uma página porque contribui para a latência de entrada real que os usuários enfrentam. No entanto, como esse atraso não é tecnicamente uma tarefa longa, ele não afeta o TBT de uma página. Isso significa que uma página pode ter uma INP ruim, apesar de ter notas de TBT muito boas.
Efeitos do estado do cache e do bfcache no INP
Da mesma forma que o armazenamento em cache adequado pode melhorar a LCP no campo, ele também pode melhorar a INP.
Na vida real, um usuário pode ter o JavaScript de um site já no cache. Assim, o processamento dele pode levar menos tempo e resultar em atrasos menores.
O mesmo vale para páginas restauradas do bfcache. Nesses casos, o JavaScript é restaurado da memória, então pode haver pouco ou nenhum tempo de processamento.
CLS
Efeitos da interação do usuário no CLS
O CLS medido no laboratório considera apenas as mudanças de layout que ocorrem acima da dobra e durante o carregamento, mas esse é apenas um subconjunto do que o CLS realmente mede.
No campo, a CLS considera todas as mudanças de layout inesperadas que ocorrem durante a vida útil da página, incluindo conteúdo que muda conforme o usuário rola a página ou em resposta a solicitações de rede lentas após a interação do usuário.
Por exemplo, é bastante comum que as páginas carreguem imagens ou iframes sem dimensões, o que pode causar mudanças no layout quando um usuário rola para essas seções da página. No entanto, essas mudanças só podem acontecer se o usuário rolar para baixo, o que geralmente não é detectado em um teste de laboratório.
Conteúdo personalizado
O conteúdo personalizado, incluindo anúncios segmentados e testes A/B, afeta quais elementos são carregados em uma página. Isso também afeta a forma como eles são carregados, já que o conteúdo personalizado geralmente é carregado mais tarde e inserido no conteúdo principal de uma página, causando mudanças de layout.
No laboratório, uma página geralmente é carregada sem conteúdo personalizado ou com conteúdo para um "usuário de teste" genérico, que pode ou não acionar as mudanças que os usuários reais estão vendo.
Como os dados de campo incluem as experiências de todos os usuários, a quantidade (e o grau) de mudanças de layout em qualquer página depende muito do conteúdo carregado.
Efeitos do estado do cache e do bfcache no CLS
Duas das causas mais comuns de mudanças de layout durante o carregamento são imagens e iframes sem dimensões (como mencionado acima) e carregamento lento de fontes da Web. Essas duas questões têm mais probabilidade de afetar a experiência na primeira vez que um usuário visita um site, quando o cache está vazio.
Se os recursos de uma página estiverem armazenados em cache ou se a página for restaurada do bfcache, o navegador geralmente poderá renderizar imagens e fontes imediatamente, sem esperar o download. Isso pode resultar em valores de CLS mais baixos no campo do que o que uma ferramenta de laboratório pode informar.
O que fazer quando os resultados são diferentes
Como regra geral, se você tiver dados de campo e de laboratório para uma determinada página, use os dados de campo para priorizar seus esforços. Como os dados de campo representam a experiência dos usuários reais, essa é a maneira mais precisa de entender o que está dificultando a vida dos usuários e o que precisa ser melhorado.
Por outro lado, se os dados de campo mostram boas pontuações em todos os aspectos, mas os dados de laboratório sugerem que ainda há espaço para melhorias, vale a pena entender quais otimizações adicionais podem ser feitas.
Além disso, embora os dados de campo capturem experiências de usuários reais, eles só fazem isso para usuários que conseguem carregar seu site. Os dados de laboratório às vezes podem ajudar a identificar oportunidades para ampliar o alcance do seu site e torná-lo mais acessível para usuários com redes mais lentas ou dispositivos mais simples.
No geral, os dados de laboratório e de campo são partes importantes da medição de desempenho eficaz. Elas têm pontos fortes e limitações, e se você estiver usando apenas um, pode estar perdendo uma oportunidade de melhorar a experiência dos usuários.