Core Web Vitals: como medir e corrigir LCP, INP e CLS

O que são as Core Web Vitals

Core Web Vitals são três métricas que o Google usa para descrever a experiência real de quem abre uma página: quanto tempo o conteúdo principal leva para aparecer, quão rápido a página responde a um toque ou clique e quanto o layout se mexe enquanto carrega. Cada uma tem um nome e um limite:

• LCP (Largest Contentful Paint): mede carregamento. É o tempo até o maior elemento visível da tela, normalmente uma imagem de destaque ou um bloco de texto, ser renderizado.
• INP (Interaction to Next Paint): mede responsividade. Observa as interações da visita e registra quanto tempo a página leva para mostrar uma resposta visual.
• CLS (Cumulative Layout Shift): mede estabilidade visual. Soma os deslocamentos inesperados de elementos durante a visita.

O INP substituiu o FID (First Input Delay) como Core Web Vital em 12 de março de 2024. O FID media apenas o atraso da primeira interação. O INP considera as interações da visita inteira e inclui o tempo de processar e desenhar a resposta, o que o torna bem mais exigente. Sites que passavam com folga no FID descobriram problemas de JavaScript que antes não apareciam em nenhum relatório.

Limites oficiais e como são calculados

O web.dev, documentação de desempenho do Google, define três faixas para cada métrica. O valor considerado é o percentil 75 das visitas, separado entre celular e desktop. Ou seja, a página só é considerada boa quando pelo menos três em cada quatro visitas ficam dentro do limite.

O uso do percentil 75 tem uma consequência prática: a média engana. Um site pode carregar em 1,8 segundo para a maioria e em 6 segundos para quem usa celular intermediário em rede móvel. Se esse segundo grupo passa de um quarto das visitas, a página falha. Por isso olhamos sempre a distribuição por dispositivo, não um número único.

Dados de campo e dados de laboratório

Esse é o ponto que mais gera confusão em reunião. Existem dois tipos de medição, e eles respondem a perguntas diferentes:

1. Dados de campo vêm de visitas reais de usuários do Chrome, agregados no Chrome UX Report (CrUX). Aparecem no relatório de Core Web Vitals do Search Console e no topo do PageSpeed Insights. São esses dados que contam para avaliação. Cobrem uma janela móvel de 28 dias, então uma correção leva semanas para aparecer por completo.
2. Dados de laboratório vêm de um teste simulado, como o Lighthouse, com dispositivo e rede definidos. São úteis para diagnosticar e para testar uma correção antes de publicar, mas não refletem a variedade de aparelhos e conexões do público real.

Um site pode ter nota alta no Lighthouse e reprovar em campo, ou o contrário. O INP, em especial, quase não aparece em laboratório, porque depende de interações reais. Quando o tráfego da página é pequeno demais para o CrUX, recomendamos coletar as métricas no próprio site com a biblioteca web-vitals e enviá-las ao GA4, para ter dado de campo mesmo sem volume no relatório público.

Qual o peso real no SEO

A documentação do Google Search afirma que boas Core Web Vitals, junto com outros aspectos de experiência na página, se alinham ao que os sistemas de classificação procuram recompensar. A mesma documentação deixa claro que relevância do conteúdo continua acima de tudo. Uma página lenta com a melhor resposta para a pesquisa tende a vencer uma página rápida com resposta fraca.

Na prática, tratamos as Core Web Vitals como fator de desempate e, principalmente, como fator de conversão. Página que demora para mostrar o produto, que trava ao tocar no botão ou que move o botão de compra no último instante perde venda, independentemente da posição no Google. Em contas de mídia paga, essa perda é ainda mais visível: o clique já foi pago.

O que não prometemos: subir posições apenas por melhorar Core Web Vitals. Essas métricas entram no trabalho de SEO técnico ao lado de rastreamento, indexação, arquitetura e conteúdo.

Como melhorar o LCP

O web.dev divide o LCP em quatro partes: tempo até o primeiro byte (TTFB), atraso até o início do download do recurso, duração do download e atraso de renderização. Identificar qual parte pesa mais evita otimizar o que não é gargalo. As causas mais comuns que encontramos:

• Servidor lento ou sem cache: TTFB alto atrasa tudo o que vem depois.
• Imagem principal descoberta tarde, porque está em CSS de fundo ou é inserida por JavaScript.
• Imagem principal com lazy-loading. A orientação do web.dev é direta: nunca use carregamento tardio na imagem do LCP.
• Imagem pesada, sem formato moderno ou sem tamanhos diferentes para cada tela.
• CSS e scripts que bloqueiam a renderização no início do documento.

