前端性能预算怎么落地：图片、脚本与交互延迟阈值

性能预算不是把“页面必须很快”换成一句更专业的口号，而是先规定：一张首屏图最多多大、初始脚本最多传多少、主线程一次最多阻塞多久，以及上线后用什么数据判断它是否超线。落地时建议按“资源、执行、体验”三层拆开，再把每层接到 CI 和真实用户指标。

先把预算拆成三层，再谈阈值

一个电商首页和一个后台表格不应共用同一条线。先写清页面的关键任务：用户是先看商品图、先输入搜索词，还是先打开数据表。随后建立一张预算表，至少记录“预算对象、目标值、观测方式、超线动作”。

一个可执行的起点是：首屏关键图片 200KB、页面图片总量 800KB、初始 JavaScript 170KB（压缩传输口径），单次长任务尽量不超过 50ms。它们不是行业通用真理，而是方便团队先发现回归的工程线；页面复杂度、网络和设备分布改变后，应根据数据调整。

图片预算要同时约束体积、尺寸和加载时机

只设置“图片不能超过 200KB”还不够：一张被 CSS 缩到 320px 的 2400px 原图，既浪费传输，也可能拖慢 LCP。为每个图片组件补三项规则：使用响应式尺寸与现代格式；给首屏关键图明确宽高或 aspect-ratio；非关键图默认延后加载。

首屏主图才使用高优先级，列表图片按实际可视区域加载；否则“优化 LCP”的属性会反过来争抢带宽。字体也要纳入同一张表：只保留实际字重，避免为了一个标题加载整套字符集。

脚本预算要看主线程，而不是只看打包体积

JavaScript 压缩后只有 170KB，并不代表一定流畅。解析、编译、执行和第三方脚本都发生在主线程；一个体积不大的同步初始化也可能把输入事件推迟。预算应至少记录初始脚本传输量、页面启动阶段最长任务、第三方脚本数量和它们的责任人。

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // 长任务超过预算时只采样上报，避免监控代码再次阻塞主线程。
    if (entry.duration > 50) {
      navigator.sendBeacon('/perf/long-task', JSON.stringify({
        duration: Math.round(entry.duration),
        name: entry.name
      }));
    }
  }
}).observe({ type: 'longtask', buffered: true });
// 生产环境应限制采样率，并在页面卸载时保持上报可完成。

PerformanceObserver 适合观察已经产生的性能条目，但并不是所有浏览器或条目类型都完全一致，代码要允许不支持时安静退出。第三方脚本则应独立登记预算，不能把它们的成本隐藏在“业务包”里。

用 LCP、INP、CLS 和分位数判断是否真的达标

Core Web Vitals 给了很好的共同语言：LCP 的良好线是 2.5 秒以内，INP 是 200 毫秒以内，CLS 是 0.1 以内，通常看移动端和桌面端各自的第 75 分位。不要把一次 Lighthouse 分数当成线上结论：实验室环境适合稳定复现，INP 需要真实交互，线上数据才会暴露低端设备、慢网络和长页面滚动中的问题。

资源层可以用 Resource Timing 找出慢资源，体验层用 RUM 聚合分位数；同一版本至少保留设备类型、页面模板、网络条件和发布版本。这样看到 INP 超线时，才能进一步判断是点击处理器过重、长任务挤占，还是服务端响应改变了交互路径。

把超预算处理写成发布清单

每次发布只问“性能分数多少”很难行动。可以按下面顺序处理：资源超线先查图片候选尺寸和重复依赖；脚本超线先拆同步初始化、延后非关键模块；LCP 超线检查关键资源优先级；INP 超线找最长事件处理和第三方回调；CLS 超线补尺寸占位并排查异步插入。

CI 中固定设备、网络和页面路径，超过硬预算就阻断合并；接近预算线则给出警告。线上按版本看 75 分位，连续两个采样窗口超线才升级为回滚或专项优化，避免因为单个异常样本频繁扰动发布。

常见问题

预算应该按页面还是按整个站点设置？

先按页面模板设置，再汇总站点趋势。首页、详情页和后台工作台的关键任务不同，共用一条线会让预算失去解释力。

只有 Lighthouse 报告，能不能判断 INP？

不能直接等同。实验室可以用 TBT 观察主线程阻塞作为代理，但 INP 需要真实交互数据，最终应在线上按设备分组统计。

图片预算和 LCP 超线时先改哪一个？

先确认 LCP 元素。如果它就是首屏图片，优先检查尺寸、格式、响应式候选和加载优先级；如果 LCP 是文本，则应转查字体、CSS 阻塞和服务端响应。

性能预算是不是越低越好？

不是。过低的线会诱导团队牺牲必要功能，或者只在实验室里“过关”。预算应能解释用户任务，并以真实设备的分位数持续校准。