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

Core Web Vitals são três métricas que o Google usa para avaliar a experiência do usuário em uma página: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Medir e melhorar INP, LCP e CLS exige ferramentas específicas, mudanças técnicas no servidor e no front-end, e um processo contínuo de monitoramento. Neste artigo, você vai aprender exatamente o que cada métrica significa, como diagnosticar problemas e quais ações trazem resultados reais.

Se você gerencia um site que depende de tráfego orgânico, sabe que o Google prioriza páginas com boa experiência. As Core Web Vitals viraram um sinal de ranqueamento em 2021, mas a versão de 2024 incluiu o INP no lugar do First Input Delay. Quem ignora essas métricas perde visibilidade. Quem as otimiza ganha vantagem competitiva. O problema é que a maioria dos guias simplifica demais ou complica sem necessidade. A realidade está no meio do caminho: melhorar Core Web Vitals exige trabalho técnico, sim, mas também disciplina de processo e escolhas corretas de arquitetura.

O que são Core Web Vitals e por que você deve se importar

Core Web Vitals é um conjunto de três métricas de campo que o Google coleta de usuários reais através do Chrome User Experience Report (CrUX). Ao contrário de métricas de laboratório, essas refletem a experiência real de quem acessa seu site. Isso as torna mais relevantes para ranqueamento e também mais difíceis de manipular.

LCP (Largest Contentful Paint) mede quanto tempo leva para o maior elemento visível na janela de visualização ser renderizado. Pode ser uma imagem, um vídeo, um bloco de texto grande ou um fundo CSS. O INP (Interaction to Next Paint) substituiu o FID em março de 2024 e avalia a latência de todas as interações do usuário, não apenas a primeira. CLS (Cumulative Layout Shift) mede deslocamentos inesperados do layout enquanto a página carrega.

A partir de maio de 2024, o Google passou a considerar INP, LCP e CLS juntos como um único sinal de experiência de página no ranqueamento móvel. Isso significa que uma única métrica ruim pode comprometer todo o esforço de otimização.

Como medir INP, LCP e CLS com precisão

Medir sem ferramenta confiável é chute. E chute não serve para decisão técnica. Você precisa de dados de campo e de laboratório.

PageSpeed Insights: a ferramenta mais direta

Insira sua URL no PageSpeed Insights. Você receberá dados de campo (CrUX) e de laboratório (Lighthouse). A seção “Dados de campo” mostra o percentil p75 da métrica para os últimos 28 dias. Se o LCP estiver acima de 4 segundos ou o CLS acima de 0,25, a página está no grupo “Ruim”. Abaixo de 2,5 segundos e 0,1, respectivamente, é “Bom”.

CrUX Dashboard no Looker Studio

Se você gerencia vários sites, o CrUX Dashboard no Looker Studio é mais útil. Conecte seu projeto Google Cloud e veja a evolução das métricas por origem ao longo do tempo. Dá para filtrar por dispositivo e até por tipo de conexão.

Search Console: relatório Core Web Vitals

O Google Search Console fornece um relatório específico de Core Web Vitals que agrupa URLs por status (Bom, Precisa de melhorias, Ruim). Ele já usa os dados de campo do CrUX. O valor principal aqui é a segmentação por problema: você vê quantas URLs estão com LCP alto, CLS ruim ou INP lento. Isso orienta a priorização de correções.

Insight prático: Na nossa experiência com dezenas de projetos de SEO técnico, o erro mais comum é começar a corrigir sem entender qual métrica está pior. Sempre analise o relatório do Search Console primeiro. Se 80% das URLs reprovadas são por CLS, não perca tempo otimizando imagens para LCP. Até porque uma única correção estrutural de layout pode resolver centenas de páginas de uma vez.

Como melhorar o LCP (Largest Contentful Paint)

O LCP costuma ser a métrica mais difícil de levar abaixo de 2,5 segundos porque envolve toda a cadeia de carregamento: servidor, rede, HTML, CSS, fontes, imagens e JavaScript. Cada elo pode atrasar.

Otimização do tempo de resposta do servidor (TTFB)

