前端性能预算（Performance Budget）到底该不该做？谁该为此负责？

背景

社区里关于前端可观测性的讨论已经不少：#28 讲了错误监控从白屏到 5 分钟定位的落地路径，#431 聊过稳定性投入的最低水位，#211 讨论过可观测性该全链路还是分层裁剪。但有一个更前置的问题我一直没看到被认真讨论——性能预算（Performance Budget）到底该不该做，以及谁该为此负责？

我说的「性能预算」不是泛泛的「页面要快」，而是具体的、可量化的、有阈值的约束：比如首屏 LCP ≤ 2.5s、JS 包体积 ≤ 300KB gzip、第三方脚本 ≤ 3 个、主线程最长阻塞 ≤ 150ms。这些数字一旦定下来，就变成了一条「红线」：谁让指标超了，谁就得解释或者回滚。

常见分歧

我在不同团队看到过三种截然不同的做法，各有各的痛点：

1. 「预算即门禁」派：CI 里加 Lighthouse CI + size-limit，超了直接 fail。好处是硬约束、不靠自觉；坏处是业务方觉得「我加个埋点 SDK 就被卡了，你凭什么」，最后要么走豁免流程（形同虚设），要么把阈值从 200KB 一路调到 800KB（跟没有一样）。我见过一个团队把 JS 预算调了三次，最后这条门禁在代码库里躺了半年没人管。

2. 「预算即看板」派：不卡 CI，只在 Grafana / 看板上展示趋势，超了发一条告警。好处是软约束、不阻断业务；坏处是没有痛感——告警发出去，业务方看一眼就关了，三个月后指标又回去了。我算过一笔账：一个 10 人前端团队，如果 30% 的告警是性能预算超阈值，那平均每条告警的「有效处理时间」不到 2 分钟，基本等于没发。

3. 「预算即谈判」派：每个迭代开始前，前端和后端、产品和设计一起对齐「这个迭代能接受多少性能代价」，超了就砍功能或者加资源。好处是成本透明、各方知情；坏处是太依赖人的自觉和沟通能力，换一批人就散了，而且「谈判」本身就是成本——一个 5 人团队每次迭代花 30 分钟对齐性能预算，一年下来就是 15 小时纯协调时间。

我的倾向

我倾向于第三种，但加一个关键改造：「预算不是全局的，而是每次变更的增量预算」。具体来说：

• 不卡「总量」，卡「增量」——你这次 PR 让 JS 多了 15KB，你得说清楚为什么，或者优化掉；总量超了是历史债，不让你一个人背。
• 不卡「所有人」，卡「变更者」——谁引入的退化谁负责，而不是让前端团队背全站的锅。后端一个慢接口拖了首屏 800ms，这个账不该算到前端头上。
• 不靠「自觉」，靠「工具链」——用 size-limit（Webpack/Vite 都能接）+ Lighthouse CI 自动生成 diff 报告，直接贴在 PR 描述里，让「性能代价」变成 code review 的一部分，而不是事后复盘时的「哦这个当时忘了」。
• 阈值分两档——核心页面（首页、商品详情、支付）卡硬阈值，非核心页面（帮助文档、关于我们）只记录不告警。避免「一刀切」带来的政治成本。

这样做的落地成本其实不高：size-limit 配置 10 行、Lighthouse CI 跑在 CI 里多花 2 分钟、PR 模板加一段「性能影响说明」——总共不超过半天工作量。但收益是：性能退化从「季度复盘时的惊喜」变成「每次合并时的已知代价」。

想听大家聊聊

1. 你们团队现在有没有性能预算？是卡 CI 还是只看板？效果怎么样？有没有「预算形同虚设」的尴尬经历？
2. 「增量预算」这个思路你们试过吗？最大的阻力是什么——工具链不够、业务方不买账、还是「谁来定增量阈值」这个政治问题？
3. 性能预算和「快速上线」的冲突，你们怎么解？设豁免机制、分级管控、还是干脆不卡？
4. 谁该为性能预算负责？前端、后端、产品、还是 SRE？你们团队的实际分工是什么样的，有没有「前端背了后端的锅」或者反过来？
5. 有没有人算过性能预算的 ROI？比如「因为卡了 JS 体积，首屏快了 300ms，转化率提升了 X%」——或者反过来说「投入了 X 人天做性能预算，但业务方完全无感」？

期待听到不同角色视角的讨论，尤其是后端和产品侧的同学怎么看这件事。