performance-engineeringlisted

# Performance Engineering Three rules, in order: 1. **Measure first.** Optimising the wrong thing is worse than doing nothing — it costs time and adds complexity for no gain. 2. **Fix the biggest thing.** Performance work follows a power law; one bottleneck usually dominates. 3. **Set a budget and enforce it in CI.** Performance regresses by accretion, one small addition at a time, and is only ever recovered by deliberate effort. Never report "this will be slow" without a measurement. Never report a measurement without saying what it was measured on. --- ## Frontend: the numbers that matter Core Web Vitals, measured at the **75th percentile of real users** — not from your laptop on office wifi. | Metric | Good | Needs work | Poor | What it measures | |---|---|---|---|---| | **LCP** | ≤ 2.5s | ≤ 4.0s | > 4.0s | When the main content appears | | **INP** | ≤ 200ms | ≤ 500ms | > 500ms | Responsiveness to interaction | | **CLS** | ≤ 0.1 | ≤ 0.25 | > 0.25 | Visual stability | Supporting: TTFB (≤ 800ms), total JavaScript, and total page weight. **Lab vs field.** Lighthouse is a lab tool: reproducible, useful for catching regressions, and not what your users experience. Field data (Chrome UX Report, or your own real-user monitoring) is the truth. Use lab to iterate, field to decide. --- ## LCP — usually the highest-leverage fix LCP is almost always an image or a heading blocked by something. 1. **Find the element.** Chrome DevTools Performance panel marks it; Pa