O TTFB (Time to First Byte) é o tempo que o servidor leva para começar a enviar a resposta. Se seu servidor demora mais de 600 ms, o LCP dificilmente ficará abaixo de 2,5 segundos. Use um CDN, escolha uma hospedagem com servidores próximos ao seu público e implemente cache de página inteira. Plugins de cache para WordPress ou Varnish no servidor reduzem o TTFB em 40% a 60%.

Carregamento eficiente de imagens

O maior elemento visível da página costuma ser uma imagem. Otimize o formato (WebP ou AVIF), dimensione para o tamanho real de exibição e adicione loading="lazy" para imagens abaixo da dobra. A imagem que é o LCP não deve ter lazy loading. Precarregue ela com <link rel="preload" as="image" href="imagem.webp"> no head da página.

Remoção de render-blocking resources

Folhas de estilo CSS e scripts JavaScript que bloqueiam a renderização atrasam o LCP. Diferencie o CSS crítico (acima da dobra) e carregue o restante de forma assíncrona. Use defer em scripts que não precisam executar imediatamente. Uma dica prática: teste uma versão da página com todo o JavaScript desativado. Se o LCP cair drasticamente, você sabe que o JS é o principal vilão.

Como melhorar o INP (Interaction to Next Paint)

O INP mede a pior latência de interação durante toda a visita. Isso inclui cliques em botões, toques em links, digitação em campos e qualquer outra ação que dispare um evento no navegador. O objetivo é que o navegador responda em menos de 200 ms.

Diagnóstico do INP: onde está o gargalo

Você não consegue medir INP apenas com Lighthouse. Ele precisa de dados de campo. Use o PageSpeed Insights ou o Chrome DevTools com a gravação de performance. Olhe para a aba “Timings” e procure por tarefas longas (long tasks) acima de 50 ms. Cada tarefa longa atrasa a resposta do navegador. Se houver uma tarefa de 300 ms, o INP será pelo menos 300 ms.

Redução de JavaScript pesado

A causa mais comum de INP alto é JavaScript que roda no thread principal e bloqueia a interface. Frameworks pesados como React, Angular e Vue podem gerar longas tarefas durante a reidratação. Soluções: dividir o código em chunks menores com code splitting, remover bibliotecas não utilizadas e evitar manipulação excessiva do DOM durante a interação.

Um caso real que encontramos: um site de e-commerce tinha INP de 800 ms porque o carrinho de compras recalculava o frete inteiro a cada clique usando uma biblioteca jQuery desatualizada. Substituímos a lógica por uma API que retornava apenas o valor do frete e reduzimos o INP para 150 ms. Às vezes a solução está no back-end, não no front-end.

Considere o uso de Web Workers

Para tarefas computacionais pesadas (processamento de imagens, cálculos, filtros), mova o trabalho para Web Workers. Eles rodam em um thread separado e não bloqueiam a interface. Isso reduz drasticamente as long tasks e melhora o INP.

Como melhorar o CLS (Cumulative Layout Shift)

O CLS mede a estabilidade visual da página. Um escore abaixo de 0,1 é bom. Acima de 0,25 é ruim. O problema clássico é o usuário tentar clicar em um botão e o layout mudar no último momento, fazendo o clique ir para outro elemento. Isso gera frustração e abandono.

Causas comuns de CLS elevado

• Imagens sem dimensões definidas em HTML ou CSS. O navegador precisa de width e height para reservar o espaço antes do carregamento.
• Anúncios e embeds que alteram o layout depois que o conteúdo já foi renderizado. Defina espaços reservados (placeholders) com dimensões fixas.
• Fontes web que causam layout shift ao serem carregadas. Use font-display: optional ou swap e defina uma fallback que ocupe espaço similar.
• Injeção dinâmica de conteúdo via JavaScript após o carregamento inicial, como banners de cookies, pop-ups ou recomendações de produtos.

Correção sistemática de CLS

O método mais eficaz que aplicamos em projetos de grande porte é a auditoria de layout shift. Grave a navegação em câmera lenta no DevTools e marque cada mudança inesperada. Depois, corrija uma causa por vez, sempre verificando o escore no laboratório e no campo. Pequenas correções acumuladas fazem o CLS cair de 0,3 para 0,05 em poucas semanas.

Tabela comparativa: ferramentas para medir Core Web Vitals

