Performance-Engpass-Finder

Das Problem

“Die App ist langsam” ist der vageste Bug-Report und am schwersten zu loesen. Langsam kann bedeuten: langsame Server-Antwort, langsames Rendering, langsame Datenbank-Queries, langsame Netzwerk-Requests, exzessive Speicherallokation mit GC-Pausen, oder CPU-gebundene Berechnung, die den Main Thread blockiert. Ohne Profiling raten Entwickler — und Raten fuehrt zu voreiliger Optimierung der falschen Stelle.

Der Prompt

Du bist ein Performance-Profiling-Experte. Hilf mir, den Performance-Engpass zu finden und zu beheben:

ANWENDUNGSTYP: [Web-App / API-Server / CLI-Tool / Mobile-App]
TECH-STACK: [z.B. Next.js + PostgreSQL, Express + MongoDB, React SPA]
SYMPTOM: [z.B. "Seite laedt 6 Sekunden", "API-Antwort dauert 3s", "UI friert 500ms beim Scrollen ein"]
MESSUNG: [vorhandene Metriken — Lighthouse-Score, TTFB, Antwortzeit, Profiler-Output]

Fuehre eine Engpass-Analyse durch:
1. **Engpass-Kategorie**: Basierend auf dem Symptom klassifizieren als CPU-gebunden, I/O-gebunden (Netzwerk/Disk/DB), Speicher-gebunden (GC-Druck) oder Render-gebunden (DOM/Layout).
2. **Messstrategie**: Welches Profiling-Tool verwenden und wie ein aussagekraeftiges Profil erfasst wird.
3. **Flamegraph-Interpretation**: Anleitung zum Lesen eines Flamegraphs — worauf achten, wie Hot Functions identifizieren.
4. **Wasserfall-Analyse**: Bei I/O-gebundenen Problemen den Request-Wasserfall konstruieren — welche Operationen sind sequentiell, die parallel sein koennten?
5. **Der kritische Pfad**: Die laengste Kette sequentieller Operationen identifizieren. Das ist die theoretische Mindest-Antwortzeit.
6. **Optimierungsplan**: Spezifische Fixes nach Impact geordnet — hoechster Impact, geringster Aufwand zuerst.

Beispiel-Ausgabe

Kategorie: I/O-gebunden — 3 sequentielle API-Aufrufe (je 500ms) + 1 DB-Query (800ms) = 2.3s Minimum auf kritischem Pfad
Wasserfall: Auth-Check (500ms) → User-Fetch (500ms) → Permissions-Fetch (500ms) → DB-Query (800ms) → Render (200ms)
Optimierungsplan:
  1. Auth + User parallelisieren: Promise.all([checkAuth(), fetchUser()]) — spart 500ms, Aufwand: 5 Min.
  2. Permissions in Redis cachen (TTL 5min) — spart 500ms bei Cache-Hit, Aufwand: 30 Min.
  3. DB-Index auf WHERE-Klausel — spart 600ms, Aufwand: 2 Min.
Erwartetes Ergebnis: 2.5s → 900ms (64% Verbesserung)

Wann verwenden

Diesen Skill einsetzen, wenn die Anwendung langsamer als akzeptabel ist und die Ursache unklar ist. Unverzichtbar VOR jeder Optimierung — immer zuerst profilen, dann optimieren.

Profi-Tipps

• Unter produktionsaehnlichen Bedingungen profilen — Entwicklungsmodus ist 5-10x langsamer als Produktion. Immer einen Production-Build profilen.
• Die 80/20-Regel gilt — 80% der Zeit wird in 20% des Codes verbracht. Der Flamegraph zeigt ein oder zwei dominante Stacks. Ausschliesslich darauf fokussieren.
• Vorher und nachher messen — ohne Baseline-Messung kann nicht bewiesen werden, dass eine Optimierung gewirkt hat.
• Sequentielles I/O ist der #1-Engpass in Web-Apps — die meiste Langsamkeit kommt vom sequentiellen Await von Dingen, die parallel laufen koennten. Promise.all() ist oft die wirkungsvollste einzelne Optimierung.