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

Resumo: Core Web Vitals são três métricas que o Google usa para descrever a experiência de usuários reais: Largest Contentful Paint (LCP, carregamento, bom em 2,5 s ou menos), Interaction to Next Paint (INP, responsividade, bom em 200 ms ou menos) e Cumulative Layout Shift (CLS, estabilidade visual, bom em 0,1 ou menos). Cada uma é avaliada no percentil 75 das visitas reais no Chrome ao longo de 28 dias, separadamente para mobile e desktop. O Google diz que elas são usadas por seus sistemas de ranqueamento, mas a relevância vem primeiro. Para corrigi-las, divida cada métrica em suas partes e resolva primeiro a maior.

A maioria dos conselhos sobre Core Web Vitals é uma lista de cinquenta dicas. Por isso as equipes gastam uma sprint com "performance" e veem os números quase não se mexerem. As métricas são mais estruturadas do que isso: cada uma pode ser dividida em poucas partes mensuráveis, e geralmente uma delas responde pela maior parte do problema.

Este guia mostra o que as três métricas medem, os limites em outubro de 2026, em qual fonte de dados confiar, o que o Google realmente diz sobre ranqueamento e um roteiro de correção, começando pelo diagnóstico, para cada métrica, com base na documentação do próprio Google no web.dev.

O que os Core Web Vitals medem

Segundo a visão geral de Web Vitals do web.dev, o conjunto atual e estável tem três métricas:

Os limites coincidem com a tabela de About PageSpeed Insights.

A regra do percentil 75

O Google não avalia uma página pela média nem por um único teste. O web.dev diz que um bom limite a medir é "o percentil 75 dos carregamentos de página, segmentado entre dispositivos móveis e desktop". Em outras palavras: pelo menos três em cada quatro visitas reais precisam atingir o limite "bom". Para passar, a página precisa de um resultado bom no percentil 75 nas três métricas.

Isso traz duas consequências que muita gente ignora:

1. Mobile e desktop são separados. Uma página pode estar boa no desktop e ruim no mobile. O mobile costuma ser o mais difícil, porque os celulares têm CPUs e redes mais lentas.
2. Seus visitantes mais lentos decidem o resultado. Se um quarto dos seus visitantes usa Androids antigos em conexões fracas, a experiência deles é a sua nota. Testar num notebook novo com o Wi-Fi do escritório diz muito pouco.

O INP substituiu o FID em 2024

O Interaction to Next Paint substituiu o First Input Delay (FID) como Core Web Vital em 12 de março de 2024. O FID media apenas o atraso antes de o navegador começar a tratar a primeira interação. O INP cobre cliques, toques e teclas pressionadas durante toda a visita, e todo o tempo até o próximo frame ser renderizado. Muitos sites que passavam fácil no FID falham no INP, porque a parte lenta sempre foi o trabalho depois da primeira interação, que o FID nunca contava. Se você ainda vê FID em um relatório ou plugin antigo, ignore.

O web.dev também observa que os Core Web Vitals estáveis "não mudarão mais de uma vez por ano" e que novas métricas candidatas ficam em fase pendente por pelo menos seis meses, então você é avisado antes de as regras mudarem.

Dados de campo vs. dados de laboratório

Existem dois tipos de dados de performance, e confundi-los é o motivo mais comum de as equipes corrigirem a coisa errada.

Alguns detalhes da documentação do Google:

• O CrUX é uma média móvel de 28 dias, atualizada diariamente, segundo a documentação da CrUX API. Pode ser consultado para uma origem inteira ou para uma única URL, e filtrado por celular, desktop ou tablet.
• O PageSpeed Insights mostra os dois. A seção de campo usa os 28 dias anteriores de dados do CrUX. Se uma URL tem poucas visitas, ele recorre aos dados da origem inteira; se a origem é pequena demais, não há dados de campo (About PageSpeed Insights). A seção de laboratório e a nota de 0 a 100 vêm do Lighthouse.
• O Lighthouse não consegue medir o INP. O web.dev afirma que ferramentas que carregam páginas "em um ambiente simulado sem usuário não conseguem medir o INP" e sugere o Total Blocking Time (TBT) como aproximação em laboratório.
• O relatório de Core Web Vitals do Search Console agrupa páginas com experiências parecidas e atribui a cada grupo o status da sua métrica mais lenta para aquele tipo de dispositivo. Ele usa dados do CrUX dos últimos 28 dias (ajuda do relatório de Core Web Vitals).

