Relatório de Core Web Vitals

Dados de campo e dados de laboratório são duas coisas diferentes

Um teste de laboratório, como o Lighthouse, carrega a sua página uma vez em um celular intermediário simulado, com conexão limitada. Você pode repeti-lo quantas vezes quiser e ele traz muitos detalhes, mas o visitante que ele descreve é imaginário.

Os dados de campo vêm de visitas reais. Usuários do Chrome que aceitaram compartilhar estatísticas de uso enviam tempos anônimos, e o Google os agrega ao longo dos últimos 28 dias no Chrome UX Report, conhecido como CrUX. São esses os dados que a Pesquisa Google lê ao avaliar a experiência na página. Uma página pode tirar 95 no laboratório e ainda reprovar em campo porque o público real usa celulares mais antigos. Ela também pode passar em campo com uma nota de laboratório medíocre porque a maioria dos visitantes chega com o cache já preenchido.

Este relatório pede primeiro os dados de campo, já que é essa a versão que conta.

Os cinco tempos da tabela

As três primeiras são as Core Web Vitals. FCP e TTFB estão ali como extras porque ajudam a explicar um LCP lento. Elas não contam para a nota.

Como o relatório é montado

Seguimos os redirecionamentos até o endereço final e depois consultamos o CrUX duas vezes, uma para celulares e outra para desktops. Cada consulta tenta primeiro a página exata e recorre à origem inteira quando a página sozinha tem pouco tráfego. A linha acima de cada tabela diz qual das duas você está lendo.

O valor exibido para uma métrica é o percentil 75, ou seja, três visitas em cada quatro foram pelo menos tão rápidas. A barra colorida ao lado mostra a proporção de visitas nas faixas boa, a melhorar e ruim.

Para a nota, cada Core Web Vital vale 2 pontos quando boa, 1 quando precisa melhorar e 0 quando ruim. Seis pontos de seis é um A, cinco um B, quatro um C, três um D, dois um E e menos que isso um F. Uma métrica ruim limita a nota a D, por melhores que sejam as outras duas. A nota principal é a do celular quando há dados de celular.

Quando o Chrome não tem dados

O CrUX só cobre páginas públicas e visitadas com frequência suficiente. Para todo o resto, o relatório roda um teste do PageSpeed Insights em um celular simulado e avisa claramente que fez isso. Você recebe então a pontuação de desempenho do Lighthouse (A a partir de 90, B a partir de 75, C a partir de 50, D a partir de 35, E a partir de 20), valores de laboratório para LCP e CLS, e o Total Blocking Time no lugar do INP, já que não dá para medir a resposta a uma entrada sem uma pessoa fazendo a entrada. Até cinco auditorias com a maior economia de tempo estimada são listadas abaixo.

O que faz cada número mudar

LCP

Encontre o elemento LCP no painel Performance do Chrome DevTools. Geralmente é a imagem principal. Sirva-a no tamanho em que é exibida, em WebP ou AVIF, adicione fetchpriority="high" e nunca coloque loading="lazy" nela. Se o TTFB já passa de 0,8 s, conserte primeiro o servidor com cache de páginas ou um CDN. O detalhamento do peso da página mostra os arquivos mais pesados.

INP

Tarefas longas de JavaScript impedem a página de responder às entradas. Remova as tags e os plugins que você não usa mais, carregue scripts de terceiros com defer e divida o trabalho que roda por mais de 50 ms.

CLS

Dê a cada imagem e vídeo os atributos width e height, reserve espaço para anúncios e incorporações com min-height ou aspect-ratio e não insira banners acima de um conteúdo que já está visível.

Os dados de campo são uma janela móvel de 28 dias. Depois de uma correção, os números melhoram um pouco a cada dia e levam quatro semanas para mostrar o efeito completo. As visitas do Safari e de qualquer navegador no iPhone nunca fazem parte do CrUX, então o relatório só descreve o seu público do Chrome.