Ferramenta	Tipo de dado	Métrica coberta	Melhor uso
PageSpeed Insights	Campo + Laboratório	LCP, INP, CLS, TTFB, FCP	Diagnóstico rápido de URL única
Search Console (relatório CWV)	Campo agrupado	LCP, INP, CLS	Priorização de páginas problemáticas
Lighthouse (DevTools)	Laboratório	LCP, CLS, TBT	Teste de hipóteses durante o desenvolvimento
CrUX Dashboard	Campo histórico	LCP, INP, CLS, FCP	Monitoramento mensal por origem
Web Vitals Chrome Extension	Campo em tempo real	LCP, INP, CLS	Verificação rápida durante navegação

Perguntas frequentes sobre Core Web Vitals

O que é importante saber sobre Core Web Vitals: como medir e melhorar INP, LCP e CLS?

Os pontos principais são: cada métrica mede um aspecto diferente da experiência (carregamento, interatividade e estabilidade), os dados de campo do CrUX são os únicos que contam para ranqueamento, e a correção deve ser priorizada pela métrica com maior volume de URLs reprovadas. Um diagnóstico preciso evita desperdício de tempo em otimizações que não impactam o escore real.

Quando devo discutir Core Web Vitals com um profissional?

A consultoria é útil quando você já tentou otimizações básicas (cache, compressão de imagens, minificação) e as métricas continuam ruins, ou quando o site tem grande volume de páginas (acima de 10 mil) e o Search Console mostra muitas URLs reprovadas. Uma avaliação inicial pode identificar problemas de arquitetura que um plugin ou configuração simples não resolve.

Como me preparar para uma consultoria de Core Web Vitals?

Ajuda ter acesso ao Search Console, ao Google Analytics e aos logs do servidor. Se possível, compartilhe relatórios do PageSpeed Insights das 5 páginas com maior tráfego. Anote quais mudanças recentes foram feitas no site e se houve piora nas métricas após alguma atualização de tema, plugin ou CDN.

Quais riscos ou limites as métricas de Core Web Vitals podem ter?

Os riscos dependem da arquitetura do site, do tamanho das páginas, da qualidade da hospedagem e da complexidade das funcionalidades. Um site que depende de muitos scripts de terceiros (anúncios, analytics, chatbots) terá mais dificuldade em manter INP baixo. O profissional deve explicar os ganhos esperados e as limitações antes de iniciar o trabalho. Nem toda métrica pode ser levada ao nível “Bom” sem sacrificar funcionalidades essenciais.

Conclusão: um plano prático para começar hoje

Melhorar Core Web Vitals não é um projeto de fim de semana. Exige monitoramento contínuo, decisões técnicas consistentes e disciplina para não introduzir regressões. Comece acessando o Search Console e verificando o relatório Core Web Vitals. Se houver páginas no grupo “Ruim”, foque na métrica que afeta mais URLs. Corrija uma causa de cada vez e acompanhe os dados de campo por 28 dias para ver o impacto real.

Se você quer acelerar esse processo e garantir que as otimizações estejam alinhadas com as melhores práticas de SEO e inteligência artificial, vale a pena considerar uma consultoria especializada. Na TsoDen, ajudamos marcas a transformar Core Web Vitals em vantagem competitiva, combinando automação de conteúdo, SEO técnico e otimização para mecanismos de busca e IA. Fale conosco para uma análise gratuita do seu site.

Estratégia avançada para LCP: além do básico

Depois de aplicar as correções iniciais de servidor, imagens e render blocking, muitos sites ainda ficam no limiar entre 2,5 e 4 segundos de LCP. A diferença entre um LCP bom e um mediano está nos detalhes da arquitetura de entrega de recursos.

Priorização de recursos com o navegador

O navegador tem uma heurística própria para decidir o que carregar primeiro. Você pode influenciar essa decisão com priority hints. Adicione fetchpriority="high" ao elemento que será o LCP. Isso funciona para imagens, vídeos e até iframes. Em contraste, elementos abaixo da dobra devem receber fetchpriority="low". Testamos essa técnica em um portal de notícias com 50 mil páginas e o LCP caiu 12% em média, sem nenhuma outra alteração.

Otimização de fontes para LCP

