Performance costuma ser tratada como detalhe técnico, algo para otimizar no fim do projeto, se sobrar tempo. É um erro caro. Site lento perde visitante e ranqueia pior. Os Core Web Vitals colocaram um número nisso, e o número virou decisão de negócio, não detalhe de implementação.
O que os Core Web Vitals medem
São três sinais do Google sobre a experiência real do usuário:
- LCP (Largest Contentful Paint). Tempo até o maior elemento visível aparecer. Bom: até 2,5s.
- INP (Interaction to Next Paint). Quanto a página demora para responder à interação. Bom: até 200ms.
- CLS (Cumulative Layout Shift). O quanto o layout se mexe enquanto carrega. Bom: abaixo de 0,1.
Juntos, traduzem se a página parece rápida, responsiva e estável, do ponto de vista de quem está usando. Não é benchmark sintético, é o que o usuário sente.
Por que isso é dinheiro
Duas razões. A primeira: o Google usa esses sinais como fator de ranqueamento. Performance afeta diretamente quanto tráfego orgânico você recebe. Em mercado competitivo, isso é a diferença entre página 1 e página 3.
A segunda, e mais direta: cada segundo a mais de carregamento derruba conversão. Estudos consistentes mostram quedas significativas de conversão por segundo extra. Em e-commerce, B2B, lead gen, é dinheiro saindo na hora.
Onde sites perdem performance
Os culpados mais comuns:
- Imagens grandes demais. O hero do site num PNG de 4MB. Use formatos modernos (WebP, AVIF), tamanho certo, lazy loading.
- JavaScript desnecessário. Bibliotecas inteiras para uma funcionalidade pequena. Bundle inflado.
- Fontes pesadas e mal carregadas. Várias famílias, vários pesos, sem preload.
- Render bloqueado por scripts de terceiros. Analytics, tag manager, chat widget, que rodam antes de qualquer coisa importante.
- Layout que se monta em camadas. Imagem entra depois e empurra o texto. O usuário começa a ler, o conteúdo pula.
Performance é decisão de origem
Dá para otimizar depois, mas sai caro e nunca chega ao mesmo lugar. Quando a performance é critério desde o projeto (stack certa, imagens otimizadas, pouco JavaScript desnecessário, SSR/SSG no Next.js), ela vem quase de graça.
Esperar o site estar lento para pensar nisso é como deixar para limpar a casa quando ela já está suja faz seis meses. Possível, mas o esforço é desproporcional.
O que medir, e como
O Google PageSpeed Insights mede em laboratório (Lighthouse) e em campo (CrUX, dados reais agregados). Vale olhar os dois: laboratório é mais rápido para iterar, campo é o que conta para ranqueamento.
No produto vivo, vale ter monitoramento contínuo de performance. A página estava bem ontem, hoje regrediu porque alguém adicionou um script: você precisa saber em horas, não em meses.
Teste o seu site agora
Não fique no abstrato. Cole a URL do seu site no nosso analisador e veja onde está. Costuma ter surpresa boa e surpresa ruim.
Use o analisador de SEO gratuito ou veja a definição completa de Core Web Vitals no glossário. Se quiser ajuda para corrigir, conte o seu projeto.
Precisa de algo assim no seu produto?
A engenharia que escreve estes textos é a mesma que constrói. Conte o seu projeto.