| name | benchmark |
| description | Use this skill to measure performance baselines and detect regressions in re-forge — before/after a PR, when users report "it feels slow", or before a launch when you must meet performance targets. It covers page (Core Web Vitals), API (latency percentiles), and build performance, plus before/after comparison. Activate on phrases like "benchmark this", "measure performance", "is this slower", or "set a perf baseline". |
Benchmark — Performance Baseline & Regression Detection
Measure performance objectively, save baselines, and catch regressions before they ship.
When to use
- Before and after a PR to measure performance impact
- Setting up performance baselines for a project
- When users report it feels slow
- Before a launch — verify you meet performance targets
- Comparing your stack against alternatives
Modes
Mode 1: Page performance
Measure real browser metrics (via a browser automation tool):
- Core Web Vitals: LCP < 2.5s, CLS < 0.1, INP < 200ms, FCP < 1.8s, TTFB < 800ms
- Resource sizes: total page weight < 1MB, JS bundle < 200KB gzipped, plus CSS/image/third-party weight
- Network request count and render-blocking resources
Mode 2: API performance
- Hit each endpoint ~100 times; measure p50 / p95 / p99 latency
- Track response size and status codes
- Test under load (e.g. 10 concurrent requests)
- Compare against SLA targets
Mode 3: Build performance
- Cold build time, hot-reload (HMR) time
- Test-suite duration, type-check time, lint time, container build time
Mode 4: Before/after comparison
- Capture a baseline before the change.
- Make the change.
- Re-measure and compare against the baseline.
Report deltas with a verdict:
| Metric | Before | After | Delta | Verdict |
|--------|--------|-------|--------|---------|
| LCP | 1.2s | 1.4s | +200ms | WARN |
| Bundle | 180KB | 175KB | -5KB | BETTER |
| Build | 12s | 14s | +2s | WARN |
What to do
- Pick the relevant mode(s) for what changed.
- Capture a baseline (commit it so the team shares it).
- Make/measure the change and compute deltas against the baseline.
- Flag any regression beyond noise and report with the verdict table.
Output
Store baselines as JSON in .reforge/benchmarks/, git-tracked so the team shares them.
Hard rules
- Always measure a baseline before optimizing — no baseline, no verdict.
- Run enough samples to distinguish a real delta from noise (percentiles for APIs, repeated runs for builds).
- In CI, run the before/after comparison on every PR and fail on regressions beyond threshold.
- Pair with the
benchmark-optimization-loop skill when the goal is to actively make something faster.
