Core Web Vitals em 2026: O Que Realmente Move o LCP, o INP e o CLS

A maioria das equipes ainda trata o Core Web Vitals como um número do Lighthouse a perseguir, não como uma arquitetura a corrigir. É por isso que um site pode ter nota 95 no PageSpeed Insights e mesmo assim reprovar na avaliação de Core Web Vitals do Google Search Console. Esses dois números medem coisas diferentes, e apenas um deles afeta o ranqueamento e os usuários reais.

Vamos pular o conselho de plugin. Se a sua solução para um problema de performance é "instalar um plugin de cache", você está tratando um sintoma, não a causa. Veja o que realmente move cada métrica, e por que os dados de laboratório e os dados de campo divergem com frequência suficiente para que você não possa confiar em nenhum dos dois isoladamente.

LCP é um problema de caminho crítico, não um problema de imagem

O Largest Contentful Paint mede quando o maior elemento visível — geralmente uma imagem de destaque, um título ou um banner — termina de renderizar. As equipes recorrem por padrão a "comprimir a imagem", o que ajuda, mas raramente é o gargalo a partir de um certo ponto.

O caminho crítico real é este:

1. Time to first byte. Se o seu servidor ou origem leva várias centenas de milissegundos para responder antes de o navegador ter algo com que trabalhar, nenhuma quantidade de compressão de imagem vai salvar você. Renderização na borda (edge), réplicas de leitura regionais e mover rotas sensíveis a TTFB para a camada de computação de uma CDN (Cloudflare Workers, Vercel Edge, Lambda@Edge) podem reduzir esse tempo de forma significativa — o quanto depende muito da sua stack, da região e da linha de base inicial.
2. CSS e JS que bloqueiam a renderização. Cada folha de estilo e script síncrono que o navegador precisa processar antes de poder pintar a tela atrasa o LCP. Coloque o CSS crítico do conteúdo acima da dobra inline e adie o restante.
3. Descoberta de recursos. O preload scanner do navegador precisa encontrar sua imagem de LCP cedo. Se ela for injetada via JavaScript, carregada a partir de um background-image em CSS, ou escondida atrás de uma busca de dados do lado do cliente, você atrasou a descoberta em centenas de milissegundos. Use fetchpriority="high" na tag <img> real e um <link rel="preload"> para ela.
4. Carregamento de fontes. Se o seu elemento de LCP é texto e você está carregando uma web font sem estratégia de fallback, está adicionando um round-trip completo antes que esse texto possa ser pintado. font-display: swap e o preload resolvem metades diferentes desse problema: o swap pinta uma fonte de fallback imediatamente para que o round-trip não bloqueie o LCP (mas pode causar um reflow visível — e um impacto no CLS — quando a fonte real entra em cena), enquanto o preload do próprio arquivo de fonte encurta a busca para que a troca aconteça mais cedo. Use os dois juntos, não um no lugar do outro.

Nada disso é uma configuração de plugin. É roteamento, ordem de marcação e resource hints — decisões tomadas no seu pipeline de build e no seu HTML, não em um painel do WordPress.

INP é o que acontece quando sua arquitetura de JavaScript não escala

O Interaction to Next Paint substituiu o First Input Delay como Core Web Vital em março de 2024, e é uma métrica mais difícil de manipular porque amostra toda interação ao longo de uma visita à página, não apenas a primeira. Um site pode ter um primeiro clique rápido e ainda assim reprovar em INP, porque uma interação posterior, depois que componentes suficientes já montaram e estado suficiente já se acumulou, demora tanto para responder que puxa a nota do p75 para baixo — mesmo que o primeiro clique tenha parecido instantâneo.

O INP é dominado pela disputa pela thread principal (main thread). O navegador não consegue responder a um toque ou tecla pressionada enquanto está ocupado executando JavaScript. As causas mais comuns:

• Long tasks. Qualquer coisa acima de 50ms bloqueia a thread principal de processar entradas. Grandes atualizações de estado, re-renderizações não otimizadas e scripts síncronos de terceiros (widgets de chat, tags de analytics, exchanges de anúncios) são os culpados mais comuns.
• Custo de hidratação. Frameworks pesados no cliente que hidratam a página inteira no carregamento — em vez de fazer isso de forma progressiva ou seletiva — ocupam a thread principal exatamente quando os usuários começam a interagir. A islands architecture (a hidratação seletiva de componentes isolados do Astro) e a resumability (a abordagem do Qwik, que serializa o estado de execução e retoma sem reexecutar a lógica dos componentes) são duas técnicas diferentes que atacam esse mesmo problema, ao lado dos React Server Components. Se você está rodando uma SPA totalmente renderizada no cliente para um site de marketing, o INP costuma ser onde isso aparece primeiro.
• Event handlers não agrupados. Uma única entrada disparando múltiplas re-renderizações síncronas, recálculos de layout ou chamadas de API se acumula rapidamente. Debouncing, requestIdleCallback para tarefas não urgentes e mover processamento pesado para Web Workers ajudam nesse caso.
• Volume de scripts de terceiros. Gerenciadores de tags que carregam uma dúzia de scripts adicionais são um dos maiores destruidores de INP, porque você não controla o custo de execução deles, só se e quando eles carregam.