A regra prática: os dados de campo decidem se você tem um problema; os dados de laboratório ajudam a achar a causa. Uma nota 98 no Lighthouse com LCP ruim em campo significa que seus usuários reais têm uma experiência pior que a da simulação, muitas vezes por causa de dispositivos lentos, anúncios, personalização ou scripts de terceiros que o teste de laboratório não aciona.

Quanto os Core Web Vitals importam para o ranqueamento

A documentação de experiência da página do Google é clara dos dois lados:

• "Os Core Web Vitals são usados pelos nossos sistemas de ranqueamento", e o Google recomenda obter bons Core Web Vitals "para ter sucesso na Busca".
• "Não existe um sinal único" de experiência da página; os principais sistemas de ranqueamento analisam uma variedade de sinais.
• "A Busca do Google sempre procura mostrar o conteúdo mais relevante, mesmo que a experiência da página seja ruim."
• Bons resultados no Search Console ou em ferramentas de terceiros não garantem que suas páginas ficarão no topo.
• "Tentar obter uma nota perfeita só por motivos de SEO pode não ser o melhor uso do seu tempo."

Nossa leitura: os Core Web Vitals não vão colocar uma página irrelevante acima de uma relevante, mas podem pesar entre páginas de qualidade parecida, e importam diretamente para os usuários. Uma página de produto que leva cinco segundos para mostrar a foto, ou um botão "Comprar" que trava por meio segundo, perde clientes independentemente da posição. Mire em "bom" nas três, depois pare de perseguir pontos e volte ao conteúdo.

Passo 1: descubra qual métrica falha e onde

Antes de mudar o código:

1. Abra o relatório de Core Web Vitals do Search Console, começando pelo mobile. Anote qual métrica falha e quais grupos de URLs são afetados (páginas de produto, posts do blog, a home).
2. Escolha uma URL representativa por grupo com problema e rode no PageSpeed Insights. Verifique se os dados de campo são da URL ou da origem.
3. Corrija um template por vez. Problemas de Core Web Vitals quase sempre são problemas de template: todas as páginas de produto compartilham o mesmo componente de imagem, os mesmos scripts e o mesmo layout.

Nossa verificador de Core Web Vitals gratuito dá uma primeira leitura rápida sem cadastro: ele busca no CrUX o LCP, o INP e o CLS no percentil 75 para visitantes em celular (da página informada, quando o Chrome tem dados suficientes, ou da origem inteira), e mede o tempo de resposta do servidor, o tamanho do HTML, a compressão, os scripts que bloqueiam a renderização no head da página e os formatos de imagem dessa página, por padrão a sua home.

Passo 2: corrija o LCP pelas suas quatro subpartes

O LCP é o tempo até a maior imagem ou bloco de texto da viewport ser renderizado. Os elementos elegíveis incluem <img>, <video>, elementos com imagem de fundo CSS via url() e texto em nível de bloco (LCP no web.dev). Na maioria das páginas de produto e de destino, é a imagem principal (hero).

O guia Optimize LCP divide o LCP em quatro partes que somam o total:

O web.dev chama essas proporções de "diretrizes, não regras rígidas", mas elas são muito úteis para o diagnóstico. O painel Performance do Chrome DevTools mostra a divisão de um carregamento gravado. A parte que estiver muito acima da sua participação é por onde você começa.

TTFB alto

O TTFB inclui redirecionamentos, configuração da conexão e processamento no servidor. O guia de TTFB do web.dev sugere 0,8 segundo ou menos como meta aproximada, observando que o TTFB não é um Core Web Vital.

