| name | performance-rescue |
| description | Use for slowness, latency, p50/p95, efficiency, benchmarks, or making apps, APIs, queries, or UI faster. |
Performance Rescue
No guesswork. Measure the exact slow path, fix the real bottleneck with the smallest safe change, then remeasure the same path.
First Moves
- Load relevant stack skills: React/Next, Appwrite, Flutter/Dart, tests, browser verification.
- Name the workflow:
production performance smoke test.
- Capture target route/action/API, role/test account, env, and what "slow" means.
- Measure before editing. If telemetry is missing, add tiny scoped instrumentation.
Metrics
Always report:
route/action:
sample size:
status counts:
p50/p75/p95/p99/max:
error rate:
saturation:
slowest phase:
before vs after:
remaining risk:
Use client-visible timing plus backend/service timing. Do not summarize latency with only averages or p50.
Fix Order
- Delete unnecessary work.
- Kill waterfalls; start independent work early and await late.
- Reuse fetched rows/maps/lookups.
- Reduce DB cost: projection, indexes, cursor pagination, bounded queries.
- Defer optional enrichment; return primary data first.
- Reduce render/main-thread work only after profiler evidence.
- Add timeout/retry only for proven idempotent reads.
- Cache only after correctness and invalidation are clear.
Keep write authority in the canonical owner; do not move lifecycle or side effects into a faster-looking caller.
Details
Read references/runbook.md for instrumentation patterns, Appwrite/cloud-function checks, browser/Core Web Vitals gates, test ideas, red flags, and final report format.
Final
Include exact before/after metrics, code/data-flow changes, verification commands, production/browser evidence, and any remaining bottleneck.
