Core Web Vitals: como medir, priorizar e melhorar LCP, INP e CLS

Os Core Web Vitals são três métricas do Google, LCP, INP e CLS, e uma página é considerada “boa” quando o 75º percentil das visitas reais atinge LCP de até 2,5 s, INP de até 200 ms e CLS de até 0,1. Elas medem carregamento, interatividade e estabilidade visual, e entram nos sinais de experiência de página que o Google usa na busca.

Principais conclusões

O foco na otimização das métricas de Core Web Vitals, priorizando os problemas mais impactantes nos templates de maior tráfego, melhora a experiência real do usuário e a performance do site.

Índice

• O que cada métrica mede e por que importa
• Como medir: dados de campo e de laboratório
• Como melhorar os Core Web Vitals, métrica por métrica
• Diagnóstico e priorização: do relatório ao roteiro de correção
• Monitoramento e relatórios: janelas, agregações e rotina
• Checklist de otimização para sprints curtos
• Erros comuns que enganam a equipe
• Como a Velveteen integra Core Web Vitals à gestão de SEO
• Onde a maioria das equipes gasta energia errada
• Delegue a performance e mantenha o p75 estável
• Perguntas frequentes
• Fontes

O que cada métrica mede e por que importa

As três métricas olham para momentos diferentes da visita. Entender o que cada uma captura evita o erro mais comum: aplicar a mesma receita genérica de “deixar o site mais rápido” a problemas que têm causas muito diferentes.

LCP: quando o conteúdo principal aparece

O Largest Contentful Paint registra o tempo até a renderização do maior elemento de imagem ou bloco de texto visível na viewport. Na prática, é o momento em que o visitante sente que a página “carregou”. Os elementos que costumam ocupar esse posto são a imagem de destaque de um artigo, o banner principal de uma home, uma imagem de produto ou um título grande em texto.

O valor-alvo é de até 2,5 s no p75. Acima de 4,0 s, o Google classifica a experiência como ruim. Entre os dois valores, a página fica na faixa de “precisa melhorar”.

O erro de diagnóstico mais frequente é tratar o LCP como um número único. Ele se decompõe em subpartes, e cada uma pode apontar para uma equipe diferente:

• TTFB (tempo até o primeiro byte): problema de servidor, cache, banco de dados ou redirecionamentos. É assunto de infraestrutura.
• Atraso no carregamento do recurso: o navegador demora a descobrir que precisa daquela imagem, porque ela está em CSS, em um carrossel iniciado por JavaScript ou carregada com lazy loading por engano.
• Duração do download: arquivo pesado, formato inadequado, ausência de CDN.
• Atraso na renderização: o recurso já chegou, mas CSS ou scripts bloqueantes impedem a pintura.

Quando um relatório mostra LCP ruim, o primeiro passo é descobrir qual dessas quatro fatias domina o tempo. Otimizar a imagem quando o gargalo é o TTFB não move o p75 nem um milissegundo.

INP: a resposta às interações ao longo da visita

O Interaction to Next Paint substituiu o FID como métrica oficial de interatividade em 2024. A diferença é conceitual e muda o trabalho de quem otimiza. O FID olhava apenas a primeira interação e só o atraso até o navegador começar a processá-la. O INP avalia a latência de todas as interações ao longo da visita, do clique ou toque até a próxima atualização visual na tela.

O valor final costuma ser a interação mais lenta observada, desconsiderando casos extremos. Isso tem uma consequência importante: um site pode ter um carregamento inicial excelente e, ainda assim, falhar no INP porque o menu pesado, o filtro de produtos ou o carrinho travam depois de alguns minutos de uso.

As metas são INP de até 200 ms para “bom” e acima de 500 ms para “ruim”. Causas típicas de INP alto:

• tarefas longas na thread principal, geralmente JavaScript de terceiros (tags de marketing, chats, widgets);
• handlers de eventos que fazem trabalho pesado de forma síncrona;
• hidratação de frameworks que bloqueia a interface logo após o carregamento;
• atualizações grandes do DOM disparadas por uma única interação.

Como o INP depende de comportamento real, o teste em laboratório captura apenas parte do problema. Os dados de campo são indispensáveis aqui.

CLS: a estabilidade visual

O Cumulative Layout Shift soma os deslocamentos inesperados de layout durante a vida da página. Cada deslocamento é calculado pela fração da tela afetada multiplicada pela distância que os elementos se moveram. O resultado é um número sem unidade: até 0,1 é bom, acima de 0,25 é ruim.

Os casos que o visitante reconhece de imediato são o botão que se desloca no instante do toque e o parágrafo que desce porque um banner carregou acima dele. As causas recorrentes:

