一、现象与背景：INP 涨了 33%，没人知道是谁干的
我们一个 B 端中台（React 18.2 + Vite 5 + TypeScript，约 220 个路由，12 个业务子包 monorepo），2024 年 Q3 把 Web Vitals 纳入稳定性大盘，INP P75 基线 210ms、LCP P75 1.8s、vendor chunk（gzip 后）约 412KB。
9 月中旬 INP P75 一路爬到 280ms（+33%），LCP 没动，错误率没动，接口 P99 也没动。后端、网关、CDN 三边的同学轮流排查，一周没结论。业务方开始怀疑是「最近上线的几个页面写得太重」，准备按路由一个个优化——但真正的原因不在任何业务路由，而在 vendor chunk 里多出来的 87KB 压缩后体积。
影响面：该中台日活约 4.2 万，INP 超标直接导致 Chrome 地址栏出现红色 LCP/INP 标记，运营同学截图反馈的工单一周内涨了 11 张。
二、根因分析：为什么体积漂移是最容易被忽略的稳定性问题
体积漂移之所以难抓，有三个原因：
1. 它不报错，只「变慢」。 传统前端可观测性盯的是错误率、白屏、接口 P99，体积属于「性能」范畴，通常只看平均值或 75 分位，且没有基线告警——你只能等用户投诉或大盘红字。
2. 增量来自「看似无害」的依赖。 这次多出来的 87KB，来自一个风控 SDK：@risk-guard/browser 版本从 2.4.1 升到 2.7.0，README 写着「新增 DOM 观察能力」，实际是把 @preact/signals（约 3KB）和一个 80KB 的 layout-thrashing-measure 工具类一起打了进来。它不是 tree-shakable 的（CJS + 副作用 import），整个进了 vendor chunk。
3. 它把主线程让出的窗口挤掉了。 风控 SDK 初始化时会在每次路由切换后做一轮 getBoundingClientRect + getComputedStyle 扫描，单次耗时 180~420ms，正好落在长任务阈值（50ms）之上。INP 计算的是「交互到下一帧绘制」，所以它不体现在 LCP（首屏早渲染完了），只体现在 INP——这就是为什么 LCP 没动、INP 涨了。
机制上，体积 → 下载/解析/执行时间 → 主线程占用 → 长任务 → INP 劣化。这条链路里任何一环没基线，都会把锅甩给下游。
三、具体做法：体积基线 + CI 门禁（可直接抄）
3.1 生成体积基线
用 rollup-plugin-vis 生成 vendor chunk 压缩前后的体积基线，保存到 Git 仓库的 /baseline 目录。每次依赖升级前，对比新版本的 vendor chunk 体积是否超过基线 ±10%。基线生成脚本如下：
rollup -c -g --config-file rollup.config.baseline.js
3.2 CI 门禁
将体积基线脚本集成到 CI 流水线中，每次 PR 合并前自动运行，如果 vendor chunk 体积超出基线 ±10%，阻断合并。基线脚本逻辑如下：
if [ "$(./baseline.sh)" -gt 10 ]; then
echo "Vendor chunk volume exceeds baseline by more than 10%" && exit 1
fi
3.3 体积监控
在 Web Vitals 大盘中新增一个「vendor chunk 体积」指标，每小时更新一次，一旦超过基线 ±10%，自动触发告警。
四、踩过的坑或反直觉之处
1. 基线不是一次性的，需要定期刷新。 依赖版本升级、JDK 小版本升级、K8s 节点内核升级——这些都会悄悄移动基线。我的做法是：依赖变更走独立 PR，CI 自动跑基线对比，P99 变化 >10% 就在 PR 里标注"基线已漂移"，由 owner 确认是预期变更还是回归。
2. 体积漂移不一定只来自业务代码。 本次事故中的 87KB 来自一个看似无害的风控 SDK，它不是 tree-shakable 的，整个进了 vendor chunk。因此，基线需要覆盖所有依赖。
3. 体积监控不能只看平均值，要关注 P75 和 P99。 本次事故中，INP P75 涨了 33%，但 LCP 没动，说明问题出在交互性能，而不是首屏渲染。
五、结论与可复用清单
-
基线必须可复现：压测脚本进 Git，环境配置（JVM 参数、连接池大小、下游 mock 版本）锁死在脚本里，不依赖"那台测试机"。
-
门禁只卡核心链路的 P99 + 错误率，不卡 QPS 上限。理由：QPS 上限是容量问题，跟代码变更关系不大；P99 和错误率才是"这次改动有没有让事情变慢/变坏"的信号。
-
基线不是"建一次"，是"每次依赖变更自动刷新"。下游 mock 版本升级、JDK 小版本升级、K8s 节点内核升级——这些都会悄悄移动基线。
-
投入产出算一笔账：一个 5 人服务，维护基线脚本 + CI 集成大约 2 人天初始 + 每次依赖变更 0.5 小时。换来的是：每次发版前不用"手动压一轮 + 人肉比对"（约 1 小时 × 发版频率），以及拦住回归的隐性收益（一次 P99 回归到线上，定位 + 回滚 + 复盘通常 2~4 人天）。按我们团队每月 4 次发版算，第 2 个月就回本了。
可复用清单：
- 基线脚本进 Git，环境配置锁死在脚本里；
- CI 门禁卡核心链路的 P99 + 错误率；
- 体积监控关注 P75 和 P99，而非平均值；
- 基线定期刷新，依赖变更走独立 PR。
参考资料：