配了三年 SPA，每次测完首屏就不知道后面怎么样了——Chrome 150 今天把这件事用 Soft Navigations API 彻底接上了

Chrome 150 稳定版发布了一个让整个前端圈等了五年的 API——Soft Navigations API。它解决的问题一句话就能说清楚：从此 Chrome 的性能工具终于看得见 SPA 里每一次路由跳转了。

问题是真实存在的

从 Gmail 到飞书文档，现代 Web 应用几乎全是 SPA。用户点一个链接，浏览器 URL 变了，内容换了，但浏览器认为”页面没换”。这直接导致了一个荒唐的局面：Core Web Vitals 能测首屏，却测不了用户真正在用的那些交互。

拿 LCP 来说，它只在页面初始化时发射。你在 Gmail 里点一封邮件，新内容渲染出来了，但 Chrome 认为这是”同一页”，不会生成新的 LCP 条目。结果 CrUX、PageSpeed Insights、Lighthouse，全都对 SPA 的后续导航视而不见。团队优化了首屏 2 秒，却不知道用户在”跳转列表页→详情页”这条路上实际要等 5 秒。

CLS 和 INP 稍微好一点——它们基于 Event Timing 和 Layout Instability API，理论上可以跨导航切片，但之前没有统一标准来定义”哪段性能数据属于哪一次导航”。团队要么靠框架自己打点，要么干脆放弃测量。

Soft Navigations API 是什么

Chrome 150 引入了一套标准化的 SPA 导航检测机制，定义了什么叫一次”软导航”：

1. 用户操作触发（点击、键盘）
2. URL 发生变化（pushState/replaceState）
3. 产生了可见的内容绘制（paint）

三个条件同时满足，Chrome 就认为这是一次软导航，自动发射 SoftNavigationEntry。

它带来的核心变化是给所有 Performance 条目加了一个 navigationId 标识，让 CrUX 和 RUM 能够把数据归属到具体的某次导航上。

两个新 API，把 SPA 的 LCP 测出来

Chrome 150（origin trial 更早在 Chrome 147 就开始了）引入了两个新的 Performance 条目类型：

soft-navigation：每次软导航完成时发射，包含 navigationId、新 URL 和时间戳，CLS 和 INP 都可以据此切片。

interaction-contentful-paint：每次交互触发了新内容绘制时发射，最关键的是它带有一个 largestContentfulPaint，这就是 SPA 里”相当于 LCP”的东西。SoftNavigationEntry 上还提供了一个 getLargestInteractionContentfulPaint() 方法，可以直接拿到这次导航的 LCP。

这意味着什么？之前 CrUX 里的 LCP 数据全部来自首屏，SPA 的后续体验一直是盲区。现在从 Chrome 150 开始，Lighthouse、PageSpeed Insights、CrUX 都能正确记录 Gmail 列表页、Gmail 详情页、Gmail 搜索结果页各自的 LCP 了。

DevTools 也在跟进

Chrome DevTools Performance 面板在 Chrome 145+ 已经支持在 Live Metrics 和 Trace 视图中显示软导航标记。Chrome 150 之后，这条链路彻底打通——你在 DevTools 里录一条性能轨迹，可以清楚看到每次点击对应哪个 soft-navigation 条目，它的 LCP、CLS、INP 各是多少。

三个坑，踩完再上生产

1. 框架兼容性不是 100%。 三个触发条件必须同时满足才算数。如果你的框架用 replaceState 而非 pushState 更新 URL，或者某些交互只有数据请求但没有可见 paint，Chrome 可能检测不到。Chrome 150 的 origin trial 在 Chrome 147-149 期间跑了三个月，团队在持续迭代检测逻辑。

2. 你需要主动开启。 在 Chrome 里，这不是默认行为。你需要在 chrome://flags 启用 Soft Navigation Feature，或者通过 origin trial 报名。建议先在 staging 环境打开，用 DevTools 验证检测结果是否符合预期，再推到生产。

3. 跨浏览器别指望。 目前只有 Chrome 150+ 支持。Firefox 和 Safari 没有实现。这意味着你的 CrUX 数据会有 Chrome 用户偏差，RUM 方案需要做能力检测，渐进增强必须做。

三步上手

第一步：用 DevTools 验证检测是否正常。 打开 chrome://flags 启用 Soft Navigation，打开 DevTools Performance 面板，录一段你的 SPA 操作轨迹。看 soft-navigation 标记是否出现在每次你认为的”跳转”之后，LCP/CLS 数据是否按导航正确切片。

第二步：接入 PerformanceObserver 读取数据。 用 PerformanceObserver 监听 [soft-navigation, interaction-contentful-paint]，读取每条软导航的 LCP 和 CLS。框架层面，React/Vue/Angular 各自有配套的 web-vitals 软导航实验版本可用。

第三步：对比首屏数据和 SPA 导航数据。 如果你负责一个电商或内容类 SPA，你很可能会发现：首屏 LCP 1.8 秒挺漂亮，但 SPA 列表→详情导航 LCP 4.2 秒。这才是用户实际感受到的重量。

为什么这件事值得现在关注

Chrome 150 是 2026 年 3 月发布的，稳定版到 9 月已经覆盖了相当规模的用户。Google 搜索的排名信号正在逐步纳入 SPA 导航体验——虽然目前主要还是首屏数据，但 CrUX 的 SPA 能力一旦成熟，用 Lighthouse 跑分和真实用户体验之间的偏差会急剧缩小。

前端性能优化这件事，从此不再只靠”首屏快不快”一个数字。SPA 的每一次跳转，才是真实用户每天在走的那条路。

Chrome Platform Status 上 Chrome 151 已在路线图上，预计会带来更多 Performance 条目的 SPA 支持，建议持续关注。