Nicht raten — zuerst messen. Langsame Performance kann vom Client, vom Netzwerk, vom Server oder von der Datenbank kommen. Ein methodischer Ansatz findet heraus, wohin die Zeit geht, und behebt dann den größten Beitragstäter, anstatt zufällig zu optimieren.
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
Nutzen Sie den Network/Performance Tab des Browsers und server timing, um die Gesamtzeit aufzuteilen. Eine hilfreiche Aufschlüsselung:
Total 1200ms =
DNS/connect 20ms
server TTFB 900ms ← the bottleneck is server-side
download 80ms
client render 200ms
Achten Sie auf Perzentile, nicht Durchschnitte: p50 (typischer Benutzer) vs p99 (Worst Case). Ein schnelles p50 mit langsamem p99 deutet auf gelegentliche Probleme hin — Lock Contention, kalte Caches, ein langsames DB-Replikat oder GC Pauses — nicht auf ein gleichmäßiges Problem.
APM-Tools (Traces) zeigen genau, wohin die Zeit innerhalb eines Request geht:
GET /orders 950ms
├─ auth check 10ms
├─ SELECT orders 30ms
└─ loop: SELECT user per order 900ms ← N+1 query, the real cause
Das Trace zeigt direkt auf den fehlerhaften Call. Dann überprüfen Sie aktuelle Änderungen — ein Deployment, ein fehlender Index oder 10x Datenwachstum erklären oft eine plötzliche Regression.
Raten verschwendet Stunden damit, die falsche Schicht zu optimieren. Zuerst messen, den langsamen Span verfolgen und p50 vs p99 ansehen verwandelt ein vages "es ist langsam" in eine konkrete, behebbare Ursache — und erneutes Messen beweist, dass die Behebung tatsächlich funktioniert hat.