Saiba por que as ferramentas que monitoram as Core Web Vitals talvez reportem diferentes números, 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 geram relatórios de dados de laboratório: dados coletados em um ambiente controlado com configurações predefinidas de dispositivo e rede.
- Ferramentas que registram dados de campo: dados coletados de usuários reais que acessam seu site.
O problema é que, às vezes, os dados relatados pelas ferramentas de laboratório podem ser bem diferentes dos dados relatados por ferramentas de campo. Os dados do laboratório podem indicar que o site tem um ótimo desempenho, mas os dados de campo sugerem que ele precisa de melhorias. Como alternativa, os dados de campo podem indicar que todas as páginas estão boas, mas os dados de laboratório podem apresentar uma pontuação muito baixa.
O seguinte exemplo real 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 Core Web Vitals:
As diferenças entre as ferramentas são uma fonte compreensível de confusão para os desenvolvedores. Esta postagem explica os principais motivos dessas diferenças, com exemplos específicos que abrangem cada uma das métricas das Core Web Vitals, e o que fazer quando você encontrar diferenças nas suas páginas.
Dados de laboratório versus dados 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, é preciso entender a diferença entre os dados de laboratório e de campo.
Dados de 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 um 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 maior número possível de fatores, para que os resultados sejam (o máximo possível) consistentes e possam ser reproduzidos a partir da execução.
Dados de campo
Os dados de campo são determinados pelo monitoramento de todos os usuários que acessam uma página e pela medição de um determinado conjunto de métricas de desempenho para cada uma das experiências individuais deles. Como os dados de campo são baseados em visitas de usuários reais, eles refletem os dispositivos reais, as condições de rede e a localização geográfica dos usuários.
Os dados de campo também são conhecidos como dados de monitoramento real do usuário (RUM, na sigla em inglês). Os dois termos são intercambiáveis.
As ferramentas do Chrome que informam dados de campo geralmente recebem esses dados do Chrome User Experience Report (CrUX, na sigla em inglês). Também é comum (e recomendado) que os proprietários de sites coletem os próprios dados de campo porque isso pode fornecer insights mais úteis do que usar apenas o CrUX.
O mais importante a entender sobre dados de campo é que não são apenas um número, é uma distribuição de números. Ou seja, para algumas pessoas que acessam seu site, ele pode carregar muito rapidamente, enquanto para outras pode ser muito lento. Os dados de campo do seu site são o conjunto completo de todos os dados de desempenho coletados dos usuários.
Por exemplo, os relatórios do CrUX mostram uma distribuição das métricas de desempenho de usuários reais do Chrome em um período de 28 dias. Se você analisar quase todos os relatórios do CrUX, vai perceber que alguns usuários que acessam 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 dos campos das Core Web Vitals fazem isso usando o 75o percentil.
Analisando a LCP pelos dados de campo na captura de tela acima, você pode ver uma distribuição em que:
- 88% das visitas tiveram uma LCP de 2,5 segundos ou menos (boa).
- 8% das visitas observaram uma LCP entre 2,5 e 4 segundos (precisa de melhorias).
- 4% das visitas tiveram uma LCP maior do que 4 segundos (ruim).
No 75o percentil, a LCP era de 1,8 segundo:
Os dados do laboratório na mesma página mostram um valor de LCP de 3 segundos. Embora esse valor seja maior que o valor de 1,8 segundo mostrado nos dados de campo, ele ainda é um valor de LCP válido para a página, sendo 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
Conforme explicado na seção acima, os dados de laboratório e de campo medem coisas muito diferentes.
Os dados de campo incluem uma ampla 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 avanço e retorno (bfcache), ou otimizações de plataforma, como o cache de AMP.
Por outro lado, 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...
- são executados a partir de uma única localização geográfica.
As especificações de um determinado teste de laboratório podem ou não representar com precisão o 75o 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 você vê no mundo real em todos os tipos de redes, recursos de dispositivos ou localizações geográficas. Geralmente, também não está capturando o impacto do desempenho do comportamento do usuário real, como rolar, selecionar texto ou tocar em elementos na página.
Além da possível desconexão entre as condições de laboratório e as condições da maioria dos usuários no mundo real, também há várias diferenças mais sutis que são importantes de entender para que os dados de laboratório e campo sejam mais relevantes, assim como as diferenças que você pode encontrar.
As próximas seções entram em detalhes, destacando 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:
- Maior exibição de conteúdo (LCP)
- Latência na primeira entrada (FID, na sigla em inglês)
- Mudança de layout cumulativa (CLS)
LCP
Diferentes elementos da LCP
Talvez o elemento de LCP identificado em um teste de laboratório não seja 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 retornará o mesmo elemento da LCP todas as vezes. 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 circunstâncias específicas para cada visita.
Por exemplo, os seguintes fatores podem contribuir para que um elemento diferente da LCP seja determinado para a mesma página:
- Diferentes tamanhos de tela de dispositivo 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 exibido de alguma maneira, o elemento da LCP poderá ser muito diferente de usuário para usuário.
- Assim como no ponto anterior, se um teste A/B estiver em execução na página, isso poderá resultar na exibição de elementos muito diferentes.
- O conjunto de fontes instaladas no sistema do usuário pode afetar o tamanho do texto na página e, portanto, qual elemento é o elemento da LCP.
- Os testes de laboratório geralmente são executados no URL "base" de uma página, sem a adição de parâmetros de consulta ou fragmentos hash. Mas, no mundo real, os usuários geralmente compartilham URLs que contêm um identificador de fragmento ou um fragmento de texto. Assim, o elemento da LCP pode estar no meio ou na parte de baixo da página, em vez de "acima da dobra".
Como a LCP no campo é calculada como o 75o percentil de todas as visitas de usuários a uma página, se uma grande porcentagem desses usuários tiver um elemento da LCP que é carregado muito rapidamente (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 da LCP, isso poderá não afetar a pontuação da página se isso acontecer com menos de 25%.
Ou o contrário pode ser verdadeiro. Um teste de laboratório pode identificar um bloco de texto como o elemento LCP por estar emulando um smartphone Moto G4, que tem uma janela de visualização relativamente pequena, e a imagem principal da página é inicialmente renderizada fora da tela. No entanto, seus dados de campo podem incluir principalmente usuários do Pixel XL com telas maiores. Portanto, para eles, a imagem principal de carregamento lento é o elemento LCP.
Efeitos do estado do cache na LCP
Os testes de laboratório normalmente carregam uma página com um cache frio, mas quando usuários reais a visitam, é possível que alguns dos recursos já estejam armazenados em cache.
Na primeira vez que um usuário carregar uma página, ela poderá carregar lentamente. No entanto, se a página tiver o armazenamento em cache adequado configurado, a 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 de visitantes recorrentes), uma delas não consegue saber a porcentagem de visitas reais que ocorre de usuários novos e recorrentes.
Sites com configurações de cache otimizadas e muitos visitantes recorrentes podem descobrir que a LCP real é muito mais rápida do que os dados do laboratório indicam.
Otimizações de AMP ou Signed Exchange
Os sites criados com AMP ou que usam trocas assinadas (SXG) podem ser pré-carregados por agregadores de conteúdo, como a Pesquisa Google. Isso pode resultar em uma performance de carregamento significativamente melhor para os usuários que acessam suas páginas nessas plataformas.
Além do pré-carregamento de origem cruzada, os próprios sites podem pré-carregar o conteúdo das próximas páginas, o que também pode melhorar a LCP dessas páginas.
As ferramentas do laboratório não simulam os ganhos dessas otimizações e, mesmo que fizessem, não seria possível saber qual porcentagem do seu tráfego vem de plataformas como a Pesquisa Google em comparação com outras origens.
Efeitos do bfcache na 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 suas páginas forem amigáveis ao bfcache, isso provavelmente resultará em pontuações de LCP mais rápidas relatadas no campo.
Efeitos da interação do usuário na LCP
A LCP identifica o tempo de renderização da maior imagem ou bloco de texto na janela de visualização, mas esse maior elemento pode mudar conforme a página é carregada ou se um novo conteúdo é adicionado dinamicamente à janela.
No laboratório, o navegador aguardará até que a página esteja totalmente carregada antes de determinar qual era o elemento da LCP. Mas, em campo, o navegador interrompe o monitoramento de elementos maiores depois que o usuário rola a página ou interage com ela.
Isso faz sentido (e é necessário) porque os usuários normalmente esperam para interagir com uma página até que ela "apareça" carregada, que é exatamente o que a métrica da LCP pretende detectar. Também não faz sentido considerar elementos adicionados à janela de visualização depois que um usuário interage, porque esses elementos só podem ter sido carregados por causa de algo que o usuário fez.
No entanto, a implicação é que os dados de campo de uma página podem informar tempos de LCP mais rápidos, dependendo de como os usuários se comportam nessa página.
FID
A FID requer interação do usuário real
A métrica de FID mede a capacidade de resposta de uma página em relação às interações do usuário no momento em que as pessoas optam por interagir com ela.
A segunda parte é essencial porque os testes de laboratório, mesmo aqueles que aceitam o comportamento do usuário com scripts, não podem prever com precisão quando os usuários vão optar por interagir com uma página e, portanto, não podem medir a FID com precisão.
O TBT não considera o comportamento do usuário
A métrica do laboratório Tempo total de bloqueio (TBT, na sigla em inglês) ajuda a diagnosticar problemas com FID, porque quantifica quanto a linha de execução principal fica bloqueada durante o carregamento de página.
A ideia é que as páginas com muito JavaScript síncrono ou outras tarefas intensivas de renderização tenham mais chances de ter uma linha de execução principal bloqueada quando o usuário interagir pela primeira vez. No entanto, se os usuários esperarem para interagir com a página até o JavaScript terminar a execução, a FID poderá ser muito baixa.
O momento em que os usuários optam por interagir com uma página depende em grande parte se ela parece interativa ou não, e isso não pode ser medido com TBT.
O TBT não considera o tempo de toque
Se um site não estiver otimizado para visualização em dispositivos móveis, os navegadores adicionarão um atraso de 300 ms após qualquer toque antes de executar manipuladores de eventos. Isso é feito porque é preciso determinar se o usuário está tentando tocar duas vezes para aumentar o zoom antes de disparar eventos de mouse ou de clique.
Esse atraso é contabilizado no FID de uma página porque contribui para a latência real de entrada que os usuários experimentam. Mas, 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 FID ruim, apesar de ter pontuações de TBT muito boas.
Efeitos do estado do cache e bfcache na FID
Da mesma forma que o armazenamento em cache adequado pode melhorar a LCP no campo, ele também pode melhorar a FID.
No mundo real, um usuário pode já ter o JavaScript de um site no cache. Portanto, o processamento 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 na CLS
A CLS medida no laboratório considera apenas as mudanças de layout que ocorrem acima da dobra e durante o carregamento, mas isso é apenas um subconjunto do que a CLS realmente mede.
No campo, a CLS considera todas as mudanças inesperadas de layout que ocorrem durante a vida útil da página, incluindo o conteúdo que muda à medida que o usuário rola a tela ou em resposta a solicitações de rede lentas após a interação do usuário.
Por exemplo, é muito comum páginas carregar imagens ou iframes de forma lenta sem dimensões. Isso pode causar mudanças de layout quando um usuário rola até 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 é capturado 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 da página, causando mudanças de layout.
No laboratório, uma página geralmente é carregada sem conteúdo personalizado ou com conteúdo de um "usuário de teste" genérico, o 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 grau) de mudanças de layout em qualquer página depende muito do conteúdo carregado.
Efeitos do estado do cache e do bfcache na 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 fontes da Web de carregamento lento. Os dois problemas têm maior 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 forem armazenados em cache ou se a página for restaurada do bfcache, o navegador geralmente renderizará imagens e fontes imediatamente, sem esperar o download. Isso pode resultar em valores de CLS mais baixos no campo do que os informados por uma ferramenta de laboratório.
O que fazer quando os resultados forem diferentes
Como regra geral, se você tiver dados de campo e de laboratório para uma determinada página, use dados de campo para priorizar seus esforços. Como os dados de campo representam a experiência dos usuários reais, são a maneira mais precisa de entender as dificuldades dos usuários e o que precisa ser melhorado.
Por outro lado, se os dados de campo mostrarem boas pontuações em geral, mas os dados do laboratório sugerirem que ainda há espaço para melhorias, vale a pena entender quais outras otimizações podem ser feitas.
Além disso, embora os dados de campo capturem experiências do usuário real, eles só fazem isso para usuários que conseguem carregar seu site. Às vezes, os dados do laboratório podem ajudar a identificar oportunidades para expandir o alcance do seu site e torná-lo mais acessível a 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 eficaz de desempenho. Ambos têm pontos fortes e limitações, e se você estiver usando apenas um, poderá estar perdendo uma oportunidade de melhorar a experiência dos usuários.