本文目录导读：
怎样做性能预算？从定义到落地的全流程指南
📖 目录导读
- 性能预算是什么？为什么必须做？
- 制定性能预算的三大核心指标
- 如何确定预算数值（含行业参考）
- 性能预算的落地工具与工作流
- 常见问题解答：预算太紧/太松怎么办？
- 从预算到性能文化的转变
性能预算是什么？为什么必须做？
性能预算，简单说就是给网站或应用的性能表现设定一个“花钱的上限”，就像旅行前定好预算——机票、住宿、饮食各花多少钱，性能预算就是规定：首屏加载不能超过3秒、首次交互时间不能超过2秒、页面总大小不超过1MB。
为什么要做？
- 避免“功能膨胀”：团队每加一个特效、多塞一张大图，性能就偷偷掉一分，没有预算，产品经理、设计师、开发者会无意识地堆砌资源。
- 提升用户体验：谷歌研究发现，页面加载延迟1秒，移动端转化率下降20%。
- 影响SEO排名：谷歌Core Web Vitals（核心网页指标）直接作为排名因子,性能不达标意味着流量损失。
问：小团队或MVP也需要做性能预算吗？
答：需要，但可以简化，即使是MVP，设定一个“首屏加载<4秒”的底线，也能避免上线后用户大规模流失，预算不必一步到位,先有后优。
制定性能预算的三大核心指标
不要贪多，先盯住这三个最能反映用户感受的指标：
| 指标 | 衡量什么 | 理想值（移动端） | 用在哪 |
|---|---|---|---|
| LCP（Largest Contentful Paint） | 元素渲染时间 | ≤2.5秒 | 感知加载速度 |
| FID（First Input Delay） | 首次交互响应延迟 | ≤100毫秒 | 交互流畅度 |
| CLS（Cumulative Layout Shift） | 页面布局累计偏移量 | ≤0.1 | 视觉稳定性 |
| 总传输大小 | 所有资源体积 | ≤1MB（移动端） | 带宽/缓存策略 |
实际工作中,还可以补充：
- TTI（Time to Interactive）：页面完全可交互时间，建议≤5秒
- 页面请求数：建议≤50个（移动端）
问：为什么预算不能只有“加载速度”？
答：加载快不一定体验好——比如页面瞬间出来但图片链接跳来跳去（CLS高），用户一样会放弃,用户体验是多维度的。
如何确定预算数值（附行业参考）
预算不是拍脑袋定的，建议分三步走：
第一步：审计当前状态
用工具（Lighthouse、WebPageTest、Chrome DevTools）跑出当前数据，如果首屏5秒，就别直接定2秒——先从5秒降到3.5秒,再降到3秒。
第二步：参考行业基准
- 电商类：LCP≤2.5秒，TTI≤5秒（亚马逊调研：1秒延迟导致年损失16亿美元）类（博客/新闻）**：LCP≤3秒，CLS≤0.1
- 工具类/后台：FID≤200毫秒（因为是重交互场景）
第三步：用“性能预算计算器”反向推导
假设目标LCP=2.5秒,意味着：
- 网络耗时：约1.2秒（按3G网络304MBPS算）
- 渲染耗时：约1.3秒
- 那么JS/CSS/图片体积总和必须≤多少？-> 通过工具测出“每KB耗时”，反推总大小≤800KB（移动端）
落地建议：第一次定预算时，留10%~20%缓冲区（如总大小1MB，改到1.2MB）,等团队适应后再收紧。
问：预算定下来后，就能一致执行吗？
答：不能，需要定期（比如每两周一更新）重新评估，比如换了CDN、用了新版框架,预算基准也要调整。
性能预算的落地工具与工作流
工具推荐
- LiveLighthouse：嵌入CI/CD（持续集成/持续部署），每次提交代码自动跑性能,不达标阻测。
- Figma/设计稿插件：设计师在作图时就能看到“这张图超过预算限制”,避免开发返工。
- SpeedCurve / Calibre：可视化追踪预算变化,支持告警。
标准工作流
- 需求阶段：产品经理在PRD里标注“此功能会增加XKB资源”,团队一起评估是否值得。
- 设计阶段：设计师导出图片前先压缩、用WebP格式，控制每张图≤50KB。
- 开发阶段：用webpack-bundle-analyzer查JS依赖,把第三方库转成按需加载。
- 测试阶段：CI流水线自动跑性能对比，如果新代码让LCP变差,阻止合并。
- 上线前：用真实用户监控（RUM）工具（如Google Analytics Speed、New Relic）看真实数据。
问：没有性能工程师，普通开发能做吗？
答：可以，主流CI平台（GitHub Actions、GitLab CI）都有免费性能插件，配置文本即可，最难的是第一条：所有人同意“性能也是优先级”。
常见问题解答
Q1：定好的预算太紧，产品功能做不全怎么办？
A：优先做“性能性价比高”的功能，比如一个轮播图增加500KB但转化率只提升0.1%，不如优化商品详情页的加载速度（转化率可能提升3%）。
Q2：预算太松，团队会不会性能越来越差？
A：会的，建议设置“阶梯预算”：第一版1.5MB，每两个月收紧500KB，直到达到目标，同时设置“允许超目标临时加班”的机制，但要记录原因,算入技术债。
Q3：移动端和PC端预算要分开吗？
A：必须分开，移动端建议总大小700KB~1MB，PC端可以到2~3MB，移动端LCP建议≤2.5秒，PC端≤2秒。
Q4：图片怎么纳入预算？
A：对图片建立“资产清单”，每张图片算体积，建议图片占总预算的30%~40%（比如1MB中300KB~400KB给图片）,超出部分必须裁切或压缩。
Q5：第三方脚本（如分析工具、广告SDK）也算进预算吗？
A：算，且是最大陷阱，很多网站被第三方脚本拖慢，预算里必须单独给第三方留5%~10%空间,并定期审核哪些不必要的脚本可以移除。
从预算到性能文化
性能预算不是一份写死的文档，而是一套持续决策的机制,它的终极目标是：
- 让每个角色（PM、设计、开发）在做决策时，自然问：“这样做会增加多少性能成本？”
- 把“优化”从个人英雄主义（某大佬加班改代码）变成制度化流程。
下一次当你看到团队计划增加一个新功能时，请先问：
“这个功能在预算表里的‘价格标签’是多少？我们买得起吗？”
最终提醒：预算可以动态调整，但“有问题必须回滚”的原则不能丢，给团队一个性能预算是投资,不是限制。
延伸阅读（无外链）
- 搜索引擎可以搜索“Core Web Vitals 官方文档”了解指标细节
- 搜索“Lighthouse 预算配置”获取技术实现方法
（完）