• imagens, vídeos e iframes sem largura e altura declaradas;
• anúncios e embeds inseridos sem espaço reservado;
• banners de consentimento ou avisos que empurram o conteúdo;
• fontes web que trocam de métrica ao carregar e reflowam o texto;
• conteúdo injetado dinamicamente acima do que o usuário já está lendo.

Para reproduzir o problema, abra o DevTools, ative o destaque de layout shifts no painel de renderização e recarregue a página com a rede limitada. Navegue em seguida como um visitante faria, rolando e interagindo, porque muitos deslocamentos só aparecem depois do carregamento inicial.

Como medir: dados de campo e de laboratório

Existem dois tipos de dado, e confundi-los é a fonte de metade das discussões improdutivas entre SEO e desenvolvimento.

Dados de campo vêm de visitantes reais, coletados pelo Chrome e agregados no relatório CrUX. É o que alimenta o relatório de Core Web Vitals do Search Console e a seção de dados reais do PageSpeed Insights. Eles refletem dispositivos, redes e comportamentos verdadeiros, e é com base neles que o Google avalia a página. O Search Console agrupa URLs com experiências semelhantes e usa o p75 das visitas reais.

Dados de laboratório vêm de um teste sintético, em ambiente controlado, como o Lighthouse. Servem para depurar: são reproduzíveis, permitem comparar antes e depois de um deploy e funcionam em páginas ainda não publicadas. Por outro lado, não representam a variedade de aparelhos e conexões do seu público e não medem INP de forma completa, já que não há um usuário real interagindo.

A regra prática: use o campo para decidir se há um problema e onde ele está; use o laboratório para descobrir por quê e para validar uma correção antes de publicar. Uma nota alta no Lighthouse não prova nada sobre a avaliação do Google, que parte de dados de campo.

Outro ponto de leitura: a agregação passa quando o p75 de LCP, INP e CLS está na faixa “bom”. Se o INP tiver dados insuficientes, LCP e CLS em “bom” podem bastar para a avaliação.

As ferramentas que usamos no dia a dia:

• Search Console: o relatório de Core Web Vitals mostra grupos de URLs com status bom, precisa melhorar ou ruim, separados por celular e desktop.
• PageSpeed Insights: combina dados de campo do CrUX com um diagnóstico de laboratório da mesma URL, ótimo para uma primeira leitura.
• Chrome DevTools: o painel de desempenho decompõe LCP, mostra tarefas longas e deslocamentos de layout em tempo real.
• WebPageTest: permite escolher localização, dispositivo e velocidade de rede, e gera cascatas de requisições detalhadas.
• Biblioteca web-vitals: o Google recomenda medir com a biblioteca web-vitals para coletar os dados de produção e agregar por p75 em um sistema de RUM próprio.

Como melhorar os Core Web Vitals, métrica por métrica

A ordem abaixo segue o impacto típico que observamos: primeiro o que costuma render mais com menos esforço.

1. LCP: identifique o recurso certo e entregue-o cedo. Descubra qual elemento é o LCP em cada template e garanta que ele seja descoberto logo no HTML, sem depender de JavaScript. Use preload para a imagem principal e prioridade alta de busca.
2. LCP: reduza o peso e a distância. Sirva imagens em formatos modernos, com dimensões adequadas ao tamanho exibido, e distribua o conteúdo estático por uma CDN. Nunca aplique lazy loading à imagem do LCP.
3. LCP: ataque o TTFB. Cache de página, otimização de consultas, menos redirecionamentos e um servidor mais próximo do visitante encurtam a primeira fatia do tempo e beneficiam todas as outras.
4. LCP: libere a renderização. Entregue o CSS crítico no HTML inicial, adie CSS e scripts não essenciais e use fontes com font-display adequado para não bloquear o texto.
5. INP: encontre as tarefas longas. No DevTools, grave uma interação lenta e localize tarefas longas. Identifique se o código vem de você ou de um script de terceiros.
6. INP: divida o trabalho. Quebre execuções longas em partes menores, devolvendo o controle ao navegador entre elas, e mova cálculos pesados para web workers quando possível.
7. INP: enxugue os handlers. Faça no evento apenas o necessário para atualizar a interface e adie o restante (analytics, gravação de estado) para depois da pintura.
8. INP: controle o JavaScript de terceiros. Carregue tags de forma assíncrona, remova as que ninguém usa mais e avalie o custo de cada widget.
9. CLS: declare dimensões. Defina largura e altura (ou aspect-ratio) em imagens, vídeos e iframes para que o navegador reserve o espaço antes do download.
10. CLS: reserve espaço para o que chega depois. Anúncios, embeds e banners precisam de um contêiner com altura mínima definida, e conteúdo novo não deve ser inserido acima do que o usuário já vê.

