一、现象与背景：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