• Sirva o HTML por uma CDN e faça cache na borda, mesmo que por pouco tempo. As maneiras mais eficazes de melhorar os Core Web Vitals apontam a CDN como a melhor forma de reduzir o TTFB.
• Elimine cadeias de redirecionamento, inclusive as de links de anúncios e links encurtados.
• Fique atento a parâmetros de URL únicos (de analytics ou campanhas) que fazem cada requisição ser um cache miss.
• Analise consultas lentas ao banco de dados e a renderização no servidor no template da página.

Atraso de carregamento do recurso alto

Muitas vezes é a maior subparte e geralmente a mais barata de corrigir. O navegador poderia ter iniciado o download da imagem antes, mas não sabia que ela existia.

• Coloque a imagem do LCP no HTML inicial como um <img src> ou srcset normal. Imagens inseridas por JavaScript, ou que usam data-src para uma biblioteca de lazy loading, são descobertas tarde.
• Nunca faça lazy loading da imagem do LCP. Remova loading="lazy" da imagem hero; o web.dev diz sem rodeios: "nunca faça lazy loading da sua imagem do LCP".
• Adicione fetchpriority="high" à imagem do LCP, e a no máximo uma ou duas imagens.
• Se a imagem for um fundo CSS, faça preload com <link rel="preload"> e prioridade de busca alta, ou troque por um <img>.
• Sirva as imagens críticas da mesma origem do HTML sempre que possível, para reaproveitar a conexão.

Duração do carregamento do recurso alta

• Sirva a imagem no tamanho em que ela é exibida, com srcset e sizes, para que celulares não baixem uma imagem de desktop.
• Use formatos modernos como AVIF ou WebP e comprima adequadamente.
• Use uma CDN de imagens que redimensiona e converte automaticamente.
• Reduza outros downloads de alta prioridade que competem pela banda ao mesmo tempo.

Atraso de renderização do elemento alto

A imagem chegou, mas algo impede o navegador de renderizá-la:

• CSS que bloqueia a renderização: reduza, adie estilos não críticos e faça inline apenas de um CSS crítico bem pequeno.
• Scripts síncronos no <head>: adicione async ou defer.
• Renderização no cliente: se o conteúdo da página só aparece depois que um framework JavaScript é executado, prefira renderização no servidor ou prerendering.
• Scripts de teste A/B ou personalização que escondem a página até decidirem qual variante mostrar.
• Tarefas longas de JavaScript rodando no momento em que a imagem fica pronta.

Se o LCP é um bloco de texto e não uma imagem, o atraso e a duração de carregamento do recurso são zero, e o problema está no TTFB, em recursos que bloqueiam a renderização ou nas web fonts.

Passo 3: corrija o INP pelas suas três fases

O INP registra cliques, toques e teclas pressionadas durante toda a visita (não rolagem nem hover) e informa a interação mais lenta, ignorando um valor atípico a cada 50 interações (INP no web.dev). Cada interação tem três fases:

O problema de fundo quase sempre são as tarefas longas: qualquer tarefa que leve mais de 50 milissegundos na thread principal. Enquanto uma tarefa longa roda, o navegador não consegue responder ao usuário.

Reduza o atraso de entrada

• Carregue menos JavaScript na inicialização; a avaliação de scripts cria tarefas longas justamente quando os usuários tentam tocar pela primeira vez.
• Faça uma auditoria do seu gerenciador de tags. O web.dev observa que "tags antigas com código não utilizado podem ser removidas". Widgets de chat, mapas de calor, testes A/B e scripts de anúncios costumam executar trabalho pesado na thread principal.
• Use a ferramenta Coverage do Chrome e code splitting para parar de enviar código que a página não usa.

Reduza a duração do processamento

• Faça menos no manipulador de evento. Atualize primeiro o que o usuário precisa ver e adie o resto (chamadas de analytics, salvar estado, recalcular recomendações).
• Ceda a thread principal entre blocos de trabalho. await scheduler.yield() continua o trabalho restante em uma nova tarefa priorizada. Não é suportado em todos os navegadores, então o web.dev sugere usar como alternativa um setTimeout envolvido em uma Promise (Optimize long tasks).
• Evite layout thrashing: ler valores de layout (como offsetHeight) logo após alterar estilos na mesma tarefa obriga o navegador a calcular o layout de forma síncrona. Agrupe leituras e escritas.

