Performance deixou de ser "achismo" e virou métrica medível e até fator de ranqueamento no Google. Os Core Web Vitals são o padrão da indústria para responder "esse site é bom de usar?". Saber o que cada um mede, por que piora e como corrigir é parte central do trabalho de sênior.
As três métricas
Os Core Web Vitals atuais medem três experiências distintas: o quão rápido o conteúdo principal aparece, o quão estável é o layout e o quão responsivo é o site à interação.
| Métrica | O que mede | Alvo "bom" |
|---|---|---|
| LCP | Tempo até o maior elemento visível pintar | ≤ 2,5 s |
| CLS | Quanto o layout "pula" sem aviso | ≤ 0,1 |
| INP | Latência da resposta às interações | ≤ 200 ms |
LCP: o conteúdo principal aparece rápido?
O Largest Contentful Paint marca quando o maior elemento (geralmente a imagem do herói ou um bloco de texto) é renderizado. Causas comuns de LCP ruim: servidor lento, CSS/JS bloqueando a renderização, imagens enormes. Correções: priorizar o recurso crítico (fetchpriority="high"), usar CDN, comprimir imagens e evitar fontes que travam o texto.
CLS: o layout fica parado?
O Cumulative Layout Shift mede o pulo visual — aquele momento em que você vai clicar num botão e um anúncio empurra tudo para baixo. As causas clássicas: imagens sem dimensões reservadas, fontes que trocam de tamanho ao carregar, conteúdo injetado acima do que já estava lá. Correção: sempre reserve espaço (width/height ou aspect-ratio nas imagens).
<!-- Reserva espaço → não pula -->
<img src="foto.jpg" width="800" height="600" alt="...">INP: o site responde ao toque?
O Interaction to Next Paint mede quanto tempo entre o clique e a tela responder. INP ruim quase sempre é JavaScript pesado bloqueando a thread principal — o que conecta direto com a renderização e o caminho crítico. Correção: quebrar tarefas longas, adiar trabalho não-urgente e evitar handlers caros no clique.
Carregar menos: splitting, lazy e imagens
A maior alavanca de performance é simplesmente enviar menos código e bytes:
- Code splitting: dividir o bundle por rota, carregando só o necessário para a tela atual.
- Lazy loading: adiar o que está fora da tela —
loading="lazy"em imagens,import()dinâmico para componentes. - Imagens: formatos modernos (WebP/AVIF), tamanhos responsivos (
srcset), compressão.
// Carrega o componente só quando for usado
const Grafico = lazy(() => import('./Grafico'));Análise de bundle e performance percebida
Um bundle analyzer mostra o que está engordando seu pacote — muitas vezes uma biblioteca pesada importada inteira por um único uso. Cortar isso costuma render mais que qualquer micro-otimização.
E há a performance percebida: o usuário sente velocidade, não mede milissegundos. Skeletons em vez de spinners, mostrar conteúdo parcial, feedback instantâneo no clique — tudo faz o site parecer mais rápido mesmo quando os números são parecidos.
A otimização que mais rende quase nunca é deixar o código mais esperto — é não enviar o código que o usuário não precisa agora.
É comum em entrevista de sênior pedir para você citar os Core Web Vitals, seus limiares e como atacaria um LCP ruim. No dia a dia, isso aparece quando o Lighthouse acende vermelho ou o produto reclama que "o site demora a aparecer".
Conclusão
LCP cuida do conteúdo aparecer, CLS da estabilidade visual e INP da responsividade. As alavancas são quase sempre as mesmas: enviar menos (splitting, lazy, imagens otimizadas) e cuidar da percepção. Performance é experiência — e, com ela e a arquitetura sob controle, falta proteger o usuário com segurança.
Performance stopped being guesswork and became a measurable metric — even a ranking factor on Google. The Core Web Vitals are the industry standard for answering "is this site good to use?". Knowing what each one measures, why it gets worse and how to fix it is a central part of a senior's job.
The three metrics
The current Core Web Vitals measure three distinct experiences: how fast the main content appears, how stable the layout is and how responsive the site is to interaction.
| Metric | What it measures | "Good" target |
|---|---|---|
| LCP | Time until the largest visible element paints | ≤ 2.5 s |
| CLS | How much the layout "jumps" without warning | ≤ 0.1 |
| INP | Latency of the response to interactions | ≤ 200 ms |
LCP: does the main content appear fast?
Largest Contentful Paint marks when the largest element (usually the hero image or a text block) is rendered. Common causes of bad LCP: slow server, CSS/JS blocking rendering, huge images. Fixes: prioritize the critical resource (fetchpriority="high"), use a CDN, compress images and avoid fonts that block text.
CLS: does the layout stay put?
Cumulative Layout Shift measures visual jumping — that moment when you go to click a button and an ad pushes everything down. The classic causes: images without reserved dimensions, fonts that change size when loading, content injected above what was already there. Fix: always reserve space (width/height or aspect-ratio on images).
<!-- Reserves space → no jump -->
<img src="foto.jpg" width="800" height="600" alt="...">INP: does the site respond to touch?
Interaction to Next Paint measures how long it takes between the click and the screen responding. Bad INP is almost always heavy JavaScript blocking the main thread — which connects directly to rendering and the critical path. Fix: break up long tasks, defer non-urgent work and avoid expensive click handlers.
Loading less: splitting, lazy loading and images
The biggest performance lever is simply sending less code and fewer bytes:
- Code splitting: split the bundle by route, loading only what's needed for the current screen.
- Lazy loading: defer what's off-screen —
loading="lazy"on images, dynamicimport()for components. - Images: modern formats (WebP/AVIF), responsive sizes (
srcset), compression.
// Loads the component only when it's used
const Grafico = lazy(() => import('./Grafico'));Bundle analysis and perceived performance
A bundle analyzer shows what's fattening your package — often a heavy library imported in full for a single use. Cutting that usually yields more than any micro-optimization.
And then there's perceived performance: users feel speed, they don't measure milliseconds. Skeletons instead of spinners, showing partial content, instant feedback on click — it all makes the site feel faster even when the numbers are similar.
The optimization that pays off most is almost never making the code smarter — it's not shipping the code the user doesn't need right now.
Senior interviews commonly ask you to name the Core Web Vitals, their thresholds and how you'd attack a bad LCP. Day to day, it shows up when Lighthouse lights up red or the product team complains that "the site takes a while to show up".
Conclusion
LCP covers content appearing, CLS visual stability and INP responsiveness. The levers are almost always the same: send less (splitting, lazy loading, optimized images) and take care of perception. Performance is experience — and, with it and the architecture under control, what remains is protecting the user with security.