Voltar ao blog
Performance

Core Web Vitals em 2026: o que mudou e o que importa

Por Flávio Emanuel · · 8 min de leitura

2024 foi quando Google enterrou FID. Morreu de vez. INP é o novo rei das métricas de interatividade.

Peguei cliente em 2025 que ainda media FID. Falei: cara, aquela métrica é obsoleta. Ele achou que eu tava maluco.

2026 chegou, Google derrubou site dele no ranking porque INP era ruim. Aí ele entendeu.

O que é INP (Interaction to Next Paint)

FID era simples demais. Só media o delay inicial de resposta. Um clique, esperava a página responder.

INP mede todas as interações que o usuário faz. Clica button, arrasta slider, digita input. Tudo conta. Pega o pior caso durante a sessão do usuário.

Tipo assim: você tá navegando página. Clica botão de filtro, página trava 300ms. Depois clica abas do produto, trava 150ms. Clica add to cart, trava 50ms. INP pega aquele pior caso de 300ms.

Por isso que é mais fiel ao que usuário realmente sente. Não é só primeira interação. É experiência inteira.

Qual é o target de 2026?

INP: menos de 200ms. Acima de 200ms, Google avisa que tá ruim. Acima de 500ms, é realmente crítico.

LCP: menos de 2.5 segundos. Isso não mudou. Continua sendo a métrica mais importante. Se seu LCP é ruim, ninguém clica.

CLS: menos de 0.1. Aquele número sem unidade é score de instabilidade visual. Quanto menor, melhor. 0.1 é bom, 0.25 é ruim.

Na prática, a maioria das páginas que vejo tá com CLS ok. O problema mesmo é INP.

Field data vs lab data

Aqui é crítico entender a diferença.

Field data é real. É usuário real, no celular real, em rede real. Google pega isso do CrUX (Chrome User Experience Report). Cada navegação, cada clique, cada medição vira dado.

Lab data é sua máquina. Você roda teste no seu notebook, Lighthouse diz que tá tudo certo. Mas aí usuário real carrega no 4G e vira outra história.

Google usa field data pra ranquear. Lighthouse usa lab data pra diagnosticar.

Então você tem que medir os dois. Seu site pode ter INP perfeito no Lighthouse e péssimo no CrUX. Significa que problema não é código, é rede ou dispositivo do usuário real.

Como medir de verdade

Entrar em Search Console, aba “Core Web Vitals”. Google mostra exatamente qual é a situação real do seu site baseado no CrUX.

Se tá verde, parabéns. Se tá vermelho, precisa trabalhar.

Depois você usa Lighthouse pra diagnosticar. Roda auditoria, vê onde tá problema. Geralmente é:

Pra LCP: imagem de hero muito grande. Solução? Lazy load, responsive image, WebP format.

Pra INP: JavaScript pesado fazendo trabalho na thread principal. Event listeners rodando todo render. Solução? Defer scripts, web workers, throttle.

Pra CLS: layout shifts de fontes carregando, anúncios se alocando. Solução? Font display: swap, aspect ratio reservado, skeleton states.

Exemplo prático

Tem projeto que fiz com Astro pra consultório odontológico. Primeira medição, INP era 450ms. LCP tava 3.2s.

Aí fui no CrUX do Search Console. Vi que problema era mesmo em field data. Não era eu sendo ruim no diagnóstico.

Passos que fiz:

  1. Removi JavaScript desnecessário. Tinha plugin de chat que rodava na home. Movia pra drawer quando usuário abria.

  2. Implementei route prefetching com Astro Islands. Quando usuário pairava em link, já carregava dados.

  3. Otimizei imagens. Hero era 400kb. Convertei pra WebP, responsivo, deu 80kb.

Resultado: INP caiu pra 120ms, LCP pra 1.8s. Ranking melhorou.

Real user monitoring

O mais profissional é implementar Web Vitals API e enviar dados de verdade.

import { getCLS, getFID, getFCP, getLCP, getTTFB } from 'web-vitals';

function handleMetric(metric) {
  fetch('/api/vitals', {
    method: 'POST',
    body: JSON.stringify(metric),
  });
}

getCLS(handleMetric);
getLCP(handleMetric);
getTTFB(handleMetric);

Pega dados reais dos usuários e joga pra servidor. Depois você analisa tendências.

Vi muita gente usando Vercel Analytics. R$ 12/mês e já dá tudo pronto. Não precisa implementar de mão.

Performance é negócio

Não é só vanidade. Site mais rápido: melhor ranking, mais cliques, mais conversão.

Eu coloquei em proposta pra cliente agora: “Vou entregar site com INP menor que 150ms e LCP menor que 2s.” Cliente entende que isso é diferencial.

Com SEO técnico pra devs, falei dessa importância. Core Web Vitals é a base.

