性能预算自动化管理：用 Lighthouse CI 与 Web Vitals 把“性能”变成可执行门禁
性能优化最痛的不是“没提升”，而是：
- 你花了一周把首屏优化到 2.2s
- 两个迭代后引入一个组件库/统计脚本
- 首屏又回到 3.5s，大家还没人发现
这就是为什么性能需要预算：
性能预算不是用来“追高分”，而是用来防回归。
本文把“性能预算”从概念讲到自动化落地：如何设预算、如何在 PR 阶段做门禁、如何与线上 RUM 数据结合，让预算长期有效。
1. 性能预算到底是什么：把目标写成“可执行阈值”
性能预算可以是多维的，但最推荐的起步方式是两类：
- 体验预算：以 Web Vitals 为核心（LCP/INP/CLS）
- 资源预算：以体积/请求为核心（JS KB、图片 KB、请求数）
不要一上来就设 20 个阈值。门禁阈值越多，噪音越大。
2. 预算怎么定：按页面分级，而不是全站一个标准
常见页面分级：
- P0 页面：首页/落地页/核心转化页（预算最严格）
- P1 页面：内容页/列表页（预算中等）
- P2 页面：后台/编辑器（重点看 INP 与长任务）
建议先选 3–5 个关键 URL 做预算门禁。
3. 选择预算指标：最少但最有效的组合
一套低噪音组合（建议起步）：
- Lighthouse Performance score（作为粗门槛）
- LCP / CLS（首屏体验关键）
- Total Blocking Time 或长任务（更接近交互阻塞，视工具支持）
- JS bundle size（防止首屏脚本膨胀）
注意：Lighthouse 指标是 Lab 指标，更适合做“回归检测”，不适合当成绝对 KPI。
4. Lighthouse CI：把预算落地到 PR 门禁
4.1 为什么选择 Lighthouse CI
- 可自动化
- 可对比（当前 PR vs 基线）
- 可设阈值 fail
4.2 典型工作流（思路示意）
在 PR 流程中：
- 构建站点
- 启动预览服务
- 跑 Lighthouse CI 对关键 URL 测量
- 阈值不达标则失败
你可以从“只跑 1–3 个 URL”开始，确保稳定后再扩展。
5. 让预算不折磨人：降低噪音的 6 个技巧
- 固定测试环境：同样的机器/同样的网络
- 固定运行次数：多跑几次取中位数
- 只测关键 URL：不要全站乱测
- 阈值给余量：先能防回归，再逐步收紧
- 区分 PR 回归 vs 长期目标：门禁阈值不要等同 KPI
- 把失败输出变成人话：给出“怎么修”的提示
6. 把预算与 RUM 结合：避免“追分”而忽略真实用户
一个健康的闭环是：
- PR 阶段：用 Lighthouse CI 做回归门禁（Lab）
- 线上阶段：用 RUM 看真实用户体验（Field）
当出现差异时，优先相信 RUM，并用 Lab 去定位原因。
7. 建议的落地路线（按周推进更稳）
第 1 周：建立基线
- 选 3 个关键 URL
- 跑 Lighthouse 形成基线
- 先不设 fail，只生成报告
第 2 周：引入门禁
- 给 Performance score / LCP / CLS 设一个宽松阈值
- 开始阻止明显回归
第 3-4 周：与 RUM 打通
- 建立线上 Web Vitals 趋势
- 以真实用户体验指导阈值收敛
