Performance14 de março de 2026~9 min de leitura

Core Web Vitals em 2026: o que mudou e como atingir nota máxima

INP substituiu FID, LCP ficou mais rigoroso. Um guia prático e direto para entender o que o Google mede hoje e como passar no exame com nota máxima.

Core Web Vitals são o conjunto de métricas de experiência do usuário que o Google usa como fator de ranking. Desde 2021 fazem parte do Page Experience Signal, e desde 2024 passaram por uma atualização significativa que pegou muitos sites de surpresa.

Se você não revisou sua performance desde antes de 2024, provavelmente está perdendo posições sem saber o motivo. Este artigo desmonta cada métrica atual, explica os thresholds que importam e entrega um checklist prático para atingir "Good" em todas elas.

As três métricas que o Google mede hoje

Os Core Web Vitals atuais são LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). O FID (First Input Delay) foi aposentado em março de 2024 e substituído pelo INP, que é uma medição muito mais completa da interatividade.

LCP — Largest Contentful Paint

LCP mede quanto tempo leva para o maior elemento visível na viewport ser renderizado. Na prática, costuma ser a imagem principal do hero, um título grande ou um bloco de texto em destaque.

Bom: LCP ≤ 2,5 segundos
Precisa melhorar: entre 2,5 e 4,0 segundos
Ruim: LCP > 4,0 segundos

Os principais culpados de LCP ruim são: imagens sem lazy loading adequado, fontes bloqueantes, CSS crítico não inlineado e servidores lentos (TTFB alto). A sequência de otimização: primeiro resolva o TTFB com CDN ou SSR, depois otimize a imagem do LCP com preload e formato moderno (AVIF ou WebP), por fim garanta que o CSS crítico seja inlineado no HTML.

Adicione fetchpriority="high" na imagem do elemento LCP. Essa única mudança de atributo pode reduzir o LCP em 20–40% em sites com imagens no hero.

INP — Interaction to Next Paint

INP é a métrica mais nova e, para muitos sites, a mais difícil de otimizar. Ela mede a latência de todas as interações do usuário ao longo da visita (cliques, teclado, toque) e reporta o percentil 98 — ou seja, quase a pior interação que aconteceu.

Bom: INP ≤ 200ms
Precisa melhorar: entre 200ms e 500ms
Ruim: INP > 500ms

Diferente do FID, que media apenas a primeira interação, o INP captura o comportamento real da página durante toda a sessão. Um site pode ter FID excelente e INP terrível se, por exemplo, uma lista com muitos itens trava ao ser filtrada.

As principais causas de INP alto são: JavaScript pesado no thread principal, event handlers síncronos que bloqueiam a renderização, renderizações desnecessárias em frameworks React/Vue/Angular e uso excessivo de localStorage síncrono.

Use o Chrome DevTools Performance panel > Interactions para identificar quais interações estão lentas.
Quebre tarefas longas com scheduler.yield() ou setTimeout(..., 0).
Mova processamento pesado para Web Workers.
No React: use useDeferredValue e Transitions para manter a UI responsiva durante atualizações de estado.
Audite third-party scripts — Google Tag Manager mal configurado é um dos maiores assassinos de INP.

CLS — Cumulative Layout Shift

CLS mede a estabilidade visual: quanto o layout se mexe de forma inesperada durante o carregamento. Um banner que aparece e empurra o texto para baixo, uma imagem sem dimensões definidas que expande o layout — tudo isso contribui para o CLS.

Bom: CLS ≤ 0,1
Precisa melhorar: entre 0,1 e 0,25
Ruim: CLS > 0,25

A correção mais impactante é definir width e height explicitamente em todas as imagens e usar aspect-ratio no CSS para vídeos e iframes. Para fontes, use font-display: swap e precarregue as fontes críticas no <head> com <link rel="preload">.

Checklist prático para nota máxima

TTFB < 800ms: use CDN com edge nodes, habilite HTTP/3, comprima respostas com Brotli.
Imagem do LCP: AVIF ou WebP, fetchpriority="high", sem lazy loading, preload no <head>.
Fontes: preconnect + preload, font-display: swap, subsets reduzidos.
CSS crítico: inline no <head>, resto carregado de forma assíncrona.
JavaScript: code splitting, tree shaking, defer/async em scripts não críticos.
INP: audite event handlers, quebre tarefas longas, avalie impacto de third-party scripts.
CLS: width/height em todas as imagens, aspect-ratio em mídia, evite inserção dinâmica de conteúdo acima do fold.
Meça com dados reais: use o CrUX (Chrome User Experience Report) e PageSpeed Insights, não apenas Lighthouse local.

Lighthouse mede em condições de laboratório. O Google rankeia com base em dados de campo (CrUX). Um site pode ter Lighthouse 100 e CrUX medíocre se os usuários reais tiverem dispositivos mais lentos ou conexões piores.

A mentalidade certa sobre performance

Performance não é um projeto que termina — é uma propriedade que se degrada com o tempo à medida que features são adicionadas, scripts de terceiros são instalados e o conteúdo cresce. A única forma de manter nota máxima é monitorar continuamente e tratar regressões de performance com a mesma urgência que bugs de produção.

Quer um site que gera resultado de verdade?

Aplicamos tudo isso — e muito mais — nos projetos que construímos para nossos clientes.

Solicitar orçamento