写在前面
很多团队的性能优化流程是这样的： 上线 -> 用户投诉卡 -> 突击优化一周 -> 上线 -> 继续劣化 -> 循环...
这种**“波浪式”的性能曲线是不可接受的。 架构师的目标是让性能曲线呈现“锯齿状上升” （偶尔波动，总体平稳）甚至“水平直线”**。
这一节，我们将把性能管理从“靠自觉”转变为“靠制度”。我们将学习如何制定 Performance Budget（性能预算） ，并把 Lighthouse CI 植入到你的 Git Workflow 中。
一、 什么是 Performance Budget（性能预算）？
在金融领域，预算意味着“你有多少钱可以花”。 在前端领域，性能预算意味着“为了达到预期的加载速度，你最多能写多少代码/加载多大的资源”。
1.1 预算的维度
通常我们可以从两个维度设定预算：
-
基于资源的预算 (Resource-based):
- 规则： JS 总包体积 < 300KB；首屏图片 < 100KB。
- 优点： 简单，确定性强，构建时就能检测。
- 缺点： 体积小不代表跑得快（比如 10KB 的死循环代码）。
-
基于指标的预算 (Metric-based):
- 规则： LCP < 2.5s；TBT < 300ms；Lighthouse Score > 90。
- 优点： 直接反映用户体验。
- 缺点： 受 CI 机器性能波动影响大（噪音）。
1.2 如何制定合理的预算？
不要拍脑袋定个“LCP < 1秒”，这不切实际。
- 基准线法： 先测出当前生产环境的平均水平（比如 JS = 500KB），以此为基准，规定 “新增代码不得导致体积增加超过 5%” 。
- 竞品锚定法： 看看你们最大的竞争对手是多少，设定为“比他们快 20%”。
二、 守门员工具：LightWallet 与 Size-limit
有了法律（预算），我们需要警察（工具）来执行。
2.1 静态体积守门员：Size-limit
这是最轻量级的守门员，适合防范 node_modules 膨胀。
安装与配置：
// package.json
{
"size-limit": [
{
"path": "dist/assets/index.*.js",
"limit": "200 KB" // 超过这个值，npm run build 直接报错
},
{
"path": "dist/assets/vendor.*.js",
"limit": "500 KB"
}
]
}
CI 集成： 在 GitLab CI 或 GitHub Actions 中运行 npx size-limit。一旦超标，Pipeline 变红，禁止合并。
2.2 运行时指标守门员：Lighthouse CI (LHCI)
Google 官方出品的神器。它会在 CI 环境启动一个无头浏览器，跑一遍你的页面，并打分。
核心配置 lighthouserc.js：
module.exports = {
ci: {
collect: {
url: ['http://localhost:3000/'], // 本地启动服务让 LHCI 跑
startServerCommand: 'npm run start',
},
assert: {
assertions: {
'categories:performance': ['error', { minScore: 0.9 }], // 性能分低于 90 报错
'largest-contentful-paint': ['warn', { maxNumericValue: 2500 }], // LCP > 2.5s 警告
'dom-size': ['error', { maxNumericValue: 2000 }], // DOM 节点 > 2000 报错
},
},
upload: {
target: 'temporary-public-storage', // 上传报告以便查看
},
},
};
三、 实战：构建“不许变慢”的 CI/CD 流水线
把上述工具串联起来，形成一套完整的防御体系。
3.1 阶段一：PR Check (代码合并前)
当同事发起 Pull Request 时，触发 GitHub Actions：
-
Build: 构建项目。
-
Size Check: 运行
size-limit。如果引入了大包（如lodash未按需引入），直接 Block PR。 -
Audit: 运行
Lighthouse CI。- Diff 模式： 对比 master 分支和当前分支的性能差异。
- Bot 留言： LHCI 机器人会自动在 PR 下评论：“本次提交导致 LCP 增加了 200ms，请解释或优化。”
3.2 阶段二：Monitor (代码合并后)
上线后，结合我们在第二节搭建的 APM 系统。
- 熔断机制： 虽然少见，但可以设定如果线上 LCP 突增 50%，自动触发回滚（Rollback）。
四、 治理的艺术：如何处理“噪音”与“人心”
技术只是手段，治理的核心是人。
4.1 解决 CI 波动（Flakiness）
CI 服务器（如 Jenkins/Actions）的 CPU 负载是不稳定的，可能导致 Lighthouse 跑分忽高忽低。 架构师策略：
- 多次采样： 让 LHCI 跑 3-5 次，取中位数（Median）。
- 相对阈值： 不要死扣绝对值（2.5s）。设定劣化阈值（Regression Threshold），例如“比基准线慢 10% 以上”才报错。
4.2 逐步收紧策略
不要一上来就开启“报错即阻断”，这会搞崩开发团队的心态。
- 观察期 (第 1 个月): 只跑数据，不报错，让大家看到报告。
- 警告期 (第 2 个月): 超标后 CI 变黄（Warning），机器人留言羞辱，但允许合并。
- 阻断期 (第 3 个月): 核心指标（如 Bundle Size）超标，直接 Block。
4.3 性能文化
- 红黑榜： 每周发送邮件，列出“本周性能优化最佳提交”和“本周导致性能劣化最严重的提交”。
- 性能是功能的一部分： 产品经理提需求时，必须包含性能验收标准。
结语：从“救火队员”到“城市规划师”
至此，第七阶段《前端全链路性能体系与可观测性》 圆满结束。
回顾这四小节，我们走过了一条完整的架构之路：
- 定标准 (Standard): 确立 Web Vitals，拒绝主观臆测。
- 搞基建 (Infrastructure): 搭建 APM，获得上帝视角。
- 定战术 (Tactics): 分层级优化，从网络到渲染全覆盖。
- 做治理 (Governance): 设立预算与 CI，防止性能腐化。
现在的你，不再是那个天天盯着 Chrome DevTools 修 Bug 的救火队员，而是掌控全局、用数据和制度说话的系统架构师。
然而，前端的世界远不止性能。随着业务越来越复杂，单体应用（Monolith）变得难以维护，巨石应用如何拆解？微前端真的是银弹吗？Serverless 能给前端带来什么变革？