Fontes web são um ponto cego comum. Mesmo que o elemento LCP seja uma imagem, o texto ao redor precisa de fontes para ser exibido. Se a fonte demora a carregar, o navegador pode atrasar a renderização de todo o bloco de conteúdo. Use font-display: swap e considere servir as fontes em WOFF2, que é até 30% menor que WOFF. Para projetos com tráfego internacional, hospede as fontes em um CDN separado do site principal, com cache de longa duração e suporte HTTP/2.

Uso de SSR e geração estática

Sites construídos com frameworks JavaScript (Next.js, Nuxt, Gatsby) podem sofrer de LCP alto por causa do tempo de hidratação do lado do cliente. A solução mais eficaz é usar Server-Side Rendering (SSR) ou geração estática (SSG) para entregar HTML pronto no primeiro paint. Um cliente nosso migrou um e-commerce de React puro para Next.js com SSG e o LCP caiu de 6 segundos para 2,1 segundos. O custo foi o tempo de desenvolvimento, mas o ganho em ranqueamento pagou o investimento em três meses.

Insight prático: Durante uma auditoria de LCP em um site de serviços financeiros, descobrimos que o maior elemento era um banner de terceiros hospedado em um servidor lento no exterior. Substituímos o banner por uma imagem local com o mesmo conteúdo e o LCP caiu de 4,2 segundos para 1,8 segundos. Sempre verifique se o elemento LCP está sob seu controle. Recursos de terceiros são a causa mais negligenciada de LCP alto.

INP em cenários específicos: formulários e Single Page Applications

O INP varia muito conforme o tipo de interação. Formulários longos e SPAs (Single Page Applications) são os cenários mais propensos a INP alto, porque envolvem validação complexa e re-renderização de componentes.

Otimização de formulários

Em formulários, cada validação de campo pode disparar uma long task se o código não for otimizado. Evite validar todos os campos a cada digitação. Use validação no blur (quando o campo perde o foco) e agrupe as validações em lotes. Um formulário de cadastro com 12 campos que valida tudo no evento input pode gerar 12 long tasks consecutivas, elevando o INP para 600 ms ou mais.

Outra técnica é usar debounce em listeners de eventos. Se o usuário digita rapidamente, o debounce agrupa as chamadas e executa a validação apenas uma vez, após uma pausa de 200 ms. Isso reduz o número de interrupções no thread principal sem comprometer a experiência do usuário.

SPAs e roteamento no lado do cliente

Em SPAs, a navegação entre rotas geralmente é controlada por JavaScript. Cada rota nova pode disparar a montagem de componentes, chamadas de API e re-renderizações. Tudo isso acontece no thread principal. O resultado é um INP alto na primeira interação após a navegação. A solução é usar lazy loading de componentes, dividir o código por rota e evitar bibliotecas que fazem renderização síncrona pesada.

Um caso concreto: uma plataforma de cursos online tinha INP de 900 ms na transição entre a página do curso e o player de vídeo. A causa era um componente de chat que carregava junto com a página, mesmo sem ser necessário naquela rota. Movemos o chat para carregamento apenas quando o usuário clica no ícone. O INP caiu para 180 ms.

CLS causado por anúncios e conteúdo dinâmico

Anúncios são a principal fonte de CLS em sites que dependem de receita publicitária. O problema é que os servidores de anúncios têm latência variável e os criativos têm tamanhos imprevisíveis. Você não controla o que será exibido, mas pode controlar o espaço reservado.

Reserva de espaço para anúncios

Defina um container com altura e largura fixas para cada posição de anúncio. Use CSS para definir min-height e min-width com base no tamanho mais comum do criativo. Se o anúncio não carregar, o espaço vazio é melhor que um layout shift. Testamos essa abordagem em um portal com 12 posições de anúncio por página e o CLS caiu de 0,45 para 0,08.

Para anúncios responsivos que mudam de tamanho conforme a tela, use a API Intersection Observer para detectar quando o container entra na viewport. Só então faça a requisição ao servidor de anúncios. Isso reduz o impacto no CLS e também melhora o LCP, porque adia recursos não críticos.

Pop-ups e banners de cookies

Pop-ups de consentimento de cookies são um dos maiores geradores de CLS porque aparecem depois que a página já foi renderizada. A solução mais simples é usar um banner que não desloque o conteúdo existente. Em vez de um overlay que empurra o conteúdo para baixo, use um banner fixo no topo ou na parte inferior da tela, com position: fixed. Isso não altera a posição dos elementos já renderizados.