2026 é ano que performance virou não-negociável. Google tá séria. Site lento não ranqueia.

  • Verificar Core Web Vitals no Search Console
  • Rodar Lighthouse auditoria completa
  • Identificar onde INP tá acima de 200ms
  • Remover JavaScript desnecessário
  • Otimizar imagens hero em WebP
  • Implementar Real User Monitoring
  • Acompanhar CrUX mensalmente

Web Vitals boas é combustível pra crescimento.

Comparação 2024 vs 2026

2024 Google ainda tava morno com CLS. 2026 ficou bem claro: INP é o que importa.

Mudança porque usuário moderno tá acostumado com apps. Expectativa é: eu clico, coisa acontece em 200ms ou menos. Se site demora 500ms pra responder, usuario sente que site tá lento.

Desktop vs Mobile, qual sofre mais? Mobile. Site mesmo em desktop pode ter INP bom, em 4G fica ruim. Google prioriza field data de celular. Se seu site não ranqueia em mobile, problema é provavelmente Core Web Vitals em rede lenta.

INP em sites complexos

Vi muito dev achando que site simples não tem problema com INP. Errado. Site de consultório com agendador interativo? INP pode ser ruim.

Problema nem sempre é código pesado. Pode ser:

  1. Muitos event listeners disparando em render
  2. Blocos long tasks (>50ms de trabalho na main thread)
  3. Muito layout recalc por animações
  4. Trabalho síncrono em grande array

Solução? Profiler do browser. DevTools > Performance tab. Roda com throttling mobile e aí vê onde tá o gargalo.

Exemplo: site com 50 links que tinham hover effect com animação. Cada hover, browser recalculava 200ms. INP era 220ms. Removi animação, INP caiu pro 80ms. Simples.

LCP: imagem hero

Se LCP tá acima de 3s, problema é quase sempre imagem hero.

Antes: imagem de 2MB JPEG carregando no começo.

Depois: mesma imagem, mas convertida pra WebP (80KB), lazy loading na primeira, inline da versão pequena enquanto carrega a grande.

LCP: 3.2s → 1.5s.

Ferramenta que uso? ImageOptim pra desktop, Squoosh online. Converte pra WebP, redimensiona pra responsive. Depois coloco direto no Astro com componente <Image />.

CLS invisível

CLS tá invisível quando é bom. Significa página não tá se mexendo.

Problema clássico: fonte carregando e mudando tamanho. Solução: font-display: swap e aspect-ratio reservado em container.

Outro: anúncios se alocando. Solução: space reservado antes de anúncio carregar.

Terceiro: conteúdo carregando. Skeleton screens funcionam. Você coloca um “fake” do conteúdo enquanto carrega real. Zero shift.

Monitoramento contínuo

One-time audit não funciona. Você arruma, deixa passar 3 meses, problema volta porque alguém adicionou novo script ruim.

Recomendo: rodar Search Console Core Web Vitals todo mês. Se ver queda, mexe no site. Com Vercel Analytics você pode exportar dados e analisar tendências.

Vi dev que automatiza isso: cron job que roda Lighthouse todo dia, salva resultado, tá sempre acompanhando.

Sinal de ranking vs razão de ranking

Importante diferenciar: Core Web Vitals é sinal de ranking, não é razão de ranking.

Significa: Google usa como fator. Mas conteúdo ruim com Web Vitals perfeito não ranqueia. Conteúdo bom com Web Vitals ruim ranqueia menos.

Pensa como: Web Vitals é entrada pro jogo. Precisa passar do mínimo pra competir, mas só isso não ganha.

Ferramenta debugar: PageSpeed Insights

Esqueçam o Lighthouse puro. PageSpeed Insights é mais bonito e mostra field data real do seu site.

Vai em pagespeed.web.dev, cola URL, vê tudo. Mostra o que Google tá vendo realmente, não o que seu notebook tá vendo.

Dica: colocar URL de staging antes de deploy. Se Web Vitals tá vermelho, não faz deploy.

Roadmap 2026: o que vem aí

Google mencionou que está considerando adicionar métrica de latência de input. Tipo: quanto tempo demora pra responder após o clique. INP já cobre isso, mas pode ser mais específico.

Recomendação: se seu site tem INP bom agora, vai estar preparado.

  • Rodar PageSpeed Insights em 10 URLs principais
  • Identificar qual métrica tá abaixo do target
  • Usar Profiler pra encontrar gargalo exato
  • Implementar fix (imagem, script, animation)
  • Verificar melhora em PageSpeed
  • Configurar monitoramento mensal
  • Testar em rede lenta (throttle no DevTools)

Performance em 2026 virou não-negociável. Cliente paga por isso agora.

Próximo passo

Precisa de um dev que entrega de verdade?

Seja pra um projeto pontual, reforço no time, ou parceria de longo prazo. Vamos conversar.

Falar no WhatsApp

Respondo em até 2h durante horário comercial.