Performance Optimization
Overview
Measure before optimizing. Performance work without measurement is guessing — and guessing leads to premature optimization that adds complexity without improving what matters. Profile first, identify the actual bottleneck, fix it, measure again. Optimize only what measurements prove matters.
When to use
- Performance requirements exist in the spec (load time budgets, response time SLAs)
- Users or monitoring report slow behavior
- Core Web Vitals scores are below thresholds
- You suspect a change introduced a regression
- Building features that handle large datasets or high traffic
Do not optimize before you have evidence of a problem. For page-load audits use web-perf. For production telemetry design use observability.
Process
1. MEASURE → Establish baseline with real data
2. IDENTIFY → Find the actual bottleneck (not assumed)
3. FIX → Address the specific bottleneck
4. VERIFY → Measure again, confirm improvement
5. GUARD → Add monitoring or tests to prevent regression
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | ≤ 4.0s | > 4.0s |
| INP (Interaction to Next Paint) | ≤ 200ms | ≤ 500ms | > 500ms |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | ≤ 0.25 | > 0.25 |
Use both synthetic (Lighthouse, DevTools) and RUM (web-vitals, CrUX). Symptom trees, bottleneck tables, anti-pattern fixes, and budgets: references/measure-and-fix.md.
Do not apply React.memo / useMemo everywhere — overusing is as bad as underusing.
Red flags
- Optimization without profiling data to justify it
- N+1 query patterns in data fetching
- List endpoints without pagination
- Images without dimensions, lazy loading, or responsive sizes
- Bundle size growing without review
- No performance monitoring in production
React.memoanduseMemoeverywhere (overusing is as bad as underusing)
Verification
After any performance-related change:
- Before and after measurements exist (specific numbers)
- The specific bottleneck is identified and addressed
- Core Web Vitals are within "Good" thresholds
- Bundle size hasn't increased significantly
- No N+1 queries in new data fetching code
- Performance budget passes in CI (if configured)
- Existing tests still pass (optimization didn't break behavior)
References
references/measure-and-fix.md— measurement, bottleneck map, anti-pattern fixes, budgets