Reduza o atraso de apresentação

• Mantenha o DOM pequeno. Optimize INP explica que o trabalho de renderização cresce com o tamanho do DOM.
• Use content-visibility para pular a renderização de seções fora da tela, como avaliações longas ou rodapés.
• Evite renderizar grandes blocos de HTML em JavaScript em resposta a um clique; renderize apenas o necessário.

Para encontrar a interação lenta, olhe primeiro os dados de usuários reais (quais páginas falham) e depois reproduza no Chrome DevTools: grave um trace de Performance clicando no elemento suspeito com a CPU limitada (throttling) e procure tarefas longas depois do clique.

Passo 4: corrija o CLS causa por causa

O CLS soma as mudanças de layout inesperadas. Cada mudança recebe como nota a fração da viewport que se moveu multiplicada pela distância percorrida, as mudanças são agrupadas em janelas de até cinco segundos e o CLS é a pior janela (CLS no web.dev). Mudanças até 500 ms depois de um clique, toque ou tecla pressionada são excluídas, porque o usuário as esperava. A rolagem não conta como interação, então o conteúdo que muda enquanto alguém rola continua contando.

Segundo Optimize CLS, as causas e correções mais comuns:

Duas observações da prática:

• Espaço que some também causa mudança. O web.dev alerta que remover espaço reservado "pode causar tanto CLS quanto inserir conteúdo". Se um espaço de anúncio ficar vazio, mantenha o placeholder.
• Banners de cookies e barras promocionais são culpados frequentes. Sobreponha-os ao conteúdo em vez de empurrar a página para baixo.

Não se esqueça do back/forward cache

Quando o usuário clica em Voltar, uma página restaurada do bfcache aparece instantaneamente, sem novas mudanças de layout de carregamento. O web.dev classifica a elegibilidade ao bfcache como uma técnica muito eficaz para manter o CLS baixo. Os dois bloqueadores mais comuns, segundo o guia de bfcache do web.dev: listeners do evento unload (use pagehide no lugar) e o cabeçalho Cache-Control: no-store em páginas que não contêm dados sensíveis. O Chrome DevTools tem um teste em Application › Back/forward cache.

Um exemplo prático (números hipotéticos)

O exemplo a seguir é hipotético, não são dados reais. A Fernwood Home, uma loja online de móveis inventada, está reprovada na avaliação de Core Web Vitals no mobile para o template de página de produto. Os valores de campo no percentil 75:

LCP: 4,6 s

Um trace no DevTools com perfil de celular limitado mostra que o elemento do LCP é a foto principal do produto. A divisão:

O atraso de carregamento do recurso está mais de três vezes acima da participação-alvo, então ele vem primeiro. As correções: renderizar a primeira foto como um <img> simples no HTML do servidor, remover o loading="lazy" dela, adicionar fetchpriority="high", servir AVIF e WebP em tamanhos de celular via srcset, fazer cache do HTML na CDN ignorando os parâmetros de rastreamento na chave de cache e carregar o script de A/B com defer.

Resultado em laboratório após o lançamento: TTFB 0,7 s, atraso de carregamento 0,2 s, duração do carregamento 0,6 s, atraso de renderização 0,3 s, resultando em um LCP de 1,8 s.

INP: 340 ms

Os dados de campo apontam para a página de produto; reproduzindo no DevTools, a interação lenta é o botão "Adicionar ao carrinho". O trace mostra cerca de 90 ms de atraso de entrada (um widget de chat e duas tags de rastreamento rodando ao mesmo tempo), 190 ms de processamento (o manipulador renderiza de novo todo o painel do carrinho e envia três chamadas de analytics de forma síncrona) e 60 ms de atraso de apresentação.

