rcode-perflisted

@.rcode/references/karpathy-guidelines.md ## Overview Performance work without measurement is theatre. This skill enforces measure → identify → fix ��� re-measure for every claim. Targets are stack-specific because optimisation moves are stack-specific. For Three.js scenes: frame budget. For Postgres: EXPLAIN ANALYZE. For Next.js: Lighthouse + bundle analyzer. Same skill, different tools. ## Workflow 1. **Baseline.** Capture the current number — LCP in ms, fps, query duration, RAM at peak. Quote the source (Lighthouse, Chrome perf trace, EXPLAIN ANALYZE, K8s metrics). 2. **Set the budget.** What does "good enough" look like? E.g. LCP ≤ 2.5s, 60fps with 5% headroom, query p95 < 100ms. If there's no budget, the work has no exit condition. 3. **Identify the bottleneck.** One number, one mechanism. "The page feels slow" isn't a bottleneck — find the specific waterfall step or render loop. 4. **Fix.** One change. Re-measure. 5. **Compare to budget.** Either the change cleared the budget (ship it) or it didn't (next bottleneck). 6. **Stop when the budget is met.** Optimisation past the budget is yak-shaving. ## Stack-specific cheat sheet ### Next.js - LCP: defer below-the-fold images; preload the LCP image. - TBT: split the largest Client Component into Server Component + small Client island. - Hydration: prefer Server Components by default; `'use client'` only where interactivity is required. - Bundle: `next-bundle-analyzer`; per-route, find the >100KB chunks first. ### T