Core Web Vitals: LCP, INP e CLS na prática

Core Web Vitals são três métricas com que o Google mede a experiência real de quem acessa uma página. Elas fazem parte dos sinais de experiência usados no ranqueamento e, mais importante, têm impacto direto em conversão: site lento perde venda antes de perder posição.

As três métricas e seus limites

Para ser aprovado, o site precisa atingir a faixa boa em 75% das visitas reais de cada métrica. Não basta ir bem no teste isolado da sua máquina.

LCP: o tempo até a página parecer pronta

O Largest Contentful Paint marca o instante em que o maior elemento da área visível termina de carregar. Normalmente é a imagem principal, um banner ou o bloco de texto do topo.

Causas comuns de LCP alto

• Imagem do topo pesada ou em formato antigo (JPG e PNG em vez de WebP).
• Servidor lento a responder, elevando o tempo até o primeiro byte.
• CSS e JavaScript bloqueando a renderização.
• Fontes web carregadas sem estratégia, atrasando o texto.
• Falta de cache e de rede de distribuição de conteúdo.

Como corrigir

1. Converta as imagens para WebP ou AVIF e dimensione-as para o tamanho real de exibição.
2. Faça preload da imagem do topo e marque-a com fetchpriority="high".
3. Nunca aplique loading="lazy" na imagem principal: isso atrasa justamente o elemento medido.
4. Reduza CSS e JS críticos e adie o que não é essencial ao primeiro paint.
5. Ative cache no servidor e compressão gzip ou brotli.

INP: quanto o site demora a responder

O Interaction to Next Paint substituiu o antigo FID em março de 2024. Ele mede o tempo entre a ação do usuário (clique, toque, tecla) e a atualização visual correspondente, considerando todas as interações da visita, e não apenas a primeira.

INP ruim quase sempre significa JavaScript pesado ocupando a thread principal. Os caminhos de correção:

• Reduzir e dividir os pacotes de JavaScript, carregando o que for necessário sob demanda.
• Remover scripts de terceiros que não geram retorno mensurável.
• Quebrar tarefas longas em blocos menores para liberar a thread.
• Evitar animações que dependem de cálculo de layout a cada frame.
• Dar retorno visual imediato à interação, mesmo antes do processamento terminar.

CLS: quando o layout pula sob o dedo do usuário

O Cumulative Layout Shift mede o quanto os elementos se deslocam sozinhos durante o carregamento. É a métrica mais irritante para o usuário: você vai tocar em um botão e um banner empurra tudo para baixo no instante do toque.

Causas típicas

• Imagens e vídeos sem width e height declarados.
• Anúncios e embeds sem espaço reservado.
• Conteúdo injetado por JavaScript acima do que já está visível.
• Troca de fonte que altera a altura das linhas.
• Elementos em grid ou flex que só ganham dimensão depois que a imagem carrega.

A lição vale para qualquer site: teste sempre com limitação de rede ativada, não apenas na sua conexão.

Onde medir: laboratório e campo

Existem duas naturezas de dado, e confundi-las gera diagnósticos errados:

• Laboratório: Lighthouse e a aba de performance do navegador simulam uma visita em ambiente controlado. Ótimo para depurar, não é o que o Google usa para ranquear.
• Campo: o relatório CrUX reúne dados de usuários reais do Chrome nos últimos 28 dias. É esse número que conta como sinal de ranqueamento.

Por isso um site corrigido hoje pode continuar exibindo notas ruins no PageSpeed por semanas: o dado de campo é uma média móvel que precisa de tempo para refletir a melhoria. Acompanhe o relatório de Core Web Vitals no Search Console para ver a evolução por grupo de URLs.

Ordem de prioridade nas correções

1. Corrija primeiro o CLS: costuma ser barato de resolver e tem impacto imediato na percepção do usuário.
2. Ataque o LCP: imagens e tempo de resposta do servidor resolvem a maior parte dos casos.
3. Por último, o INP, que geralmente exige revisão de JavaScript e de scripts de terceiros.

Se o seu site reprova nas três métricas, o caminho mais rápido costuma ser uma auditoria completa. É o escopo do nosso serviço de SEO técnico, que entrega o plano priorizado por impacto.