你的 Lighthouse 分数很好看，但那个慢得要死的路由切换从来没被算进去过

你的 Lighthouse 分数很好看，但那个慢得要死的路由切换从来没被算进去过。

不是工具不努力，是工具以前根本没有这个数据。

Chrome 151（稳定版 2026 年 7 月 28 日）给 Performance Timeline 新增了两类条目：soft-navigation 和 interaction-contentful-paint，web-vitals v6（2026 年 7 月 21 日）第一时间接了进去。

这意味着：一个单页应用里的每一次客户端路由切换，现在有了自己的 LCP、INP、CLS 数据，而不是只能混在整个会话里被平均掉。

问题是：SPA 的路由从来没人量过

传统页面加载有完整的 Core Web Vitals——LCP、INP、CLS 都有，Performance API 全程追踪。

但 SPA 不一样。点击一个链接，URL 变了，屏幕重新渲染了，浏览器没有发起新的导航请求，旧的指标管道不知道”这里发生了一次页面切换”。整个会话只有一个 document timing origin，所有性能数据都挂在最初那个 URL 下面。

结果就是一个 React 应用可以有很漂亮的首屏 LCP，但某个关键用户流程的页面切换可能是全应用最慢的操作——只是从来没有人看见过它。

Chrome 151 做了什么

浏览器现在会在检测到”用户交互触发的同文档路由变化”时，生成一个 soft-navigation PerformanceEntry，建立新的 timing origin，并让后续的 LCP、INP、CLS 都关联到新的活跃路由上。

interaction-contentful-paint 则是对这个路由上”交互触发的内容渲染”的测量——即使内容是通过 fetch 异步拉回来的，也能量到。

配合 web-vitals v6，一行配置就能拿到这些数据：

import { onSoftNavigation } from 'web-vitals';

onSoftNavigation({ softNavigationAbove: 'paint' }, ({ value, entries }) => {
  console.log('Route LCP:', value, 'entries:', entries);
});

迁移要小心，别把数据弄乱了

CSS Wizardry 的 Harry Roberts 专门发了文章警告这件事：新旧两套数据并存时，很容易出现双重计数或数据断裂。

同一个路由切换，旧的 RUM 可能在发”虚拟页面”事件，新的 Chrome 在发 soft-navigation 事件，如果两个都进了仪表盘，percentile 会莫名其妙变差——不是因为用户体验差了，是因为数据覆盖面变了。

他的建议是：新旧并行跑，对比 reporting rate、metric completion 和数据分布，确认两边对得上之后，再做单向切换。同时保留浏览器版本、web-vitals 版本、路由分类这些维度，方便回溯。

另外 web-vitals v6 还有几个相关改动：

• requestIdleCallback 等待时间上限改为 1 秒，防止空闲回调跑太久
• includeProcessedEventEntries 默认改为 false
• bfcache 恢复后的短 INP 交互现在能正常上报了
• v6.0.1 加了 PerformanceObserver 环境守卫

这会改变优化策略吗？

可能会。

以前慢的路由切换被全会话数据稀释了，你不知道哪个页面的切换在拖后腿。现在有了 per-route 指标，p75-p95 的 INP 分位点里可能会出现一些你完全没意识到的慢路由。

如果你的分析平台支持按 data-cpu-tier（Chrome 152 CPU Performance API） + soft-navigation 双维度切分，就能看出低性能设备上哪些路由是重灾区——不是靠猜，是靠真实用户数据。

Chrome 151 目前只有 Chromium 支持，Safari 和 Firefox 暂无计划。多数团队会有一段时间的双轨报告期，这反而是个做 A/B 对比的好窗口。

下一步：检查你的 RUM 是否接了 web-vitals v6，如果没有，先跑起来看你的 SPA 里真实路由切换的 LCP 和 INP 是多少。你可能会发现一些从来没被注意到的慢路由。