O que mostra este relatório de Core Web Vitals?
Introduza um domínio ou um URL, escolha telemóvel ou desktop, e o relatório extrai 25 semanas de field data da CrUX History API da Google. Recebe um gráfico semanal para o LCP, o INP e o CLS, mais o TTFB e o FCP. O LCP nunca pode ser mais rápido do que qualquer um deles. Funciona para qualquer site com tráfego suficiente no Chrome, até o de um concorrente.
Abaixo dos gráficos de carregamento, o LCP surge dividido nas suas quatro partes. Mais abaixo encontra o CLS e o INP ao longo do tempo, seguidos dos dispositivos e tipos de navegação. Estes dois últimos, bem como a percentagem de imagem ou texto do LCP, abrangem todos os dispositivos em conjunto, independentemente da opção escolhida.
Como ler os gráficos semanais do CrUX
Uma barra é uma semana. Passe o cursor por cima para ver o p75 dessa semana e a percentagem de carregamentos de página bons, a precisar de melhorias e fracos.
O p75 é o valor pelo qual a Google o avalia: três em cada quatro carregamentos de página foram pelo menos tão bons.
- O LCP é bom até 2,5 s e fraco acima de 4 s
- O INP é bom até 200 ms e fraco acima de 500 ms
- O CLS é bom até 0,1 e fraco acima de 0,25
Passa nos Core Web Vitals quando os três forem bons no p75.
O badge em cada cartão de métrica mostra a direção de uma linha reta traçada ao longo de todas as semanas. O resumo no topo compara a média do p75 da metade mais antiga das semanas com a metade mais recente. A pontuação de UX happiness ao lado é um número meu: a percentagem de carregamentos de página bons na última semana, calculada a partir da média de LCP, INP, CLS, FCP e TTFB. A Google não a utiliza e, de qualquer forma, não existe nenhuma pontuação oficial de Core Web Vitals.
De onde vêm os dados do CrUX?
Do Chrome em Android e desktop, para utilizadores que sincronizam o histórico e partilham estatísticas de utilização com a Google. O Chrome no iPhone não está incluído. O Edge também não.
Cada ponto semanal cobre os 28 dias anteriores, pelo que os pontos se sobrepõem. Um fix que entre em produção a uma terça-feira precisa de cerca de quatro pontos para se refletir na totalidade.
A Google adiciona um novo ponto todas as segundas-feiras com dados até ao sábado anterior; por isso, à segunda-feira, o ponto mais recente tem dois dias. Os 28 dias são a largura de cada janela, e é por isso que o atraso de 28 dias é um mito.
Isto é o que os visitantes obtiveram nos próprios dispositivos. O PageSpeed Insights executa o Lighthouse uma única vez, a partir de um servidor da Google, com a simulação de um telemóvel e de uma rede lentos. O Lighthouse nunca clica em nada, pelo que não tem qualquer INP. Um 98 no Lighthouse e uma linha vermelha no INP aqui podem ser ambos verdade.
Qual é a diferença em relação ao relatório de Core Web Vitals no Search Console?
O Search Console lê os mesmos dados do CrUX, apenas para os seus sites. Agrupa URLs com comportamento semelhante e classifica cada grupo pela sua pior métrica nos últimos 28 dias.
O Search Console indica que grupo de páginas não passa. As barras semanais aqui ajudam a encontrar a semana em que começou e, a partir daí, a release.
O que verificar quando uma métrica piora
Fique primeiro no telemóvel (o relatório abre aí): é quase sempre o pior dos dois. Depois, olhe para a forma da linha.
Um deploy traduz-se numa subida ao longo de cerca de quatro semanas que depois estabiliza: um tema novo, uma tag adicionada no Tag Manager, uma hero image que passou a ter loading="lazy". Veja o que entrou em produção na semana em que a subida começa.
Uma linha que continua a subir durante meses é, normalmente, sinal de scripts de terceiros a acumularem-se.
No caso do LCP, abra o gráfico de detalhe e veja que parte aumentou. Apenas contabiliza carregamentos de página em que o elemento de LCP é uma imagem. Mais TTFB aponta para o servidor ou para a cache. Um load delay mais longo significa que o browser encontra a imagem do LCP demasiado tarde. Uma load duration mais longa traduz-se numa imagem mais pesada ou numa ligação lenta ao servidor onde está alojada. Um render delay a crescer é o CSS ou o JavaScript a atrasar o paint.
O que o histórico do CrUX não lhe diz
Sites pequenos não têm dados. A Google precisa de muitas visitas no Chrome e não diz quantas. Páginas com noindex ou com um status diferente de 200 também ficam de fora. O URL não tem dados? Experimente o domínio inteiro. O relatório testa com e sem www por si.
Mesmo com dados, obtém apenas um p75 por métrica e por semana para o domínio inteiro ou para um URL popular. O CrUX não diz qual é o template lento, que elemento se move ou que script está a travar o clique.
Para isso é preciso monitorização de utilizadores reais no próprio site. Criei o CoreDash para isso: os carregamentos de página no seu próprio site, com o elemento de LCP e a interação lenta associados, para ver um fix a funcionar em poucas horas.