Não adivinhe — meça primeiro. A lentidão pode vir do cliente, da rede, do servidor ou do banco de dados. Uma abordagem metódica encontra para onde o tempo vai e, em seguida, corrige o maior contribuidor em vez de otimizar aleatoriamente.
Não adivinhe — meça primeiro. A lentidão pode vir do cliente, da rede, do servidor ou do banco de dados. Uma abordagem metódica encontra para onde o tempo vai e, em seguida, corrige o maior contribuidor em vez de otimizar aleatoriamente.
1. MEASURE → where is the time spent? client render, network, server, DB?
2. REPRODUCE → confirm it reliably (same endpoint, payload, user)
3. TRACE → use APM/distributed traces to find the slow span
4. CHECK RECENT CHANGES → deploys, config, traffic, data growth
5. ISOLATE → layer by layer, narrow to one component
6. FIX the biggest contributor → re-measure to confirm
Use a aba Network/Performance do navegador e timing do servidor para dividir o total. Uma divisão útil:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Olhe para percentis, não médias: p50 (usuário típico) vs p99 (pior caso). Um p50 rápido com um p99 lento aponta para problemas ocasionais — contenção de lock, caches frios, uma réplica de BD lenta ou pausas de GC — não um problema uniforme.
Ferramentas APM (traces) mostram exatamente para onde o tempo vai dentro de uma solicitação:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
O rastreamento aponta diretamente para a chamada culpada. Em seguida, verifique as mudanças recentes — uma implantação, um índice ausente ou um crescimento de dados 10x frequentemente explicam uma regressão repentina.
Adivinhar desperdiça horas otimizando a camada errada. Medir primeiro, rastrear o span lento e olhar para p50 vs p99 transforma um vago "está lento" em uma causa específica e corrigível — e remedir prova que a correção realmente funcionou.