Melhorar Core Web Vitals em 2026 exige diagnóstico específico por métrica, não otimização genérica. LCP (Largest Contentful Paint, alvo ≤2,5s) é dominado por imagem do hero e font loading; fix está em otimização de imagem (formato AVIF/WebP, tamanho correto, priority hint), self-host de fonte e preload. INP (Interaction to Next Paint, alvo ≤200ms, substituiu FID em mar/2024) é JavaScript bloqueante; fix está em code splitting, lazy load de tracking de terceiros, web workers. CLS (Cumulative Layout Shift, alvo ≤0,1) é elementos que deslocam conteúdo durante carregamento; fix está em reservar espaço pra imagem, banner e cookie consent.
A Huios é agência de desenvolvimento; otimizamos performance pra clientes em Next.js, WordPress e React. Conflito de interesse declarado: vendemos serviço de otimização técnica. Honestidade técnica acima do interesse comercial.
Para o panorama mais amplo (checklist completo por stack, score esperado, ROI), leia como aprovar no PageSpeed mobile. Este post é o fix técnico por métrica.
Os 3 Core Web Vitals que importam
Core Web Vitals oficiais Google em 2026:
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP | Tempo até o maior elemento visível carregar | ≤ 2,5s | 2,5–4s | > 4s |
| INP | Latência da interação mais lenta | ≤ 200ms | 200–500ms | > 500ms |
| CLS | Quanto layout se mexe durante carregamento | ≤ 0,1 | 0,1–0,25 | > 0,25 |
INP substituiu FID em março/2024. Sites otimizados pra FID podem reprovar em INP por medirem coisas diferentes (FID era o primeiro input; INP é o pior input em toda sessão).
Como medir o que importa (CrUX, não Lighthouse)
Antes de otimizar, certifique-se de que está medindo a coisa certa:
- Lighthouse / PageSpeed Insights (lab data): simulação controlada. Útil pra detectar issues técnicos. NÃO entra no ranking do Google.
- CrUX (Chrome User Experience Report) / Field data: dados reais de usuários Chrome nos últimos 28 dias. É o que rankeia.
Como Annie Sullivan, líder do projeto CrUX no Google, descreveu em 2024: "Lab data is great for catching issues. Field data is what matters for ranking."
Acesse field data em:
- PageSpeed Insights — mostra CrUX se o site tem ≥ ~10k pageviews/mês
- CrUX Dashboard no Looker Studio — relatório histórico
- Vercel Speed Insights ou SpeedCurve — em tempo real e segmentado
- Google Search Console → Experience → Core Web Vitals
Fixes pra LCP > 2,5s
LCP em mobile é dominado por imagem do hero em ~70% dos casos observados em 80+ auditorias Huios em 2024-2026.
Causa 1: imagem hero não otimizada (mais comum)
Fix Next.js 16:
import Image from 'next/image';
<Image
src="/hero.webp"
alt="..."
width={1200}
height={630}
priority
fetchPriority="high"
sizes="(max-width: 768px) 100vw, 1200px"
/>
Pontos críticos: priority no hero (não em todas as imagens — só na que aparece acima da dobra), fetchPriority="high", formato WebP ou AVIF, largura real ≤ 1200px pra mobile (não 1920px).
Fix WordPress: plugin Imagify ou ShortPixel converte pra WebP/AVIF automaticamente. Lazy load nativo do WP 5.5+ deve ser removido do hero (porque hero precisa carregar imediato).
Fix React/Vite genérico: react-lazy-load-image-component com effect="opacity" e fetchPriority="high" no hero.
Causa 2: fonte web carregando lentamente
Fix Next.js 16:
import { Inter } from 'next/font/google';
const inter = Inter({
subsets: ['latin'],
display: 'swap',
});
next/font faz self-host + preload automaticamente.
Fix WordPress: Local Fonts plugin self-hosta Google Fonts e adiciona <link rel="preload">. Limitar a 2 famílias × 3 weights máximo (cada peso adicional = ~30KB).
Causa 3: CSS bloqueante no head
Fix: Critical CSS inline no <head> + resto async via <link rel="preload" as="style" onload="this.rel='stylesheet'">. Em Next.js, o framework faz isso automaticamente. Em WordPress, WP-Rocket ou LiteSpeed Cache com "Optimize CSS Delivery" ativo.
Causa 4: server response time > 600ms (TTFB ruim)
Fix: hospedagem decente (Vercel, Cloudflare, AWS edge) + cache de página (HTML cache em CDN, edge functions). Sites em hospedagem compartilhada barata raramente atingem TTFB ≤ 200ms — vale migrar.
Fixes pra INP > 200ms
INP mede a latência da interação mais lenta em toda sessão. Em ~80% dos casos, JavaScript bloqueante é o culpado.
Causa 1: bibliotecas grandes carregando síncronas
Fix: code splitting agressivo. Em Next.js:
import dynamic from 'next/dynamic';
const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
ssr: false,
loading: () => <Skeleton />,
});
Em React/Vite genérico: React.lazy + Suspense. Bibliotecas que mais quebram INP em projetos Huios: Recharts, react-quill, react-pdf, Three.js, Framer Motion (versões antigas).
Causa 2: tracking de terceiros bloqueante
Fix Next.js 16:
import Script from 'next/script';
<Script
src="https://www.googletagmanager.com/gtag/js?id=G-XXX"
strategy="lazyOnload"
/>
strategy="lazyOnload" faz GA, Pixel, Hotjar, Clarity carregarem após o site interativo. Pra economizar ainda mais, considere tracking server-side via Stape ou GTM Server-side — tira ~300KB de JS do cliente.
Fix WordPress: Flying Scripts ou WP-Rocket com "Delay JavaScript Execution" ativo.
Causa 3: long tasks no main thread
Fix: identificar via Chrome DevTools Performance → Long Tasks. Tasks > 50ms são problemas. Mover trabalho pesado pra:
- Web Workers (Comlink facilita) — bom pra processamento custom
requestIdleCallbackpra trabalho não-crítico- Server-side quando possível (Server Components em Next.js)
Causa 4: framework com hydration custosa
Fix: se Hydration mismatch warnings aparecem no console, corrigir antes — eles dobram o trabalho do React durante hidratação. Em Next.js 16, prefira Server Components pra UI estática (sem JS no cliente).
Fixes pra CLS > 0,1
CLS é deslocamento de conteúdo durante carregamento — frustrante pro usuário e penaliza ranking.
Causa 1: imagem sem dimensões explícitas
Fix: SEMPRE definir width e height no HTML. Browser reserva o espaço antes da imagem chegar.
<img src="/foto.jpg" alt="..." width="800" height="600" />
Em Next.js, <Image> exige width/height por padrão (ou fill em container relative).
Causa 2: banner de cookie / aviso pushing conteúdo
Fix: banner deve ser position: fixed sobre o conteúdo, NÃO empurrar conteúdo. Bibliotecas como Cookiebot e OneTrust configuradas em modo "no layout shift".
Causa 3: anúncio carregando em slot variável
Fix: reservar altura mínima pro slot de anúncio com min-height. Mesmo se anúncio não carregar, espaço fica:
.ad-slot {
min-height: 250px; /* tamanho mínimo do banner */
}
Causa 4: web font causando layout shift (FOIT/FOUT)
Fix: font-display: swap + ajustar size-adjust, ascent-override pra fonte fallback ter métricas próximas da web font.
@font-face {
font-family: 'Inter';
font-display: swap;
size-adjust: 107%; /* ajustar pra match com fallback */
}
Em Next.js, next/font faz isso automaticamente.
Causa 5: elemento aparecendo após interação do usuário (modal, tooltip)
Fix: usar position: absolute ou position: fixed pro elemento dinâmico. Layout shift causado por interação direta do usuário não conta pro CLS (window de exclusão de 500ms após input). Mas se o elemento aparece sem input, conta.
Ordem de prioridade pra fix
Em 80+ auditorias Huios, essa ordem maximiza ganho por hora investida:
- LCP image (1-2h fix, ganho típico: -1 a -2 segundos no LCP)
- JavaScript de tracking lazy (30-60min, ganho típico: -100 a -300ms no INP)
- CSS reserve de banner cookie + imagem (1-2h, ganho típico: CLS de 0,3 pra 0,05)
- Code splitting de biblioteca pesada (2-4h por biblioteca, ganho típico: -50 a -200ms no INP)
- Self-host de fonte com next/font (30min em Next.js, 2-4h em WordPress, ganho típico: -200 a -500ms no LCP)
Se você tem 4 horas pra otimizar 1 site, foque em LCP image + JS lazy + CSS reserve. Esses 3 fixes resolvem ~80% dos sites em 2026.
Como medir antes/depois
Após cada fix, meça em CrUX (não só Lighthouse):
- PageSpeed Insights: rodar antes do fix, salvar URL com data
- Aplicar fix
- Rodar novamente após 14-28 dias (CrUX usa janela de 28 dias)
- Comparar p75 (percentil 75 — métrica oficial do Google)
Importante: mudança no site demora 1-2 semanas pra aparecer no CrUX. Quem mede só Lighthouse e celebra "score 95" pode ter CrUX ruim em produção.
Erros que NÃO valem corrigir (ROI negativo)
Lighthouse aponta dezenas de "issues". Nem todos importam:
- "Serve images in next-gen formats" se você já está em WebP — alerta pra AVIF é marginal (~1 ponto)
- "Reduce JavaScript execution time" abaixo de 200ms — abaixo disso, ganho imperceptível
- "Use HTTP/2" se você está em Vercel/Cloudflare — já está em HTTP/3
- "Eliminate render-blocking resources" quando o resource bloqueante é o CSS principal (não dá pra eliminar, só otimizar)
A regra: se o issue não está em vermelho/laranja no Lighthouse, frequentemente não vale o esforço.
Tempo realista de otimização
Em 80+ otimizações Huios em 2024-2026:
| Estado inicial → meta | Tempo realista |
|---|---|
| Score Lighthouse 50-65 → 85+ mobile | 12-25h de trabalho técnico |
| Score 70-80 → 90+ mobile | 8-15h de trabalho |
| Score 85+ → 95+ mobile | 4-10h (rendimento decrescente) |
| Score < 50 → 80+ mobile | Frequentemente migrar plataforma é mais barato que otimizar |
Sites em Wix com score < 60: o caminho mais curto pra 80+ é migrar pra Next.js, não otimizar Wix.
Perguntas frequentes
O que é considerado um bom Core Web Vitals?
LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1 nos dados de campo (CrUX). Esses são os limites oficiais do Google. Acima desses limites, o site é considerado "precisa melhorar" ou "ruim" e perde sinal de ranqueamento.
LCP, INP e CLS — qual é o mais importante?
Os 3 são considerados sinais de ranking. Mas em ~70% dos sites em 2026, LCP é o que mais reprova (imagem hero pesada). INP é o segundo mais comum (JS de tracking). CLS é o que entrega ROI mais rápido após fix (mudanças visíveis pro usuário). Comece pelo que está em vermelho.
Por que Lighthouse mostra score 95 mas CrUX mostra ruim?
Lighthouse simula em rede 4G slow + CPU throttled 4×. Usuários reais podem estar em conexão pior. CrUX mede usuários reais nos últimos 28 dias — esse é o que rankeia. Otimize Lighthouse pra atingir CrUX bom, não o contrário.
INP substituiu FID — meu site otimizado pra FID reprova em INP?
Pode reprovar. FID media só o primeiro input. INP mede o pior input em toda sessão. Sites com long tasks ocasionais (chart pesado, autocomplete, etc) passavam em FID e reprovam em INP. Audite via Chrome DevTools Performance → Long Tasks.
Qual ferramenta uso pra medir Core Web Vitals?
PageSpeed Insights (lab + field), Vercel Speed Insights (field em tempo real), SpeedCurve (segmentado), Google Search Console → Experience (alertas de queda). Use 2-3 em conjunto pra ter visão completa.
Vale a pena otimizar pra score 100?
Não pra SEO. Acima de 90 mobile, ganho marginal em ranking é zero. Excepção: ecommerce de alto ticket onde 100ms de LCP a mais reduz conversão em ~1% (estudo Google/Deloitte 2020). Aí vale otimizar até o último décimo.
Posso atingir Core Web Vitals bom em WordPress?
Sim, mas exige stack disciplinada: hospedagem decente (Kinsta, WP Engine, Cloudways), WP-Rocket ou LiteSpeed Cache, plugin de imagem WebP/AVIF, CDN, tema leve (GeneratePress, Astra), < 25 plugins ativos. Em projetos Huios, WordPress otimizado atinge LCP 2,8s mediano em mobile; Next.js no mesmo nicho atinge 1,9s.
Próximos passos
Para checklist completo por stack (Next.js, WordPress, Wix) com erros comuns que custam 20-40 pontos, leia como aprovar no PageSpeed mobile — post-pai deste spoke técnico.
Pra entender contexto de SEO mais amplo (Modo IA, GEO, performance), leia Modo IA do Google no Brasil.
Se você está construindo do zero e quer Next.js com performance correta desde o primeiro commit, criar site com IA cobre quais ferramentas geram código que passa em PageSpeed (v0, Lovable) e quais não.
Fontes e dados: "80+ auditorias Huios em 2024-2026" são dados internos do nosso time técnico. Limites oficiais e definições conforme web.dev/articles/vitals. Estudo "100ms de LCP reduz conversão em ~1%" do Google/Deloitte Milliseconds Make Millions, 2020.
Publicado em 30 de abril de 2026 · Por Equipe Huios
