Core Web Vitals em 2026: por que INP abaixo de 200ms virou requisito pra ranquear

Um cliente nosso de e-commerce de óculos viu o tráfego orgânico cair 28% num único mês de 2025. Conteúdo intacto, backlinks intactos, nada de penalidade manual.

A causa: INP médio do site subiu pra 412ms depois de uma atualização do tema. Google rebaixou. Em 8 dias depois de a gente corrigir, tráfego voltou.

Esse caso não é exceção. Em 2026, velocidade de site virou requisito — não bônus. Quem tem Core Web Vitals ruim não compete, por melhor que seja o conteúdo.

Esse artigo é o guia completo: o que cada métrica significa, qual o limite que vale, e como corrigir.

O que são Core Web Vitals (rápido)

São 3 métricas que o Google usa pra avaliar experiência real do usuário no site. Diferente de “velocidade de página” antiga, elas medem coisas que o usuário sente:

Métrica	O que mede	Limite ideal
LCP (Largest Contentful Paint)	Quanto tempo até o elemento mais importante aparecer	< 2.5s
INP (Interaction to Next Paint)	Quanto tempo entre o clique e a resposta visual	< 200ms
CLS (Cumulative Layout Shift)	Quanto a tela “pula” durante o carregamento	< 0.1

Se você fica dentro dos 3 limites, está em “Good” no Google. Fora de qualquer um deles, pode ser penalizado no ranking.

Atenção: INP substituiu o FID em março/2024

Antes era FID (First Input Delay) — quanto tempo até a página responder ao primeiro clique. Mas FID era enganoso porque media só o primeiro toque.

INP mede TODOS os cliques durante a sessão — escolhe o pior. É muito mais rigoroso. Sites que passavam no FID começaram a falhar no INP. Daí o “porque meu site caiu de posição sem motivo”.

Por que INP é o grande vilão de 2026

Site moderno tem JavaScript pra tudo: lazy-loading, animações, popups, chat widget, GTM, pixels, integrações.

Cada interação dispara código JS. Se esse código demora pra processar, o usuário clica, e nada acontece visualmente por 300, 400, 600ms. INP captura exatamente isso.

Os 5 vilões mais comuns:

1. Scripts de terceiros pesados

• Pixel Meta (versão antiga sem CAPI)
• GTM com 30 tags
• Chat widget que carrega 800KB
• Hotjar/Crazy Egg sem amostragem
• Plugins de WordPress sem manutenção

2. JavaScript bloqueante no main thread

Loops grandes, processamento pesado feito no fluxo principal sem usar Web Workers.

3. Re-renderização excessiva (React, Vue mal usados)

Componente que re-renderiza em loop ou após cada keystroke.

4. Imagens não otimizadas

Imagem de 4MB que demora pra decodificar trava interação.

5. Hidratação SSR pesada

Site Next.js/Nuxt com hidratação de página inteira em vez de “islands”.

Como medir os 3 (gratuitamente)

1. PageSpeed Insights

🔗 https://pagespeed.web.dev

Cola URL → te dá nota mobile e desktop, com sugestões específicas. Use mobile — Google ranqueia pelo mobile-first.

2. Search Console — relatório de Core Web Vitals

Mostra a média do campo real (CrUX — Chrome User Experience) das últimas 28 dias, com gráfico de evolução.

Esse é o número que conta pro ranking. Não a nota do lab.

3. Chrome DevTools — Performance Insights

Pra debug ao vivo. Abre site em incognito, F12, aba Performance, grava → mostra o que tá travando.

O passo a passo pra corrigir cada métrica

LCP > 2.5s (carregamento lento)

Causas comuns:

• Imagem hero gigante (não otimizada)
• Web fonts bloqueando renderização
• Servidor lento

Correções:

• Imagem hero: serve em WebP ou AVIF, com loading="eager" e fetchpriority="high". Não fica esperando o navegador descobrir.
• Fonts: font-display: swap e preconnect/preload pro CDN da fonte.
• Cache CDN: site servido por CDN (Cloudflare, Vercel, Railway) sempre é mais rápido que servidor único.
• Server-side: se o backend responde lento, otimiza queries SQL, adiciona cache (Redis), reduz processamento síncrono.

Meta: LCP em menos de 2.0s. Acima disso, mesmo dentro do limite, te coloca em borda.

INP > 200ms (interação travada)

Causas comuns:

