Como melhorar os Core Web Vitals: um guia prático de LCP, INP e CLS

Os Core Web Vitals são três medições que o Google usa para descrever a experiência de carregar e usar uma página: com que rapidez o conteúdo principal aparece, com que rapidez a página responde quando alguém interage com ela e o quanto o layout fica pulando. Eles fazem parte da forma como o Google avalia a experiência na página, embora conteúdo relevante e útil pese muito mais no ranqueamento. Acima de tudo, são um bom termômetro para saber se o seu site passa a sensação de ser rápido.

As três métricas e o que conta como bom

• Largest Contentful Paint (LCP) — o momento em que a maior imagem ou o maior bloco de texto da viewport termina de ser renderizado. Bom: 2,5 segundos ou menos; ruim: mais de 4 segundos.
• Interaction to Next Paint (INP) — quanto tempo a página leva para responder visivelmente a cliques, toques e teclas pressionadas, ao longo de toda a visita. Bom: 200 milissegundos ou menos; ruim: mais de 500 ms. O INP substituiu o First Input Delay como Core Web Vital em março de 2024.
• Cumulative Layout Shift (CLS) — o quanto o conteúdo visível se desloca de forma inesperada. Bom: 0,1 ou menos; ruim: mais de 0,25.

Uma página é aprovada quando 75% dos carregamentos (o 75º percentil) atingem o limite "bom" de cada métrica, com medição separada para mobile e desktop. Isso significa que o quarto mais lento dos seus visitantes não conta contra você, mas o visitante típico, com um celular intermediário, conta.

Dados de laboratório versus dados de campo

Os dados de campo vêm de visitantes reais. O Chrome UX Report, do Google, os coleta de usuários do Chrome que optaram por participar, em uma janela móvel de 28 dias, e é isso que aparece no relatório de Core Web Vitals do Search Console e no topo do PageSpeed Insights. São os dados que contam — mas exigem tráfego suficiente e mudam devagar.

Os dados de laboratório vêm de um único carregamento da página em condições controladas, como faz o Lighthouse. Estão disponíveis na hora para qualquer página e mostram por que uma métrica está lenta, o que faz deles a ferramenta de diagnóstico. Mas uma execução de laboratório em um celular simulado não vai corresponder aos dispositivos e às redes reais dos seus visitantes, e um teste de laboratório simplesmente não consegue medir o INP, porque ninguém está interagindo com a página. O Total Blocking Time (TBT), o tempo em que a thread principal fica ocupada demais para responder durante o carregamento, é o sinal de laboratório mais próximo.

Use os dois: os dados de campo para saber se você tem um problema e se a correção funcionou; os de laboratório para encontrar a causa. Para coletar os seus próprios dados de campo, a biblioteca JavaScript de código aberto web-vitals envia as três métricas das visitas reais para o seu analytics.

Como melhorar o LCP

O tempo de LCP se divide em quatro partes: o tempo até o primeiro byte, o atraso até o navegador começar a carregar o recurso de LCP, o tempo de download desse recurso e o atraso até ele ser renderizado. Descubra qual parte está grande e então:

• Acelere a resposta do servidor com cache de página e uma CDN, para que o HTML chegue rápido.
• Faça a imagem de LCP ser descoberta cedo: use um <img> normal no HTML, em vez de um background de CSS ou de uma imagem injetada por JavaScript, e nunca coloque loading="lazy" nela.
• Dê prioridade a ela: adicione fetchpriority="high" à imagem de LCP ou faça preload dela se a referência aparecer tarde.
• Deixe-a menor: sirva-a no tamanho em que é exibida, em WebP ou AVIF — veja como reduzir o tamanho das imagens.
• Elimine os recursos que bloqueiam a renderização: coloque o CSS crítico inline, adie os scripts não essenciais e evite uma renderização pesada no cliente antes de o conteúdo principal aparecer.

Como melhorar o INP

O INP fica lento quando a thread principal do navegador está ocupada — normalmente executando JavaScript — no momento em que alguém interage, ou quando o trabalho disparado pela interação demora para ser pintado na tela.

• Envie menos JavaScript. Remova bibliotecas e plugins sem uso, divida os bundles e não hidrate partes da página que não precisam ser interativas.
• Quebre as tarefas longas. Divida o trabalho que passa de 50 ms em blocos menores e devolva o controle ao navegador entre eles, com setTimeout ou com scheduler.yield() onde houver suporte.
• Faça menos nos manipuladores de eventos. Atualize a interface primeiro e só depois faça o trabalho pesado; aplique debounce aos manipuladores de entrada.
• Revise os scripts de terceiros. Widgets de chat, gerenciadores de tags e ferramentas de teste A/B costumam rodar código pesado a cada interação. Carregue-os mais tarde ou só quando forem necessários.
• Mantenha o DOM em um tamanho razoável, porque DOMs grandes deixam cada nova renderização mais lenta.

Como melhorar o CLS

• Dê dimensões a imagens e vídeos com os atributos width e height ou com aspect-ratio no CSS, para que o espaço seja reservado antes de eles carregarem.
• Reserve espaço para anúncios, incorporações e banners. Dê uma altura mínima aos contêineres deles e não insira conteúdo acima do que o visitante já está lendo.
• Dome as fontes web. Use font-display: swap ou optional, faça preload das fontes principais e use uma fonte substituta com métricas ajustadas (size-adjust) para reduzir o deslocamento quando a fonte web chegar.
• Anime com transform, e não com propriedades como top ou height, que movem o conteúdo ao redor.
• Deixe o cache de avanço e retorno (bfcache) trabalhar — evite manipuladores de unload — para que as visitas de retorno sejam restauradas instantaneamente, sem deslocamentos.

Onde o Rudra entra

O verificador de velocidade de sites gratuito executa um único teste de laboratório do Lighthouse, com a simulação mobile padrão. Cada métrica aparece com o valor medido, identificada como medição de laboratório de uma única execução, e comparada com os limites publicados — LCP 2,5 s / 4 s, CLS 0,1 / 0,25, TBT 200 / 600 ms. As auditorias reprovadas listam até cinco dos arquivos ou elementos responsáveis, com a economia estimada, para você saber por onde começar. Ele não mede o INP nem inclui dados de campo; consulte-os no Search Console ou no PageSpeed Insights. Para os motivos pelos quais uma página é lenta de modo geral, veja por que meu site está lento.

Um processo que funciona

1. Consulte o relatório de Core Web Vitals do Search Console para descobrir qual métrica está reprovada e em qual grupo de páginas.
2. Escolha uma página representativa desse grupo e rode um teste de laboratório várias vezes.
3. Corrija primeiro a maior causa, publique e teste de novo em laboratório.
4. Espere os dados de campo se atualizarem (a janela é de 28 dias) antes de avaliar o resultado.