Dica profissional: corrija primeiro o template que concentra mais URLs e mais tráfego: uma mudança no modelo de página de produto ou de artigo melhora centenas de URLs de uma só vez e aparece no p75 muito mais rápido do que ajustes página a página.

Diagnóstico e priorização: do relatório ao roteiro de correção

Medir sem priorizar gera uma lista infinita de pendências. O caminho que funciona começa no relatório de Core Web Vitals do Search Console, que não avalia URLs isoladas: ele as reúne em grupos com experiência parecida. Páginas com pouco tráfego podem herdar o status do grupo ou da origem, o que complica o diagnóstico quando a estrutura de URLs não separa bem os templates.

Para transformar o relatório em plano de trabalho, aplicamos estes critérios, nesta ordem:

• Tráfego orgânico do grupo: grupos com muitas sessões entram primeiro, porque o ganho de experiência alcança mais pessoas.
• Proximidade do limiar: um grupo próximo do limiar de LCP está a um passo do “bom”; um grupo muito distante exige trabalho estrutural. Vitórias rápidas validam o processo.
• Valor de negócio: páginas de conversão, como checkout, formulários e páginas de serviço, pesam mais do que arquivos antigos.
• Custo de correção: uma alteração de template ou de configuração de CDN vale mais do que centenas de ajustes manuais.
• Dependência de terceiros: problemas causados por scripts externos pedem uma conversa com o responsável pela ferramenta, não uma sprint de código.

Para validar, publique as correções em releases pequenos e rastreáveis, um tipo de mudança por vez, anotando a data de cada deploy. Assim, quando o p75 mudar, você sabe qual ação o moveu. O efeito só aparece de forma completa após a janela de 28 dias do CrUX, então planeje a validação em ciclos desse período.

Monitoramento e relatórios: janelas, agregações e rotina

O Search Console e o CrUX trabalham com uma janela móvel de 28 dias. Isso significa que uma correção publicada hoje será diluída pelos dias anteriores à mudança, e o relatório só reflete o resultado pleno depois de aproximadamente um mês. Quem espera o gráfico mudar em dois dias conclui, erradamente, que a correção não funcionou.

Uma minoria de visitas muito lentas não derruba a avaliação, mas um problema que afeta um quarto do público (por exemplo, usuários de celulares modestos em redes instáveis) sim. Olhe sempre a distribuição, não apenas a média.

A agregação também importa. Os dados podem ser avaliados por página, por grupo de URLs ou pela origem inteira. Quando uma URL tem tráfego insuficiente, ela é julgada pelo grupo ou pela origem, e um problema localizado pode ficar escondido na média. Para diagnóstico fino, cruze o relatório com dados de RUM próprios, coletados com a biblioteca web-vitals.

Uma rotina operacional enxuta:

• Semanal: consulte o relatório do Search Console, procure novos grupos em “precisa melhorar” ou “ruim” e verifique se algum deploy recente coincide com a piora.
• A cada deploy relevante: rode PageSpeed Insights e um teste no WebPageTest nos templates afetados.
• A cada 28 dias: feche o ciclo, compare o p75 com o mês anterior, registre o que melhorou e defina o próximo conjunto de correções.
• Alertas: configure o RUM para avisar quando LCP, INP ou CLS ultrapassarem o limiar em algum template crítico.

Checklist de otimização para sprints curtos

Organize o trabalho em duas faixas e ligue cada tarefa a um objetivo mensurável de p75.

1. Comprimir e redimensionar imagens para os tamanhos realmente exibidos, usando formatos modernos. Objetivo: reduzir o LCP do template em questão.
2. Declarar largura e altura em todas as imagens, vídeos e iframes. Objetivo: levar o CLS para 0,1 ou menos.
3. Remover o lazy loading da imagem principal e adicionar preload ao recurso do LCP. Objetivo: encurtar o atraso de descoberta do recurso.
4. Adiar scripts não essenciais com defer ou carregamento sob demanda. Objetivo: reduzir tarefas longas e o INP.
5. Reservar espaço para anúncios, embeds e banners. Objetivo: eliminar deslocamentos tardios.
6. Aplicar code-splitting para entregar só o JavaScript necessário em cada rota. Objetivo: reduzir bloqueio da thread principal.
7. Otimizar o servidor: cache de página, compressão e CDN. Objetivo: diminuir o TTFB.
8. Extrair o CSS crítico e carregar o restante de forma assíncrona. Objetivo: liberar a primeira pintura.
9. Documentar cada tarefa com data de deploy, métrica-alvo e valor de p75 antes e depois, para validar no ciclo de 28 dias.