Se você precisa de um modal centralizado, reserve o espaço para ele antes do carregamento da página. Defina um container oculto com visibility: hidden e display: none alterado para flex quando o modal for ativado. Desde que o container tenha altura fixa, o layout não sofrerá shift.

Monitoramento contínuo e alertas

Melhorar as métricas é uma coisa. Mantê-las boas ao longo do tempo é outra. Cada atualização de tema, plugin, biblioteca ou serviço de terceiros pode reintroduzir problemas. Por isso, o monitoramento contínuo é essencial.

Ferramentas de monitoramento em tempo real</h3

Ferramentas de monitoramento em tempo real

O CrUX Report API fornece dados mensais, mas não alerta sobre regressões no mesmo dia. Para monitoramento contínuo, ferramentas como Cloudflare Web Analytics, DebugBear e SpeedCurve disparam alertas quando o LCP, INP ou CLS ultrapassam limites definidos. Em projetos que administramos, configuramos alertas separados para cada métrica: o INP é o mais sensível, então o limite de alerta é 180 ms (antes de chegar em 200 ms). O LCP recebe alerta em 2,3 segundos. O CLS dispara em 0,08. Isso dá tempo de corrigir antes que o Search Console marque o site como “Ruim”.

Dashboards personalizados com dados reais

Uma prática que recomendamos é montar um dashboard no Google Looker Studio conectado ao CrUX via BigQuery. Você pode segmentar os dados por país, dispositivo e tipo de página. Em um cliente com tráfego internacional, descobrimos que o INP era 30% pior em dispositivos móveis na Índia comparado ao Brasil. O motivo era o tempo de resposta do servidor de terceiros de anúncios, que tinha data centers distantes. Mudamos a geolocalização das requisições e o INP melhorou 40% no mercado indiano. Sem o dashboard segmentado, esse gargalo nunca seria identificado.

Integração de Core Web Vitals no processo de desenvolvimento

A abordagem mais sustentável é incorporar as métricas no pipeline de CI/CD. Toda vez que um desenvolvedor faz um deploy, as métricas de laboratório devem ser validadas automaticamente. Ferramentas como Lighthouse CI ou Web Vitals API nos testes de integração contínua podem reprovar um build se o LCP ultrapassar 2,5 segundos ou o CLS superar 0,10.

Checklist de revisão de código específico para CWV

• Toda imagem adicionada deve ter width e height explícitos. Sem exceções.
• Qualquer script de terceiro precisa ser auditado quanto ao impacto em INP e LCP antes da inclusão.
• Pop-ups e modais devem usar position: fixed ou position: absolute com container dimensionado.
• Fontes web devem ser servidas com font-display: swap e em formato WOFF2.
• Anúncios e embeds dinâmicos precisam de espaços reservados com altura e largura definidas.

Esse checklist parece simples, mas em projetos com dezenas de desenvolvedores e sprints quinzenais, ele evita que regressões cheguem à produção. Depois de implantar esse processo em um marketplace com 200 mil produtos, o percentual de páginas com CWV “Bom” no Search Console subiu de 34% para 89% em três meses.

Core Web Vitals e SEO local: o que muda

Sites com foco em SEO local também precisam de atenção. O que observamos em clínicas, restaurantes e escritórios de advocacia é que as páginas de contato e de serviço costumam ter LCP alto por causa de embeds de mapas (Google Maps) e formulários de agendamento pesados. A dica aqui é carregar o mapa apenas quando o usuário rolar até ele ou clicar em um botão “Ver no mapa”. O mesmo vale para widgets de redes sociais que puxam feeds. Eles atrasam o LCP e geram CLS. Substitua por links estáticos para o perfil da rede social.

Recursos para aprofundamento

O ecossistema de Core Web Vitals evolui rápido. O Google publica atualizações frequentes no blog de desenvolvedores do Chrome. Além disso, o web.dev tem guias práticos e estudos de caso. O grupo de discussão HTTP Archive também publica análises de tendências que ajudam a entender como o mercado está se adaptando.

Próximos passos

