前端性能预算是什么？团队如何用它约束页面变慢？

简化版

前端性能预算是给页面性能设定可量化上限，例如首屏 JS 不能超过 200KB、LCP 不能超过 2.5s、关键请求不能超过 20 个。它不是单次优化技巧，而是一套持续治理机制：先确定用户体验目标，再拆成资源体积、请求数量、核心 Web 指标和运行时开销，接入 CI、监控和评审流程，超过预算就阻止发布或要求说明。

详细版

性能预算的价值是把“页面感觉慢”变成“哪些指标不能突破”。常见预算包括四类：资源预算、体验指标预算、运行时预算和第三方脚本预算。

预算类型	示例	作用
资源体积	首页 JS gzip 后不超过 200KB	防止包体积悄悄膨胀
请求数量	首屏关键请求不超过 25 个	降低网络排队和阻塞
Web 指标	LCP < 2.5s、INP < 200ms	约束真实体验
运行时	单个长任务不超过 50ms	防止主线程卡顿

落地时不能只写在文档里。更好的方式是在构建阶段用 bundle analyzer、Lighthouse CI、PageSpeed、WebPageTest 或自研脚本检查预算；在线上用 RUM 采集真实用户数据；在 Code Review 里要求新增大依赖、第三方脚本和首屏逻辑说明性能影响。

{
  "budgets": [
    { "path": "/", "resourceSizes": [{ "resourceType": "script", "budget": 200 }] },
    { "path": "/", "timings": [{ "metric": "largest-contentful-paint", "budget": 2500 }] }
  ]
}

面试回答性能预算，要强调它是“团队约束机制”，不是某个单点优化工具。

完整版教学

一、为什么需要性能预算

前端性能退化通常不是一次大事故，而是很多小改动慢慢叠加：加一个埋点 SDK、引入一个 UI 库、首页多一个接口、首屏组件里多做一点计算。每次看起来都不大，但几个月后页面就明显变慢。

性能预算的核心作用，是把这种隐性退化显性化。它让团队在开发阶段就知道“这个改动有没有让页面超过可接受范围”。

二、性能预算不是只看包体积

很多同学会把性能预算理解成“限制 bundle 大小”。包体积确实重要，但它只是其中一类。

完整预算通常包含：

资源体积：JS、CSS、字体、图片、第三方脚本大小。
请求数量：首屏关键请求数量、域名数量。
体验指标：LCP、CLS、INP、TTFB、FCP。
运行时开销：长任务数量、主线程阻塞时间、内存增长。
业务关键链路：搜索页、详情页、下单页、登录页等核心路径。

三、预算要按页面类型分层

不同页面不能套同一套阈值。营销落地页、后台管理页、搜索结果页和可视化大屏对性能的要求不同。

页面类型	预算重点	原因
首页/落地页	LCP、JS 体积、图片体积	直接影响转化
后台页面	INP、长任务、表格渲染	用户操作频繁
内容页	首屏、SEO、字体加载	阅读体验重要
可视化页	内存、Canvas/WebGL、计算任务	容易运行时卡顿

四、CI 如何卡预算

CI 适合卡确定性较强的指标，比如产物体积、依赖变化、Lighthouse 实验室分数和关键资源数量。真实网络会抖动，所以 CI 阈值不要太窄。

npm run build
npx lighthouse-ci autorun
npx bundlesize

如果构建产物超过预算，可以让流水线失败；如果 Lighthouse 指标轻微波动，可以设置警告阈值和多次取中位数。

五、线上监控如何补足 CI

CI 环境是实验室数据，设备、网络、缓存状态都比较固定。真实用户可能来自低端手机、弱网、旧浏览器和不同地域，所以还需要 RUM。

RUM 可以采集真实 LCP、INP、CLS、资源加载、长任务和错误数据。团队更应该看 p75 或 p90，而不是平均值，因为平均值容易掩盖慢用户。

六、预算超了怎么办

预算超了不一定意味着立刻禁止上线，但必须有决策过程：

能优化就优化，例如拆包、移除无用依赖、延迟加载。
业务收益明显时允许豁免，但要记录原因和过期时间。
第三方脚本新增必须说明用途、加载时机和降级方案。
预算长期不合理时调整阈值，但不能让阈值跟着退化无限放宽。

七、常见误区与追问

误区：性能预算就是限制 JS 大小。 JS 大小只是资源预算，真正的预算还包括用户体验指标、运行时开销和第三方脚本。
误区：Lighthouse 分数过了就代表线上没问题。 Lighthouse 是实验室数据，线上还要看真实用户的 p75/p90 指标。
误区：预算越严格越好。 阈值过严会让团队绕过规则，应该根据页面类型和业务目标设置。
追问：预算超过后一定要阻断发布吗？ 核心页面和明显退化可以阻断，低风险页面可以先警告，但要有负责人和修复计划。
追问：为什么看 p75 而不是平均值？ p75 更能代表大多数用户的较差体验，平均值容易被快设备拉低。
追问：第三方脚本怎么纳入预算？ 单独统计大小、加载时机、长任务和错误率，新增脚本要经过评审。

八、加强记忆

把性能预算记成“先定红线，再自动检查”。它关注资源、体验、运行时和第三方脚本；CI 负责卡可重复指标，RUM 负责看真实用户；预算超了要优化、豁免或调整，但不能让性能退化悄悄发生。

简化版

详细版