Para a imagem principal, o ajuste mais eficiente costuma ser marcá-la como prioridade e garantir que o navegador a encontre cedo:

<!-- Imagem do LCP: prioridade alta, sem lazy-loading, com dimensões -->
<img src="/img/destaque.webp"
     width="1200" height="630"
     fetchpriority="high"
     alt="Descrição da imagem principal">

<!-- Se a imagem só aparece no CSS ou via JavaScript, antecipe a descoberta -->
<link rel="preload" as="image"
      href="https://www.seusite.com.br/img/destaque.webp"
      type="image/webp"
      fetchpriority="high">

<!-- Imagens abaixo da dobra podem, essas sim, carregar depois -->
<img src="/img/secundaria.webp" width="800" height="600"
     loading="lazy" alt="Descrição">

Use o preload com moderação. Pré-carregar muitos recursos anula o efeito, porque todos passam a disputar a mesma prioridade.

Do lado do servidor, o TTFB melhora com cache de página, CDN próxima do público e redução de redirecionamentos encadeados. Em lojas virtuais e portais com muitas páginas dinâmicas, é comum o TTFB responder por boa parte do LCP antes de qualquer imagem entrar na conta. Por isso medimos o tempo de resposta do servidor separado das outras partes. Otimizar a imagem de destaque não resolve uma página que leva um segundo e meio só para entregar o HTML.

Como melhorar o INP

O INP de uma interação tem três fases: o atraso até o código do evento começar a rodar, o tempo de processamento desse código e o atraso até o navegador desenhar o próximo quadro. Na maioria dos sites que analisamos, o problema está no excesso de JavaScript na linha principal.

1. Reduza tarefas longas. Scripts que rodam por centenas de milissegundos bloqueiam qualquer clique nesse intervalo. Dividir o trabalho e devolver o controle ao navegador entre as partes é a recomendação central do web.dev.
2. Revise scripts de terceiros. Chat, mapas de calor, pixels e widgets somam peso. Cada um precisa justificar o custo.
3. Faça o mínimo no clique. O código do evento deve aplicar a mudança visual primeiro e deixar o resto (envio de dados, cálculos) para depois do próximo quadro.
4. Controle o tamanho do DOM. Páginas com milhares de elementos tornam cada atualização mais cara.

Em sites montados com construtores visuais e muitos plugins, o INP costuma ser a métrica mais difícil de corrigir sem rever a base. Nesses casos, discutimos com o cliente se vale remendar ou reconstruir.

Como melhorar o CLS

Deslocamento de layout quase sempre tem uma de quatro origens, e todas têm correção conhecida:

• Imagens e vídeos sem largura e altura declaradas. Com os atributos width e height, o navegador reserva o espaço antes do download.
• Anúncios, embeds e banners que chegam depois. Reserve espaço com altura mínima ou com aspect-ratio.
• Fontes web que trocam a fonte provisória e mudam o tamanho do texto. Escolher fontes de fallback com métricas parecidas reduz o salto.
• Animações que mudam posição com propriedades como top e left. Prefira transform, que não desloca outros elementos.

Avisos de cookies e barras promocionais inseridos no topo da página também são causa frequente. Se eles precisam existir, devem sobrepor o conteúdo ou ter espaço reservado desde o primeiro carregamento.

Como conduzimos um projeto de Core Web Vitals

Para sites com muitas páginas, o trabalho é por modelo de página, não página a página. Uma correção no modelo de produto resolve milhares de URLs de uma vez. O roteiro que seguimos:

1. Levantamos os dados de campo no Search Console e no CrUX, agrupados por modelo de página e dispositivo.
2. Escolhemos as URLs representativas de cada grupo e diagnosticamos em laboratório qual parte de cada métrica pesa mais.
3. Priorizamos pelo cruzamento entre gravidade e tráfego ou receita do modelo.
4. Implementamos com o time de desenvolvimento do cliente ou diretamente, conforme o caso, e validamos em laboratório antes de publicar.
5. Acompanhamos os dados de campo por pelo menos um ciclo de 28 dias para confirmar a melhora real.

Quando o problema está na base do site, e não em ajustes pontuais, o caminho costuma passar por criação de sites com desempenho tratado como requisito desde o projeto, e não como correção posterior.