Performance Optimization

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