As correções: carregar o widget de chat só depois da primeira interação do usuário, mostrar primeiro a atualização do painel do carrinho e ceder a thread antes das atualizações de analytics e de recomendações. Medição em laboratório no mesmo perfil limitado: cerca de 150 ms.

CLS: 0,21

Três causas: um widget de estrelas de avaliação inserido acima do preço depois do carregamento, uma troca de web font que reorganiza as quebras de linha do título do produto e miniaturas sem dimensões. As correções: reservar a altura do widget de avaliações, fazer preload da fonte do título e ajustar o fallback com size-adjust, adicionar width e height a cada miniatura. CLS em laboratório: 0,04.

Lendo o resultado

Os números de laboratório confirmam que as correções funcionam. Os números de campo, que decidem a avaliação, se movem à medida que novas visitas substituem as antigas na janela de 28 dias. A Fernwood deve esperar uma mudança gradual ao longo de cerca de quatro semanas e então clicar em Start tracking no relatório do Search Console para iniciar a validação, que também dura 28 dias. Se o LCP de campo ficar em, digamos, 2,3 s em vez de 1,8 s, isso é normal: celulares e redes reais são mais lentos que qualquer perfil de laboratório.

Erros comuns

• Perseguir a nota do Lighthouse. A nota de 0 a 100 é um resumo de laboratório. A avaliação do Google usa dados de campo no percentil 75.
• Testar só no desktop. O mobile é avaliado separadamente e normalmente falha primeiro.
• Fazer lazy loading de tudo. Lazy loading de imagens abaixo da dobra é bom; lazy loading da imagem hero é uma das causas mais comuns de LCP ruim.
• Corrigir só a home. A maior parte do tráfego muitas vezes cai em templates de produto, categoria ou artigo. Corrija os templates com mais URLs reprovadas.
• Adicionar mais um script. Cada tag, widget e script de teste disputa a thread principal. Remova um para cada um que adicionar.
• Esperar resultados instantâneos. Os dados de campo levam cerca de 28 dias para refletir totalmente um lançamento.
• Ignorar o básico do mobile. Uma página sem a tag viewport ou com imagens grandes demais é lenta em celulares antes de qualquer otimização. O teste de compatibilidade com dispositivos móveis gratuito verifica esses pontos básicos.

Um checklist inicial de uma hora

1. Passe seu domínio pelo verificador de Core Web Vitals gratuito para ver LCP, INP e CLS de usuários reais em celulares, além do tempo de resposta do servidor, da compressão e dos scripts bloqueantes.
2. Abra o relatório de Core Web Vitals do Search Console para mobile e liste os grupos de URLs reprovados.
3. Para cada grupo reprovado, rode uma URL no PageSpeed Insights e anote qual métrica falha em campo.
4. Para o LCP, grave um trace no DevTools e anote as quatro subpartes. Corrija primeiro a maior.
5. Para o INP, encontre a interação lenta e as tarefas longas depois dela.
6. Para o CLS, verifique imagens sem dimensões, conteúdo injetado tarde e fontes.
7. Publique, confirme em laboratório e depois verifique os dados de campo após duas e quatro semanas.

Os Core Web Vitals são uma parte da saúde técnica do site. Nosso guia de auditoria de SEO técnico os coloca em contexto com rastreamento, indexação, redirecionamentos e dados estruturados.

Como o Searvia ajuda com os Core Web Vitals

O verificador de Core Web Vitals gratuito não exige cadastro e mostra, em menos de um minuto, o panorama de usuários reais do seu site. Dentro do Searvia, a aba Page speed de um projeto de site roda o PageSpeed Insights nas suas páginas mais visitadas toda semana e mostra tanto as notas de laboratório quanto os dados de usuários reais do Chrome para LCP, INP e CLS dos últimos 28 dias. As correções são ordenadas pelo tempo que economizam, e Write a fix plan for my files with AI transforma os principais itens em mudanças passo a passo para a sua stack (3 créditos). Conecte o Search Console para ver cliques e posições ao lado da velocidade e saber se um template mais rápido realmente trouxe mais tráfego. O guia de ajuda sobre velocidade da página explica a configuração em cerca de dois minutos.