- Fundamentos: O que é Performance e por que Importa
- Core Web Vitals: LCP, INP e CLS na Prática
- Entrega & Rendering: CDN, Lazy Loading e Estratégias de Render
- JavaScript: Seu Bundle Está Pesado Demais
- CSS: Critical Path e Layout Thrashing
- DevTools: Explorando a Performance no Navegador
- Monitoramento: Medindo o que Importa em Produção
Antes de qualquer otimização, precisamos entender por que performance importa de verdade — não só como boa prática de engenharia, mas como fator direto de receita, retenção e experiência.
"53% dos usuários mobile abandonam um site que leva mais de 3 segundos para carregar." — Google, Think with Google
Esse número não é teórico. A Amazon calculou que cada 100ms de latência extra custava 1% de vendas. O Pinterest reduziu o tempo de carregamento em 40% e viu um aumento de 15% no tráfego orgânico. Performance é produto.
O que é Performance no Frontend?
Performance no frontend é a capacidade de uma aplicação web de responder rapidamente às ações do usuário e apresentar conteúdo útil o mais cedo possível. Não se resume a velocidade bruta — envolve a percepção do usuário sobre essa velocidade.
O que os instrumentos medem: TTFB, FCP, LCP, TBT. São os números brutos do pipeline de carregamento.
O que o usuário sente. Um skeleton loader bem colocado pode fazer 3s parecer mais rápido que 1s em branco.
Bounce rate, conversão, SEO, retenção. Performance ruim tem custo mensurável em todas essas métricas.
Above the Fold
O conteúdo "above the fold" é tudo que o usuário vê antes de rolar a página. É o que precisa carregar primeiro e mais rápido — é a primeira impressão.
Viewport inicial — Above the Fold
Below the Fold — pode carregar com lazy loading
Estilos necessários para a primeira tela devem estar no head via style, não em arquivo externo
A imagem principal do LCP deve ter prioridade máxima de fetch e nunca usar lazy loading
width e height evitam CLS causado por imagens sem tamanho definido
CDN, fontes e APIs usadas no fold devem ter link rel=preconnect no head
Nenhum script síncrono deve bloquear o parser no head para conteúdo above the fold
Métricas que importam
Existem dezenas de métricas de performance. Antes de mergulhar em otimizações, é essencial saber quais medir e por quê. O Google classifica as principais em Core Web Vitals (as que afetam ranking) e métricas de diagnóstico.
Métricas de laboratório (Lighthouse, WebPageTest) são reproduzíveis e boas para debugging. Métricas de campo (CrUX, RUM) refletem usuários reais. Use lab para identificar problemas, field para confirmar impacto real — você precisa das duas.
Por que o usuário abandona?
O impacto de lentidão não é linear — é exponencial. O abandono aumenta drasticamente conforme o tempo sobe:
- 0–1s — Experiência percebida como instantânea
O usuário não percebe latência. Taxa de abandono mínima.
- 1–3s — Atenção mantida, mas expectativa crescente
O usuário aguarda, mas começa a perder o interesse. Cada segundo custa.
- 3–5s — 53% de probabilidade de abandono (mobile)
A maioria dos usuários mobile já foi embora. Alta correlação com bounce rate elevado.
- 5s+ — Queda abrupta de conversão
Usuários que ficam estão frustrados. Core Web Vitals ruins nessa faixa afetam ranking no Search.
O modelo mental certo
Faça sempre estas quatro perguntas antes de qualquer otimização:
1. O que o usuário precisa ver primeiro? Priorize esse conteúdo above de tudo — CSS inline, fetchpriority na imagem, JS diferido.
2. O que posso adiar? Qualquer coisa below the fold, interações secundárias, analytics, chat widgets.
3. O que posso eliminar? Scripts de terceiros desnecessários, CSS não usado, imagens oversized.
4. Como medir o impacto? Defina métricas antes de otimizar, compare depois. Sem baseline, não há como saber se funcionou.
Otimizar sem medir: Você pode gastar horas comprimindo imagens enquanto o verdadeiro problema é um script de terceiro bloqueando o main thread.
Focar só em Lighthouse: O score do Lighthouse em lab pode ser ótimo enquanto usuários mobile em 3G têm experiência ruim. Sempre valide com dados de campo (CrUX, Vercel Speed Insights).
Tratar performance como projeto pontual: Sem monitoramento contínuo, regressões entram silenciosamente a cada PR. Performance precisa de gates no CI/CD.
Ignorar dispositivos reais: Benchmarks em MacBook Pro são 5-10x mais rápidos que dispositivos de entrada. Sempre use CPU throttling ao medir.
No próximo artigo desta série, vamos fundo nos Core Web Vitals — como cada métrica é calculada, o que as move e como reproduzir e debugar problemas reais.
As minhas notas
Selecione um trecho e use Destacar no menu (somente neste aparelho).