performance-auditlisted

# Performance Audit ## The Law ``` A PERFORMANCE CLAIM WITHOUT NUMBERS IS AN OPINION. "I think it's faster" is not a result. "p95 latency dropped from 480ms to 42ms on a 1000-item dataset" is a result. ``` ## When to Use - Before any optimisation work (establish baseline first) - When a performance regression is reported - As a pre-release gate on performance-critical features - After an optimisation to validate the improvement ## Audit Workflow ### Step 1: Define the Performance Goal Before measuring anything, define what "good" looks like: | Category | Example target | |----------|---------------| | API latency | p95 < 200ms at 100 concurrent users | | Page load | First Contentful Paint < 1.5s on 4G | | Mobile frame rate | 60fps during scroll, 0 jank frames | | Build time | Full build < 3 minutes | | Memory | Peak heap < 512MB under load | | Bundle size | JS bundle < 250KB gzipped | If no target exists, the first audit establishes the baseline that becomes the target. ### Step 2: Measure the Baseline Run the benchmark **before any changes**. Record: - Tool used and exact command - Input size and conditions - Raw numbers (min, p50, p95, p99, max) - System state (CPU, memory, concurrent users) ```markdown ## Baseline — YYYY-MM-DD **Feature:** User search endpoint **Tool:** k6 **Command:** `k6 run --vus 50 --duration 60s scripts/search-load-test.js` **Input:** 1000-user dataset, query="test" | Metric | Value | |--------|-------| | p50 | 45ms | | p95 | 380ms | | p