Core Web Vitals: Como Otimizar Cada Métrica

O que são Core Web Vitals

Core Web Vitals são três métricas do Google que medem a experiência real de quem usa uma página: velocidade de carregamento, tempo de resposta a interações e estabilidade visual. Elas fazem parte do algoritmo de ranqueamento desde 2021, dentro do conjunto mais amplo de Page Experience.

As três métricas são o LCP (Largest Contentful Paint), o INP (Interaction to Next Paint) e o CLS (Cumulative Layout Shift). Cada uma isola um sintoma diferente: página que demora para mostrar conteúdo, clique que trava antes de responder e elemento que pula na tela enquanto a página carrega.

Existem duas formas de medir cada uma: dado de campo, coletado de usuários reais pelo Chrome UX Report, e dado de laboratório, gerado por uma ferramenta como o Lighthouse em uma máquina controlada. O Google usa o dado de campo para ranqueamento. O dado de laboratório serve para testar antes de publicar, quando ainda não existe volume de usuário real para medir.

Por que Core Web Vitals pesam no ranqueamento e na conversão

Core Web Vitals funcionam como um sinal de ranqueamento entre páginas com relevância parecida para a mesma busca. Não superam um conteúdo melhor, mas desempatam quando o conteúdo é equivalente, e o Google usa dado real de usuário, não só teste de laboratório, para decidir isso.

O impacto em conversão é mais direto do que o em SEO. Suponha um checkout onde o botão de finalizar compra demora para responder ao toque: cada instante de atraso na interação aumenta a chance de o usuário desistir antes de concluir. Layout que pula empurra o dedo do usuário para um clique errado, geralmente em um anúncio ou em um link que ele não queria abrir. O usuário não lê relatório de performance. Ele sente a página travando e sai.

Suponha uma loja com dez mil visitas por dia na página de produto. Se o LCP está em 4 segundos e cai para 2 segundos, uma fração maior desses visitantes chega a ver o botão de compra antes de desistir da espera. O número exato de vendas recuperadas depende do produto e do público, mas a direção do efeito é sempre a mesma: menos espera, menos abandono.

LCP: o que mede e o que fazer quando está alto

LCP mede o tempo até o maior elemento visível da tela terminar de carregar, geralmente uma imagem de capa, um vídeo ou um bloco de texto grande. A meta é manter esse tempo abaixo de 2,5 segundos no percentil 75 dos usuários reais.

Os culpados mais comuns são imagem sem otimização, fonte que bloqueia a renderização e CSS crítico que só chega depois de várias requisições em cadeia. Comprimir a imagem principal, usar preload na fonte e no recurso do LCP, e adiar o CSS que não afeta a primeira tela resolve a maior parte dos casos. O guia completo de como reduzir esse tempo passo a passo está em como otimizar o LCP do seu site.

INP: o que mede e como reduzir o atraso de resposta

INP mede o tempo entre uma interação do usuário, como um clique ou um toque, e o momento em que a tela responde visualmente a ela. A meta é manter esse tempo abaixo de 200 milissegundos no percentil 75 dos usuários reais. Ele substituiu o antigo FID em março de 2024 porque captura o atraso da interação inteira, não só o primeiro instante dela.

JavaScript que trava a thread principal é a causa mais comum de INP alto. Um listener de clique que dispara um cálculo pesado, uma renderização de lista grande sem virtualização ou um script síncrono de terceiro seguram a resposta visual da página. Dividir tarefas longas em partes menores, adiar trabalho que não precisa rodar durante a interação e revisar script de terceiro como pixel de anúncio, chat ou analytics, que competem pela thread principal, reduz o atraso.

Em aplicações React o padrão mais comum é o re-render em cascata: um estado muda no componente pai e arrasta uma árvore inteira de filhos que não precisavam atualizar. Memoizar componente pesado e mover estado para o nível mais próximo de quem realmente o usa costuma cortar boa parte do atraso sem tocar na lógica de negócio.

CLS: o que mede e como evitar o layout instável

CLS mede o quanto os elementos da página se deslocam depois de já terem aparecido na tela. Um CLS abaixo de 0,1 é considerado bom, e cada deslocamento inesperado soma no total.

A causa mais frequente é imagem ou anúncio sem dimensão reservada no CSS. O navegador não sabe o tamanho final até o arquivo carregar, então empurra o conteúdo abaixo quando ele chega. Declarar width e height (ou aspect-ratio) em toda imagem, reservar espaço fixo para banner de anúncio e evitar inserir conteúdo acima do que o usuário já está lendo resolve a maior parte dos casos.

Como medir Core Web Vitals na prática

Medir antes de otimizar evita corrigir um problema que não existe. Estes passos cobrem tanto dado de campo quanto de laboratório.

1. Abra o PageSpeed Insights e rode a URL da página. Ele traz o dado de campo do CrUX, quando existe volume suficiente, e o dado de laboratório do Lighthouse.
2. Confira o relatório Core Web Vitals no Google Search Console. Ele agrupa páginas por URL parecida e mostra quais grupos estão em "Precisa melhorar" ou "Ruim".
3. Rode o Lighthouse local, no DevTools do Chrome, para testar antes de publicar uma mudança, sem esperar o dado de campo acumular.
4. Instale a extensão Web Vitals no Chrome para ver LCP, INP e CLS em tempo real enquanto navega pela própria página.
5. Depois de cada ajuste, repita a medição de campo por alguns dias antes de decidir se o problema foi resolvido. Dado de laboratório melhora na hora, dado de campo demora para refletir o uso real.

Core Web Vitals não é um checklist para rodar uma vez e esquecer. Cada deploy pode introduzir uma imagem sem dimensão, um script novo de terceiro ou uma fonte que volta a bloquear a renderização. Medir com regularidade, com dado de campo e de laboratório juntos, é o que mantém as três métricas dentro da meta.

Se sua aplicação está com Core Web Vitals no vermelho e você quer um diagnóstico de performance completo, fale com a gente.