一句话

先测量再优化的性能流程：定位一个瓶颈、只修那一个、用数据决定去留，再立护栏防回退。

何时用

• 适合：有性能要求或疑似回退；Core Web Vitals、加载时长要改善；N+1 等已定位的模式；profiling 出了热点。
• 不适合：没有测量数据的「感觉慢」；成本上不值的优化（cost mid）。

怎么用

商品页 LCP 超标，帮我定位瓶颈并修掉，修完要数据证明

1. Measure：合成数据（Lighthouse、DevTools trace）加 RUM、APM 先到位。
2. Identify：从数据里指出一个瓶颈，不是一堆。
3. Fix：只修识别出的那个；常见反模式的修法查 references/optimization-patterns.md，用到才翻。
4. Verify：对比前后数据，没改善就 revert，不留「理论上更快」。
5. Guard：bundle size、Lighthouse CI 等护栏防回退。

产出

• 前后对比数据、针对单瓶颈的修复、回归护栏配置。

要点与坑

• 不测量不优化；一次只修一个瓶颈才能归因。
• 没达标的优化要回退，「留着也没坏处」会累积成债。
• /webperf 命令走 web-performance-auditor 人格做专项审计。

本机版本差异

仓库版把 Step 3 改成「只修已识别的瓶颈」，反模式清单抽到 references/optimization-patterns.md 按需查阅；本机旧版是内联的逐条修复清单。

关联

• 搭配：addy-browser-testing-with-devtools、addy-observability-and-instrumentation · 下游：addy-shipping-and-launch
• 所属：00-addy-概览