用Lighthouse CI自动化流水线识别隐藏性能回归

识别隐藏的性能退化，仅靠肉眼观察或偶尔运行一次 Lighthouse 远远不够。关键在于建立一套可重复、可对比、并带有历史基线的自动化流水线。Lighthouse CI 的核心价值，正是把这种“偶然检测”转变为一位“持续守门人”——它不仅告诉你当前得分，还能明确回答几个关键问题：这次比上次变差了吗？差在哪里？是否超出了团队的容忍范围？

用历史基线代替单次快照

单次 Lighthouse 报告就像一张孤立的快照，缺乏上下文，容易忽略缓慢累积的性能衰退。Lighthouse CI 通过保存每次构建的完整性能指标（如 LCP、CLS、TBT），能够自动计算并呈现趋势变化。

• 必须启用 upload 配置（初期可使用 temporary-public-storage），否则无法实现跨构建的历史数据对比。
• 确保每次数据收集面向相同的 URL 和测试环境，例如统一使用 startServerCommand: 'npm run preview' 来启动静态服务。
• 在 lighthouserc.js 配置文件中，开启 collect.numberOfRuns: 3，通过多次采样降低单次测试的随机波动影响。

设置有业务意义的断言阈值

笼统的“分数下降了5分”不一定是问题，但“首页的 LCP 超过了 2.8 秒并且连续两次构建都在恶化”，很可能就是一个需要立即拦截的隐藏风险。

• 避免直接使用笼统的 preset: 'lighthouse:recommended'，这套预设主要做基础合规检查，对防止性能回归作用有限。
• 针对核心业务页面（如首页、商品详情页、登录页），需要单独配置精细化的 assertions。例如：
  'largest-contentful-paint': ['error', {maxNumericValue: 2800}],
'cumulative-layout-shift': ['warn', {maxNumericValue: 0.1}],
• 对于关键的用户交互路径（例如点击搜索按钮后的结果页渲染），可在 CI 流程中额外运行定向性能测试，而不仅仅依赖于首页 URL 的检测。

在 Jenkins 或 GitHub Actions 中嵌入回归判断逻辑

CI 工具本身并不理解什么是“性能退化”，这需要依靠 Lighthouse CI 提供的退出码和结构化报告来驱动决策流程。

• Lighthouse CI 在 assert 断言失败时会默认返回非零退出码（如 1），这会导致 Jenkins 构建自动标记为失败；在 GitHub Actions 中，则可利用 if: ${{ failure() }} 条件触发告警通知。
• 不要只盯着总分变化。在 Jenkins 构建日志中，可搜索 Regression detected in 关键字，它能明确指出是哪个具体指标、在哪个 URL 上出现了恶化。
• 配合使用 lhci healthcheck 命令，定期验证 Lighthouse CI 服务器的连通性与数据采集稳定性，从而排除因测试环境临时抖动而产生的误报。

把报告变成可协作的信号源

识别出性能退化只是第一步。团队能否快速响应并修复，很大程度上取决于相关信息是否能够直接触达、便于追溯、以及清晰归因。

• 启用 upload.target: 'lhci-server' 以自建服务，从而获得功能完整的 Web 仪表盘，其中包含提交差异对比、PR 关联信息以及可视化的指标趋势图表。
• 在 GitHub 的 Pull Request 描述中，可自动插入 Lighthouse CI 的性能摘要。使用 stefanoeb/lighthouse-ci-action 这类 Action 可以轻松实现这一功能。
• 对于那些反复触发同一项指标警告的 PR，可为其添加特定标签（例如 perf/lcp-regression），这有助于推动团队进行专项排查和优化。