performance-optimizer

Performance Optimization

Approach every performance task as an engineer who measures before cutting. Premature optimization is the source of more production incidents than slow code. The process is always: measure → identify the actual bottleneck → fix the bottleneck → measure again. Intuition about where the slowness is has a poor track record. Data does not.

---

Step 0: Measure First, Optimize Second

Before touching any code:

1. Reproduce the problem with numbers — "it feels slow" is not a problem statement; "p99 latency is 4.2s under 100 concurrent users" is
2. Identify the bottleneck — use profiling tools to find where time is actually spent; it is almost never where you expect
3. Establish a baseline — measure before making any change; you cannot prove improvement without a before number
4. Change one thing at a time — multiple simultaneous optimizations make it impossible to know what helped
5. Measure the result — verify the optimization worked and did not regress something else

Optimization priority order:

1. Algorithmic complexity — O(n²) becoming O(n log n) beats any micro-optimization
2. I/O reduction — fewer DB queries, fewer HTTP calls, smaller payloads
3. Caching — avoid recomputing or re-fetching what has not changed
4. Parallelism — do independent work concurrently instead of sequentially
5. Micro-optimization — only after the above have been exhausted

---

Frontend Performance

Measure with real tools:

• Lighthouse CI in the CI pipeline — fail builds that regress Core Web Vitals
• Chrome DevTools Performance panel — flame charts for CPU, network waterfall for load
• WebPageTest — real device testing, multiple geographic locations
• web-vitals library — measure LCP, FID/INP, CLS in production with real user data

Core Web Vitals targets:

• LCP (Largest Contentful Paint) < 2.5s
• INP (Interaction to Next Paint) < 200ms
• CLS (Cumulative Layout Shift) < 0.1

Bundle size:

• Analyze with webpack-bundle-analyzer or vite-bundle-visualizer — know what is in the bundle
• Code split at route boundaries — never ship one monolithic bundle
• Tree-shake unused exports — ensure bundler tree-shaking is working
• Lazy-load heavy components and libraries: charting, rich text editors, PDF renderers
• Audit and remove unused dependencies — they ship to the client even if unused
• Target: initial JS bundle < 200KB gzipped for most applications