Code splitting e lazy loading baseado em rotas reduzem o total de JS entregue, mas o INP especificamente recompensa manter a thread principal livre durante as janelas de interação — isso é tanto um problema de agendamento quanto um problema de tamanho de bundle.

CLS ainda é, em grande parte, um problema de disciplina

O Cumulative Layout Shift é o mais fácil de corrigir dos três, e é o único que não tem nada a ver com infraestrutura de servidor. Ele é causado por:

• Imagens e embeds sem width/height explícitos ou aspect-ratio reservado no CSS.
• Web fonts que trocam para um fallback metricamente diferente, deslocando o reflow do texto — mitigue isso com size-adjust em um bloco @font-face ajustado à sua fonte de fallback.
• Anúncios, banners de cookies e conteúdo injetado dinamicamente que empurram o conteúdo existente para baixo depois que o layout inicial já foi pintado.
• Conteúdo inserido acima de conteúdo existente (um erro comum de CMS/personalização — um banner injetado no topo depois do carregamento da página).

Um CLS abaixo de 0,1 é alcançável em praticamente qualquer stack, desde que todo elemento dinâmico tenha espaço reservado. Não existe correção de infraestrutura para um atributo width ausente.

Por que os dados de laboratório e os dados de campo divergem

Essa é a parte que a maioria dos relatórios pula. Os dados de "laboratório" do Lighthouse e do PageSpeed Insights rodam um único carregamento de página em um dispositivo intermediário simulado, com conexão limitada de propósito (throttled), em um estado de cache limpo, sem nenhuma variabilidade real de usuário. É reproduzível, o que o torna útil para testes de regressão — mas é uma fotografia sintética.

Os dados de campo — os que aparecem no relatório de Core Web Vitals do Search Console e no Chrome UX Report (CrUX) — são um agregado móvel de 28 dias no percentil 75, coletado de usuários reais do Chrome, em dispositivos reais, redes reais e estados de cache reais. É isso que o Google de fato usa como sinal de ranqueamento.

Essa diferença aparece de formas previsíveis:

• Mix de dispositivos. Seu teste de laboratório roda em um dispositivo simulado fixo. Seus dados de campo incluem celulares Android de entrada reais em 4G, que sempre mostrarão um INP pior do que um perfil intermediário sintético.
• Variabilidade de terceiros. Testes A/B, plataformas de gestão de consentimento e tags de anúncios frequentemente não disparam do mesmo jeito em um crawl de laboratório (que pode não aceitar cookies, acionar geolocalização ou carregar redes de anúncios específicas de região) como disparam no tráfego real.
• Estado de cache. Testes de laboratório costumam rodar "a frio". Usuários reais acessam o cache da sua CDN, fontes já aquecidas e recursos previamente carregados em visitas repetidas, o que pode fazer as ferramentas de campo mostrarem um resultado melhor do que o laboratório — o inverso do padrão usual.
• Tamanho da amostra e percentil. Uma execução de laboratório é um único ponto de dado. Dados de campo no p75 significam que um quarto das suas visitas reais é pior do que o número que você está vendo — exatamente a cauda que as "soluções rápidas" baseadas em plugin nunca alcançam.

Trate os dados de laboratório como uma barreira de regressão na sua CI, não como um proxy da sua nota real. Trate os dados de campo como a verdade absoluta pela qual você é responsável, e diagnostique-os com monitoramento de usuário real (RUM), não com execuções repetidas do Lighthouse.

O que realmente priorizar

Se você está triando prioridades: corrija o CLS primeiro (mais barato, maior certeza), corrija o LCP em segundo lugar (mudanças de infraestrutura e marcação com números claros de antes/depois), e trate o INP como uma preocupação arquitetural contínua, não como uma correção pontual — ele volta a piorar toda vez que você lança um novo script de terceiros ou uma árvore de componentes mais pesada.

É também por isso que o trabalho de Core Web Vitals pertence a quem escreve e publica o seu código, não a uma checklist de marketing. Nossa equipe de SEO técnico trata performance como um problema de engenharia com um efeito colateral no ranqueamento, não o contrário — porque é assim que a coisa realmente funciona.

Resumindo: as notas de laboratório dizem se você quebrou algo desde ontem. Os dados de campo dizem o que os seus usuários e o Google realmente vivenciaram. Se esses dois números divergirem, confie nos dados de campo — e vá corrigir a arquitetura, não as configurações do plugin.