• Scripts de terceiros (GTM, Hotjar, chat)
• JS pesado no main thread

Correções:

• Audita scripts de terceiros: cada um tem custo. Mantém só os essenciais.
• Carrega com defer ou async: scripts não-críticos não devem bloquear render.
• Adia GTM: usa container “deferred” pra carregar GTM só após interação inicial.
• Web Workers: processamento pesado vai pra worker, não trava UI.
• Code splitting: framework moderno (Astro, Next.js, Remix) divide JS por rota. Carrega só o necessário.
• Hidratação parcial: Astro “islands” são o padrão ouro aqui — só JS de componentes interativos é hidratado.

Caso real: cliente nosso reduziu INP de 412ms pra 87ms só removendo 3 scripts de tracking duplicados que estavam no GTM.

CLS > 0.1 (layout pula)

Causas comuns:

• Imagens sem width e height declarados
• Web fonts trocando dimensão
• Ads/embeds que aparecem depois e empurram conteúdo

Correções:

• Toda <img> tem width e height: sempre. Mesmo as responsivas.
• Reserva espaço pra ads/embeds: aspect-ratio no container antes do conteúdo carregar
• Web fonts com fallback similar: use font-display: optional ou ajusta fallback pra não pular
• Skeleton screens em vez de spinners: reserva espaço visual do conteúdo que vem

CLS é o mais fácil de corrigir tecnicamente — quase sempre é só pôr width/height em imagens.

Stack de site rápido em 2026

Pra negócios começando hoje, o conjunto que entrega Core Web Vitals “Good” sem esforço:

• Frontend: Astro (SSG) ou Next.js (com cuidado) — não use SPAs pesadas (CRA, Vue SPA puro) pra site público
• CDN: Cloudflare, Vercel, Railway com static — qualquer um global
• Imagens: Astro Image, Next Image, ou Cloudinary com otimização automática
• Fonts: Google Fonts com display=swap, ou self-hosted via fontsource
• Analytics: Plausible/Umami/Cloudflare Analytics (não pesa) em vez de GA4 + GTM

Esse setup nasce com LCP < 1.5s, INP < 100ms, CLS < 0.05. Sem otimização.

O que pesa hoje, e quanto cada coisa custa

Item	Impacto em INP	Tempo de fix
GTM com >15 tags	+100-300ms	1 dia
Pixel Meta antigo (sem CAPI)	+50-100ms	4 horas
Plugin WP desatualizado	+50-500ms	2-8 horas
Chat widget pesado	+100-200ms	2 horas (trocar)
React Native Web não otimizado	+200-400ms	1-2 semanas
Imagem hero 4MB não otimizada	+50ms (INP) +2s (LCP)	1 hora
Web fonts sem display:swap	+100ms (INP) +500ms (LCP)	30 min

A maioria dos sites brasileiros tem 3-5 desses problemas. Corrigir 2-3 já tira o site da zona vermelha.

Plano de 14 dias pra entrar no Good

Dia 1-2: Diagnóstico

• PageSpeed Insights mobile da home + 5 páginas principais
• Search Console → relatório Core Web Vitals
• Anota a pior métrica de cada página

Dia 3-5: Quick wins

• Comprime e converte imagens pra WebP/AVIF
• Adiciona width/height em toda imagem
• Adiciona loading="lazy" em imagens abaixo da dobra
• Adiciona font-display: swap

Dia 6-10: Scripts

• Audita scripts no GTM. Remove os que ninguém usa.
• Migra Pixel Meta pra CAPI (server-side)
• Substitui chat widget pesado por alternativa leve (Crisp, Intercom moderno)

Dia 11-14: Validação

• Roda PageSpeed novamente
• Aguarda 7 dias pro Search Console refletir
• Mede CTR e posição média do orgânico antes/depois

Em 1 mês, ganhos típicos: +15% de tráfego orgânico só com Core Web Vitals.

A regra de ouro

Site rápido vende mais. Não só por SEO — por taxa de conversão.

Cada 100ms de latência cortados = ~1% de aumento em conversão (estudo Cloudflare 2025). 500ms de melhoria = 5% mais venda, sem mexer em nada de marketing.

E o melhor: enquanto sua concorrência ainda discute “vale a pena otimizar?”, você já está colhendo posição. Velocidade é a vantagem competitiva mais barata que existe hoje.

---

Faz um audit completo de Core Web Vitals + plano de correção? A gente tem template. Fala com a gente.