Otimização de Performance

Visão Geral

Meça antes de otimizar. Trabalho de performance sem medição é adivinhação — e adivinhação leva à otimização prematura que adiciona complexidade sem melhorar o que importa. Faça o profiling primeiro, identifique o gargalo real, corrija-o, meça novamente. Otimize apenas o que as medições provam que importa.

Quando Usar

• Requisitos de performance existem na especificação (orçamentos de tempo de carregamento, SLAs de tempo de resposta)
• Usuários ou monitoramento relatam comportamento lento
• Pontuações dos Core Web Vitals estão abaixo dos limites
• Você suspeita que uma mudança introduziu uma regressão
• Construindo funcionalidades que lidam com grandes conjuntos de dados ou alto tráfego

Quando NÃO usar: Não otimize antes de ter evidências de um problema. Otimização prematura adiciona complexidade que custa mais do que a performance que ela ganha.

Metas dos Core Web Vitals

O Fluxo de Trabalho de Otimização

1. MEASURE  → Establish baseline with real data
2. IDENTIFY → Find the actual bottleneck (not assumed)
3. FIX      → Address the specific bottleneck
4. VERIFY   → Measure again; keep or revert
5. GUARD    → Add monitoring or tests to prevent regression

Passo 1: Medir

Duas abordagens complementares — use ambas:

• Sintética (Lighthouse, aba Performance do DevTools): Condições controladas, reproduzível. Melhor para detecção de regressão em CI e isolamento de problemas específicos.
• RUM (biblioteca web-vitals, CrUX): Dados de usuários reais em condições reais. Necessário para validar que uma correção realmente melhorou a experiência do usuário.

Frontend:

// Synthetic: Lighthouse in Chrome DevTools (or CI)
// Chrome DevTools → Performance tab → Record
// Chrome DevTools MCP → Performance trace

// RUM: Web Vitals library in code
import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(console.log);
onINP(console.log);
onCLS(console.log);

Backend:

// Response time logging
// Application Performance Monitoring (APM)
// Database query logging with timing

// Simple timing
console.time('db-query');
const result = await db.query(...);
console.timeEnd('db-query');

Onde Começar a Medir

Use o sintoma para decidir o que medir primeiro:

What is slow?
├── First page load
│   ├── Large bundle? --> Measure bundle size, check code splitting
│   ├── Slow server response? --> Measure TTFB in DevTools Network waterfall
│   │   ├── DNS long? --> Add dns-prefetch / preconnect for known origins
│   │   ├── TCP/TLS long? --> Enable HTTP/2, check edge deployment, keep-alive
│   │   └── Waiting (server) long? --> Profile backend, check queries and caching
│   └── Render-blocking resources? --> Check network waterfall for CSS/JS blocking
├── Interaction feels sluggish
│   ├── UI freezes on click? --> Profile main thread, look for long tasks (>50ms)
│   ├── Form input lag? --> Check re-renders, controlled component overhead
│   └── Animation jank? --> Check layout thrashing, forced reflows
├── Page after navigation
│   ├── Data loading? --> Measure API response times, check for waterfalls
│   └── Client rendering? --> Profile component render time, check for N+1 fetches
└── Backend / API
    ├── Single endpoint slow? --> Profile database queries, check indexes
    ├── All endpoints slow? --> Check connection pool, memory, CPU
    └── Intermittent slowness? --> Check for lock contention, GC pauses, external deps

Passo 2: Identificar o Gargalo

Gargalos comuns por categoria:

Frontend:

Backend:

…