性能预算
性能预算：给项目设置性能指标阈值，超出则告警或阻断发布。
#type / concept
#status / growing
#tech / dev / frontend
[!info] related notes
- 所属 MOC: 前端性能优化 MOC
- 前置概念: performance-monitoring-system
- 并列概念: performance-metrics-system
性能预算
一句话定义
性能预算是为网站性能指标设定量化目标（体积、耗时、得分），超出阈值时自动告警或阻断发布的工程化治理手段。
核心机制 / 工作原理
为什么需要性能预算
- 性能退化是渐进的，每次 PR 增加一点，累积后用户流失
- 没有量化目标，性能优化永远排在功能后面
- 预算让性能从”事后补救”变为”事前预防”
常见指标预算
| 指标 | 含义 | 推荐目标 |
|---|---|---|
| FCP（First Contentful Paint） | 首次内容绘制 | < 1.8s |
| LCP（Largest Contentful Paint） | 最大内容绘制 | < 2.5s |
| TTI（Time to Interactive） | 可交互时间 | < 3.8s |
| TBT（Total Blocking Time） | 总阻塞时间 | < 200ms |
| CLS（Cumulative Layout Shift） | 累积布局偏移 | < 0.1 |
| INP（Interaction to Next Paint） | 交互响应延迟 | < 200ms |
资源预算
| 资源类型 | 预算限制 |
|---|---|
| 首屏 JS bundle | < 200KB（gzip） |
| CSS 总量 | < 50KB（gzip） |
| 单张图片 | < 200KB |
| 字体文件 | < 100KB |
| 首屏请求数 | < 30 个 |
| 长任务数量 | < 3 个 |
如何制定预算
- 竞品分析：测量同类产品的性能数据作为基线
- 用户设备：根据目标用户群的设备和网络条件调整（如新兴市场需更宽松）
- 业务优先级：核心路径（首页、支付）预算更严格
- 逐步收紧：初期设宽松值，优化后逐步收紧
执行方式
- 构建时检查：webpack bundle analyzer、size-limit 等工具在构建时检查体积
- CI 门禁：PR 合并前自动检查 bundle 大小变化，超标则阻断
- Lighthouse CI：在 CI 中跑 Lighthouse，检查 Web Vitals 是否达标
- 运行时监控：RUM（真实用户监控）持续追踪线上性能数据
工具链
| 工具 | 用途 |
|---|---|
| size-limit | 检查 JS 包体积变化 |
| bundlesize | CI 中检查 bundle 大小 |
| Lighthouse CI | CI 中跑 Lighthouse 审计 |
| Web Vitals 库 | 采集真实用户性能数据 |
| webpack-bundle-analyzer | 可视化 bundle 组成 |
最小例子
在 package.json 中配置 size-limit：
{
"size-limit": [
{
"path": "dist/index.js",
"limit": "50 KB"
},
{
"path": "dist/vendor.js",
"limit": "150 KB"
}
]
}CI 中运行 npx size-limit，超过限制则返回非零退出码，阻断合并。
边界与常见误解
- 预算不是一成不变：随业务增长和优化进展动态调整
- 预算 ≠ 不允许超标：超标需说明原因和改进计划，而非一刀切阻断
- 体积预算 ≠ 性能预算：JS 体积小不代表执行快，还需关注 TBT/TTI
- Lighthouse 分数有波动：CI 中多次运行取中位数更可靠
- 预算的文化价值：让团队从”出了问题再优化”变成”主动控制性能”
Related notes
- 前端性能优化 MOC
- 性能指标体系
- 前端工程化中的性能优化
- Lighthouse
- [[web-vitals|Web Vitals]]