Erros comuns que enganam a equipe

Alguns equívocos se repetem em quase todo projeto de otimização, e todos produzem a aparência de progresso sem ganho real.

• Perseguir uma nota perfeita no Lighthouse. A pontuação é uma simulação. Especialistas do Google Search Central alertam que buscar pontuações perfeitas só por SEO é um erro: o foco deve estar na experiência real do usuário. Uma página pode ter uma nota alta no laboratório e falhar no campo.
• Confundir FID com INP. Painéis, scripts de coleta e relatórios internos ainda baseados no FID escondem justamente os problemas de interação que o INP revela.
• Mudar sem observabilidade. Sem RUM e sem registro de deploys, não há como saber o que funcionou. Sem rollback testado, uma otimização agressiva que quebra o layout vira incidente.
• Otimizar só a home. O Google avalia grupos de URLs, e os templates profundos costumam concentrar os piores números.

Como a Velveteen integra Core Web Vitals à gestão de SEO

Na nossa operação, os Core Web Vitals fazem parte da análise técnica que abre qualquer trabalho de SEO, junto com a publicação diária de conteúdo, a construção de backlinks e a presença em comunidades online. Esse conjunto é o que sustenta a autoridade de uma marca, inclusive para ser recomendada por sistemas de IA como o ChatGPT. Este texto aborda SEO para IA, e você encontra mais publicações no blog da Velveteen.

Equipes com desenvolvedores disponíveis e correções pontuais conseguem agir internamente. Quando o problema é contínuo, com releases frequentes que regridem o p75, vale ter quem cuide de tudo de forma recorrente.

Onde a maioria das equipes gasta energia errada

Minha opinião, apoiada no que a documentação do Google deixa claro: os Core Web Vitals são um piso de qualidade, não uma alavanca de ranking que compense conteúdo fraco. Há sinais públicos de que o Google usa essas métricas em seus sistemas de ranking, mas dentro de um conjunto de sinais de experiência. Passar nos três limiares evita um problema; não garante posição.

O conselho convencional tende a falhar em dois pontos. Primeiro, trata o LCP como o grande vilão, quando o INP, mais novo e pouco instrumentado, é onde sites aparentemente rápidos mais reprovam.

O que priorizar primeiro: instrumente os dados de campo, descubra qual template concentra tráfego e falha em alguma métrica, e corrija esse template antes de qualquer refinamento. Uma correção bem escolhida em um modelo de página vale mais do que dez ajustes espalhados.

— Duarte Braga

Delegue a performance e mantenha o p75 estável

Melhorar os Core Web Vitals uma vez é a parte fácil. Difícil é manter o p75 no verde enquanto o site recebe novos scripts, campanhas e templates. Com a Velveteen SEO, nós assumimos a gestão completa: análise técnica, otimizações contínuas, conteúdo diário e backlinks, sem que você precise acompanhar cada detalhe. Com isso, sua equipe de desenvolvimento fica livre para o produto, e a presença da sua marca se fortalece nos mecanismos de busca e nos sistemas de IA.

Veja como funciona em Velveteen.

Perguntas frequentes

O que são as Core Web Vitals?

São três métricas do Google que medem a experiência real do visitante: LCP para carregamento, INP para interatividade e CLS para estabilidade visual. O Google considera a página boa quando o p75 das visitas atinge LCP de até 2,5 s, INP de até 200 ms e CLS de até 0,1.

Como melhorar os Core Web Vitals?

Comece pelo template com mais tráfego e identifique qual métrica falha. Para LCP, priorize o carregamento do recurso principal; para INP, quebre tarefas longas de JavaScript; para CLS, declare dimensões e reserve espaço para conteúdo dinâmico. Valide o resultado em ciclos de 28 dias.

O que o Cumulative Layout Shift mede?

O CLS mede o quanto os elementos da página se deslocam de forma inesperada durante a visita, somando a área afetada e a distância percorrida. O valor é um número sem unidade: até 0,1 é considerado bom e acima de 0,25 é ruim.

Como medir os Core Web Vitals?

Use dados de campo, do Search Console e do PageSpeed Insights, para saber se há problema, e dados de laboratório, como Lighthouse e DevTools, para depurar a causa. Para monitoramento próprio, a biblioteca web-vitals coleta os valores de produção por p75.

Fontes

• Developers
• Developer

Recomendações

• SEO para IA: o guia prático de GEO para ser citado por sistemas generativos
• Otimização de mecanismos generativos: o que é e por onde começar
• SEO para SaaS: como priorizar o que gera trials e pipeline
• SEO para B2B: o que realmente gera leads qualificados em 2026