2026 年 9 月我们给一个客户的官网加性能预算，第一次跑 CI 就拦下了两个提交：一个把 JS 包从 680KB 顶到 1.1MB，另一个加了四张大图。没有预算，这两件事在评审时都不会被发现。
为什么需要预算
性能是慢慢变差的。每次加一个脚本、一张图、一个统计工具，单独看都合理，加起来就超标了。
等到用户抱怨或者指标掉出合格线，已经很难回溯是哪个提交造成的。
预算就是在每次提交时设一道线，超过就得说清理由。
定哪四个数
第一个，首屏 JS 体积。我们的默认线是 300KB，压缩后。软件官网通常够用。
第二个，首屏图片总量。默认 500KB，超过就要换格式或者裁尺寸。
第三个，请求数。首屏不超过 40 个请求，超过多半是图标、字体、统计拆得太碎。
第四个，三个核心指标的实验室值。LCP 2.5 秒、INP 200 毫秒、CLS 0.1。
怎么落地
CI 里跑 Lighthouse CI，对核心页面测三次，取中位数，和预算比。
PR 里自动贴对比，说明哪个指标超了、超了多少。超过就阻塞合并，或者要求负责人写明原因。
我们通常给两个页面设门禁：首页和核心产品页。这两个页面决定了大部分流量和转化。
超了怎么办
先看是真超标还是误报。Lighthouse 波动大，一次超标可以重跑确认。
真超标就两条路：改回提交，或者调预算。调预算要有人批，而且要在 PR 里留下记录。
我们的规矩是预算每季度可以调一次，平时只降不升。
怎么跟不写代码的人解释
预算这个说法对业务方不直观。我们换个说法：这个页面在手机上打开不能超过三秒，超过就要改。
然后把目标和预算数字对应起来，让对方知道 300KB 的 JS 大概对应多少秒。
有了这个换算，评审时说这个库加进来会让首屏慢半秒，比说超过预算了有效得多。
一个真实的变化
2026 年 5 月预算上线前，这个站的 JS 从一年前的 400KB 涨到 1.2MB，没人说得清怎么涨的。
上了预算之后三个月，包体回落到 700KB 左右。不是做了大重构，是每次提交都被迫想一下这个依赖值不值。
一个态度
性能预算的本质是流程，不是技术。它把性能从上线后才发现的问题，变成提交前就要面对的问题。
没有流程，优化就是一阵风。做完一次冲进合格线，半年后又回到原点。
设定预算这件事，一个下午就能做完。真正难的是坚持执行，尤其是业务方催着上线的时候。
元析智能
为软件公司做 SEO 和 GEO 优化