Gis niet — meet eerst. Traagheid kan afkomstig zijn van de client, het netwerk, de server of de database. Een methodische benadering bepaalt waar de tijd heengaat, en lost vervolgens het grootste bottleneck op in plaats van willekeurig te optimaliseren.
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
Gebruik het browser Network/Performance tabblad en server timing om het totaal in te delen. Een nuttige indeling:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Kijk naar percentielen, niet gemiddelden: p50 (gemiddelde gebruiker) versus p99 (ergste geval). Een snelle p50 met een langzame p99 wijst op incidentele problemen — lock contention, koude caches, een langzame DB replica, of GC pauses — niet op een uniform probleem.
APM tools (traces) tonen precies waar de tijd heengaat binnen een request:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
De trace wijst rechtstreeks naar de oorzaak. Controleer vervolgens recente wijzigingen — een deploy, een ontbrekende index, of 10x datagroei verklaart vaak een plotselinge regressie.
Raden verspilt uren door de verkeerde laag te optimaliseren. Eerst meten, de trage span tracen, en p50 versus p99 bekijken transformeert een vaag "het is traag" in een specifieke, oplosbare oorzaak — en opnieuw meten bewijst dat de fix daadwerkelijk werkt.