很多团队都知道 Lighthouse，但真正把 Lighthouse CI 跑进日常流程的并不多。
原因很现实：
- 大家担心 CI 不稳定
- 评分波动不好解释
- 报告看起来很多，但不知道该怎么落地
于是性能检查往往变成上线前“想起来才测一次”的手工动作。这样做最大的问题不是效率低，而是性能回归会在没有人注意的时候悄悄发生。
Lighthouse CI 的目标不是追高分，而是防回归
这是最重要的前提。
如果团队把 Lighthouse CI 当成“每次都要 100 分”的系统，最终只会出现两个结果：
- 指标被形式化追逐
- CI 规则被大家集体绕开
更合理的目标是：
- 守住关键页面的底线指标
- 尽早发现异常波动
- 在 PR 阶段暴露风险，而不是上线后追责
Lighthouse CI 真正适合做的，是门禁，不是竞赛。
接入前先确定关键页面与关键指标
并不是所有页面都值得同等强度地跑 Lighthouse CI。
优先级通常应该是：
- 业务入口页
- 高流量内容页
- 转化关键页
- 公共布局和公共组件变更影响较大的页面
指标也不应一股脑全上。更实用的选择是：
- LCP、CLS、INP 或 TBT
- JS 体积、未使用代码、关键请求链
- Accessibility 与 Best Practices 中的关键底线
性能预算要写成“可执行阈值”
团队最容易踩的坑，是只设一个总分阈值。
这样的问题在于：
- 总分波动很难定位原因
- 单一回归会被其他分项掩盖
- 开发很难知道具体应该修什么
更好的做法是把预算拆成明确断言：
- LCP 不能超过多少
- JS 总字节数不能超过多少
- 阻塞主线程时长不能超过多少
这样 CI 报红时，工程师能立刻知道问题在哪里。
CI 流程设计要兼顾稳定性与可解释性
Lighthouse CI 最大的落地难点，不是命令怎么写，而是怎么减少误报。
常见做法包括：
- 在固定环境运行，减少资源波动
- 关键页面跑多次取中位值
- 将实验性页面和核心门禁页面分开
- 把“警告”和“阻断”区分开来
如果一上来所有断言都直接阻断合并，团队很快会反感这套系统。
Lighthouse CI 不能替代真实用户监控
这是另一个常见误区。Lighthouse CI 是实验室数据，它很适合做基线和回归检查，但不能覆盖：
- 真实弱网场景
- 低端设备差异
- 区域性服务波动
- 第三方脚本偶发问题
所以正确组合通常是：
- 用 Lighthouse CI 做提交阶段门禁
- 用 RUM 做线上真实体验监控
- 用告警和趋势图找回归来源
一个常见失败案例：CI 接上了，但团队最后选择全部忽略
原因通常不是 Lighthouse CI 不好，而是接入姿势有问题：
- 页面选得太多
- 阈值设得过满
- 结果解释成本太高
- 性能问题没人负责跟进
最后大家看到红灯的第一反应，不是修问题，而是想办法跳过检查。
所以 Lighthouse CI 必须和团队流程一起设计，而不是单独丢一个工具进去。
一份可直接复用的检查清单
- 是否只选择了真正关键的页面进入门禁
- 预算是否拆成可解释的具体阈值，而不是只看总分
- CI 是否通过重试、中位值和环境固定降低误报
- 是否用警告和阻断区分不同严重级别
- 是否同时搭配了真实用户监控来覆盖线上体验
总结
Lighthouse CI 的核心价值，是把性能检查前移到 PR 阶段，并把性能目标写成团队能执行的门禁规则。只要页面范围、预算阈值和误报控制设计得当，它就会从“漂亮报告”变成真正有效的工程防线。
进一步阅读：
