Velocidade não é nota em ferramenta, é caixa no fim do mês. Este guia traduz LCP, INP e CLS para dinheiro, mostra as metas oficiais sem tecnês e entrega um checklist que roda em uma tarde, com código Next.js pronto e uma frase por item para você cobrar do seu dev sem precisar decorar sigla.
Minha posição depois de 20 anos entre design e código: performance é faturamento, não vaidade técnica. Cada item abaixo tem camada dupla, explicação curta para o dono e prova técnica para o dev, porque site rápido que ninguém mede volta a ficar lento em três meses.
Key Takeaways
- Cada segundo a mais de carregamento derruba cerca de 7% da conversão; melhorias de 100 ms no LCP rendem 1 a 2% de conversão (Google, via Visie e F. Souza, 2026).
- Sites com LCP abaixo de 2,5s têm rejeição 24% menor; CLS zerado contra 0,25 decide até 15% da conversão no checkout (Google, via Visie e F. Souza, 2026).
- 87% dos sites falham em pelo menos uma das três métricas no Chrome UX Report (via Visie, 2026); as metas são LCP abaixo de 2,5s, INP abaixo de 200ms e CLS abaixo de 0,1.
- INP substituiu o FID em março de 2024 e o Google ranqueia por dados de campo de 28 dias, não pelo teste de laboratório.
Quanto a lentidão custa em dinheiro?
Cada segundo a mais de carregamento reduz a conversão em cerca de 7% no e-commerce, e cada 100 ms ganhos no LCP devolvem de 1 a 2% de conversão em média (Google, via Visie e F. Souza, 2026). Sites com LCP abaixo de 2,5s registram rejeição 24% menor que sites acima de 4s, e a diferença entre CLS zerado e CLS em 0,25 pode decidir até 15% da conversão no checkout. Com 87% dos sites falhando em pelo menos uma métrica no Chrome UX Report (via Visie, 2026), estar no verde já é vantagem competitiva.
Pense em conta simples: loja com 10 mil visitas e ticket de R$200 não precisa de mais tráfego para faturar mais, precisa parar de perder os 7% de cada segundo.
Quanto maior o LCP, menor a conversão relativa, pela regra dos 7% por segundo.
Para o plano completo de site que converte, volte ao guia pilar site que vende todo dia.
As 3 metas oficiais, em português claro
Os limites da faixa boa são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. A avaliação usa o percentil 75 das visitas, separado entre celular e desktop; uma execução de laboratório não comprova aprovação em campo. Consulte as definições oficiais dos Web Vitals. O INP substituiu o FID em março de 2024 e considera as interações durante a visita. Em páginas com muitas interações, o cálculo pode descartar valores extremos: não é sempre o pior evento isolado. Veja a metodologia do INP. O CrUX agrega dados reais em uma janela móvel de 28 dias; esses sinais de experiência não garantem posição na busca.
87% falham em pelo menos 1 métrica no campo, por isso o verde converte.
LCP abaixo de 2,5s: imagem e fonte decidem o jogo
O LCP quase sempre é imagem do hero ou título gigante com fonte web. No Next.js, isso significa next/image com priority e sizes corretos mais next/font com display: swap e subset, além de preload só no recurso crítico.
O que pedir ao dev: "hero com next/image prioritário em WebP ou AVIF, fonte sem shift e preload só do crítico."
// Hero com LCP otimizado: prioridade + dimensão + formato moderno
import Image from 'next/image';
import hero from '@/public/hero-loja.webp';
export function Hero() {
return (
<Image
src={hero}
alt="Vitrine da loja com oferta principal em destaque"
priority
sizes="(max-width: 768px) 100vw, 1200px"
placeholder="blur"
/>
);
}
// Fonte sem shift de layout: swap + subset latino
import { Inter } from 'next/font/google';
export const inter = Inter({
subsets: ['latin'],
display: 'swap',
preload: true,
});
INP abaixo de 200ms: o site precisa reagir na hora
O INP mede a pior resposta a toques e cliques na visita, então o vilão típico é JavaScript de terceiro mais handler pesado na thread principal: chat, pixel e banner que carregam junto com a página e disputam CPU com o clique no botão comprar. A correção é adiar o que não é crítico com next/script em modo lazy e manter o handler do clique magro.
O que pedir ao dev: "terceiros com lazy, clique com handler leve e medição de INP em produção."
// Terceiro sem travar o clique: carrega depois da interação
import Script from 'next/script';
export function ThirdParty() {
return (
<Script
src="https://cdn.exemplo.com/chat.js"
strategy="lazyOnload"
/>
);
}
// Mede Web Vitals em produção e envia para seu endpoint
import { onINP, onLCP, onCLS } from 'web-vitals';
export function reportWebVitals() {
onINP((m) => navigator.sendBeacon('/api/vitals', JSON.stringify(m)));
onLCP((m) => navigator.sendBeacon('/api/vitals', JSON.stringify(m)));
onCLS((m) => navigator.sendBeacon('/api/vitals', JSON.stringify(m)));
}
Nota de escopo honesta: next/image otimiza entrega de imagem, não divide socket de rede por si só; standalone com NFT reduz o que vai para o servidor. Ganho real vem de menos JS na thread, não de flag isolada.
CLS abaixo de 0,1: nada pode pular na tela
CLS é soma de susto: imagem sem dimensão que empurra texto, anúncio que abre espaço do nada e fonte que troca e quebra linha. A correção é reservar espaço para tudo que carrega depois: width e height ou aspect-ratio em imagem e vídeo, esqueleto com altura fixa para anúncio e embed, e fonte com métrica estável.
O que pedir ao dev: "todo bloco dinâmico nasce com altura reservada e imagem com proporção fixa."
/* Reserva de espaço: o layout não mexe quando a mídia chega */
.media-16x9 {
aspect-ratio: 16 / 9;
width: 100%;
background: #0f172a0d;
overflow: hidden;
}
.anuncio-300 {
min-height: 250px;
}
Checklist executável em 1 tarde + rotina semanal
Rode nesta ordem e marque pronto só com critério cumprido: imagens do hero com dimensão e WebP ou AVIF (pronto quando o LCP de lab cai e o hero tem priority), fontes com swap e subset sem shift visível em reload com cache limpo, terceiros com defer ou lazy e nada de chat bloqueando o primeiro clique, espaço reservado para imagem, anúncio e embed (pronto quando o CLS de lab fica abaixo de 0,1), preload só do crítico validado no waterfall, e monitoramento semanal no Search Console com alerta de URL que sai do verde. Campo manda: lab bom com campo vermelho significa usuário real com rede e CPU piores que as suas.
Prova honesta do meu portfólio: Lighthouse de lab marca 100 no desktop e cerca de 79 no mobile com CPU throttled, e o campo tende a ficar acima do lab porque o First Load da home gira em torno de 118 kB com LCP em texto (medição própria do autor, lab com throttle declarado, 2026). Não vendo print perfeito, vendo método repetível.
Complete a base técnica com a migração Next.js 16 e o motion que não mata performance.
Perguntas frequentes
Lighthouse 100 mas campo vermelho, por quê?
Porque lab e campo medem coisas diferentes: lab roda sua página uma vez em ambiente controlado, campo agrega usuários reais por 28 dias no Chrome UX Report, com rede fraca e celular simples no meio. Terceiros que pesam só em horário de pico, anúncio que muda por visita e CPU fraca explicam a diferença. Confie no campo para ranqueamento e use o lab para depurar.
next/image resolve o LCP sozinho?
Não. Ele entrega dimensão, formato moderno e lazy certo, o que resolve metade do problema, mas não salva hero com imagem de 3 MB, fonte que empurra layout nem servidor lento. LCP verde pede imagem leve mais fonte estável mais resposta rápida juntas, e o priority só no hero, nunca em galeria inteira.
Com que frequência devo medir?
Toda semana no Search Console, com olhar por template (home, categoria, produto, checkout) em vez de média do site. Deploy grande com imagem nova ou script novo pede medição de lab antes de publicar e checagem de campo 28 dias depois. Rotina pequena evita reforma grande.
Conclusão
- 1 segundo a mais derruba cerca de 7%; 100 ms no LCP devolvem 1 a 2% (Google via Visie e F. Souza, 2026).
- Metas: LCP abaixo de 2,5s, INP abaixo de 200ms, CLS abaixo de 0,1; INP vale desde março de 2024 no lugar do FID.
- 87% falham em pelo menos 1 métrica no campo (CrUX via Visie, 2026). Verde já é diferencial.
- Checklist de 1 tarde mais Search Console semanal segura o verde melhor que reforma anual.