你以为 Lighthouse 分数挺好上线用户还说卡？今天 Performance Budget 把这件事从制度上彻底变了

你以为 Lighthouse 分数挺好上线用户还说卡？今天 Performance Budget 把这件事从制度上彻底变了

配了三年性能优化，每次提测前都会把 Lighthouse 跑一遍——分数绿了，心里就踏实了。结果上线第一天，用户反馈「页面好慢」，一看 CrUX 数据：p75 LCP 3.8 秒，比测试环境高了整整两秒。

这不是你优化没做到位，是 Lighthouse 的测量环境从根上就不是用户的真实场景。

Lighthouse 跑的是 Lab Data——实验室数据。它模拟的是空缓存、固定节流 CPU（4x slowdown）、固定网络（4G Fast），没有任何第三方脚本，没有用户 cookie，没有并发标签页。而真实用户跑在真机上，4G 变 3G，切到后台再切回来，Chrome 扩展在跑，DevTools 开着。Google 自己数据显示，30% 到 40% 的页面 Lab 和 Field 偏差超过 30%。

你的 Lighthouse 过了，生产还在卡。

Field Data 靠 CrUX，但有个致命问题：窗口 28 天。你 9 月 1 日上了优化，CrUX 数据要等到 9 月底才能反映变化。这一个月里，你等于在黑屋子里做手术——凭感觉，等命运。

三层接起来，才算把性能这件事真正管住。

第一层：Build-time 卡死。Lighthouse CI 的 assertMatrix 把断言路由到不同入口，可以给首页配 LCP < 2.5s，给 Checkout 配 TBT < 200ms，配完 Push 就触发，不通过不让合并。配置写在 .lighthouserc.json 里，不需要额外 UI。

{
  "ci": {
    "collect": { "url": ["http://localhost:3000/"] },
    "assert": {
      "assertions": {
        "categories:performance": ["error", { "minScore": 0.9 }],
        "first-contentful-paint": ["error", { "maxNumericValue": 2000 }],
        "largest-contentful-paint": ["error", { "maxNumericValue": 2500 }]
      }
    }
  }
}

第二层：Field 看真用户。CrUX 数据 28 天窗口是硬伤，但你可以在页面里埋一个轻量 RUM，直接上报真实用户指标到自己数据平台，不需要等 Google 更新，就能看到优化有没有在跑。web-vitals.js 三行代码接进来，48 小时内就能拿到第一批真实数据。

import { onLCP, onINP, onCLS } from web-vitals;

function sendToAnalytics({ name, value, id }) {
  navigator.sendBeacon(/analytics, JSON.stringify({ metric: name, value, id }));
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

第三层：制度层。Performance Budget 是把性能当成服务协议来签——不是「建议」，是「合同」。谁的 commit 拖慢了 p75 LCP，谁的 PR 负责修。压线不过的，CI 自动 halt，不接受「下次再优化」的借口。

三个坑要注意：Lighthouse CI 跑的还是 Lab 数据，对第三方脚本的测量能力有限；CrUX 窗口 28 天，优化效果要耐心等；如果你没有自己的 RUM 数据，可以先用 Lighthouse CI 顶住 Build-time，等 CrUX 反馈上来再调整阈值。

三步下一步：查一下自己的 CrUX Dashboard，看 Field p75 和 Lab 分差多少；把 Lighthouse CI assertMatrix 配到项目里，先跑一轮基线；再选一个指标（推荐 LCP）配 Budget，上线第一天就监控真实数据。