Non indovinare — misura prima. La lentezza può provenire dal client, dalla rete, dal server o dal database. Un approccio metodico trova dove va il tempo, quindi corregge il contributore più importante invece di ottimizzare a caso.
Non indovinare — misura prima. La lentezza può provenire dal client, dalla rete, dal server o dal database. Un approccio metodico trova dove va il tempo, quindi corregge il contributore più importante invece di ottimizzare a caso.
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
Usa la scheda Network/Performance del browser e il timing del server per dividere il totale. Una suddivisione utile:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Guarda i percentili, non le medie: p50 (utente tipico) vs p99 (caso peggiore). Un p50 veloce con un p99 lento punta a problemi occasionali — contesa di lock, cache fredde, una replica DB lenta, o pause GC — non un problema uniforme.
Gli strumenti APM (trace) mostrano esattamente dove va il tempo all'interno di una richiesta:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
La trace punta direttamente alla chiamata offensiva. Poi controlla i cambiamenti recenti — un deploy, un indice mancante, o una crescita dati di 10x spesso spiega una regressione improvvisa.
Indovinare spreca ore ottimizzando il livello sbagliato. Misurare prima, tracciare l'intervallo lento e guardare p50 vs p99 trasforma un vago "è lento" in una causa specifica e risolvibile — e misurare di nuovo prova che la correzione ha effettivamente funzionato.