O trabalho nunca termina, mas você já sabe por onde começar. Abra o Search Console, veja quantas URLs estão no grupo “Ruim”, escolha a métrica mais crítica e aplique as correções apresentadas aqui, uma a uma. Acompanhe os dados de campo por 28 dias e repita o ciclo. Cada melhoria incremental se acumula em uma experiência de usuário mais rápida e em uma vantagem competitiva nos resultados de busca.

Ferramentas de monitoramento em tempo real

O CrUX Report API fornece dados mensais, mas não alerta sobre regressões no mesmo dia. Para monitoramento contínuo, ferramentas como Cloudflare Web Analytics, DebugBear e SpeedCurve disparam alertas quando o LCP, INP ou CLS ultrapassam limites definidos. Em projetos que administramos, configuramos alertas separados para cada métrica: o INP é o mais sensível, então o limite de alerta é 180 ms (antes de chegar em 200 ms). O LCP recebe alerta em 2,3 segundos. O CLS dispara em 0,08. Isso dá tempo de corrigir antes que o Search Console marque o site como “Ruim”.

Dashboards personalizados com dados reais

Uma prática que recomendamos é montar um dashboard no Google Looker Studio conectado ao CrUX via BigQuery. Você pode segmentar os dados por país, dispositivo e tipo de página. Em um cliente com tráfego internacional, descobrimos que o INP era 30% pior em dispositivos móveis na Índia comparado ao Brasil. O motivo era o tempo de resposta do servidor de terceiros de anúncios, que tinha data centers distantes. Mudamos a geolocalização das requisições e o INP melhorou 40% no mercado indiano. Sem o dashboard segmentado, esse gargalo nunca seria identificado.

Integração de Core Web Vitals no processo de desenvolvimento

A abordagem mais sustentável é incorporar as métricas no pipeline de CI/CD. Toda vez que um desenvolvedor faz um deploy, as métricas de laboratório devem ser validadas automaticamente. Ferramentas como Lighthouse CI ou Web Vitals API nos testes de integração contínua podem reprovar um build se o LCP ultrapassar 2,5 segundos ou o CLS superar 0,10.

Checklist de revisão de código específico para CWV

• Toda imagem adicionada deve ter width e height explícitos. Sem exceções.
• Qualquer script de terceiro precisa ser auditado quanto ao impacto em INP e LCP antes da inclusão.
• Pop-ups e modais devem usar position: fixed ou position: absolute com container dimensionado.
• Fontes web devem ser servidas com font-display: swap e em formato WOFF2.
• Anúncios e embeds dinâmicos precisam de espaços reservados com altura e largura definidas.

Esse checklist parece simples, mas em projetos com dezenas de desenvolvedores e sprints quinzenais, ele evita que regressões cheguem à produção. Depois de implantar esse processo em um marketplace com 200 mil produtos, o percentual de páginas com CWV “Bom” no Search Console subiu de 34% para 89% em três meses.

Core Web Vitals e SEO local: o que muda

Sites com foco em SEO local também precisam de atenção. O que observamos em clínicas, restaurantes e escritórios de advocacia é que as páginas de contato e de serviço costumam ter LCP alto por causa de embeds de mapas (Google Maps) e formulários de agendamento pesados. A dica aqui é carregar o mapa apenas quando o usuário rolar até ele ou clicar em um botão “Ver no mapa”. O mesmo vale para widgets de redes sociais que puxam feeds. Eles atrasam o LCP e geram CLS. Substitua por links estáticos para o perfil da rede social.

Recursos para aprofundamento

O ecossistema de Core Web Vitals evolui rápido. O Google publica atualizações frequentes no blog de desenvolvedores do Chrome. Além disso, o web.dev tem guias práticos e estudos de caso. O grupo de discussão HTTP Archive também publica análises de tendências que ajudam a entender como o mercado está se adaptando.

Próximos passos

O trabalho nunca termina, mas você já sabe por onde começar. Abra o Search Console, veja quantas URLs estão no grupo “Ruim”, escolha a métrica mais crítica e aplique as correções apresentadas aqui, uma a uma. Acompanhe os dados de campo por 28 dias e repita o ciclo. Cada melhoria incremental se acumula em uma experiência de usuário mais rápida e em uma vantagem competitiva nos resultados de busca.