配了三年 SPA，每次路由切换都是性能盲区——Chrome 今天把这件事彻底接上了

配了三年 SPA，每次路由切换的性能数据都像蒸发了一样——你看得见 Lighthouse 分数，看不见用户点完那个「下一步」按钮之后页面到底卡了多久。这不是你的工具不够好，是浏览器从根上就没把 SPA 里的「下一页」当「页面」看。今天 Chrome 把这件事用两个新 API 从根上修了。

十年盲区是怎么来的

你点一下 SPA 里的链接，浏览器地址栏变了，页面内容也变了，但浏览器认为：你还在同一个网页上。Core Web Vitals 只在「网页加载」时测量，「网页内切换内容」这件事从来不在指标体系里。所以 LCP 只算首屏，INP 只算第一个交互，其余全靠猜。

这造成的结果：团队花大力气优化首屏加载，路由 B/C/D 的卡顿没人知道。真实用户点击「下一步」等了 800ms，没人能拿出数据证明这件事。Google Search Console 看不到这段体验的评分，因为它根本没被测量。

两个新 API 把这件事接上了

Chrome 正在推进两个新 API，目标是把 SPA 里的路由切换也变成可测量的「软导航」。

PerformanceSoftNavigation：让浏览器能识别「软导航」——由 JavaScript 拦截点击、更新页面内容但不刷新文档的路由切换。框架（React Router、Vue Router 等）在切换时调用这个 API 通知浏览器，浏览器就知道：这是一次新导航，开始新的一轮测量。

InteractionContentfulPaint：对应传统 LCP 在硬导航里的行为——测量软导航之后新内容的首次绘制。但它只在软导航场景下才生效，专门解决「路由 B 的首屏渲染完成了吗」这个问题。

两个 API 配合，把 SPA 的性能指标体系从「只看第一页」扩展到「每次路由切换都能独立打分」。

具体怎么落地

Chrome 147 开始 Origin Trial，你可以在 Chrome 里开启体验。如果你用的是 web-vitals 库（从 v6.0.0 起支持），接入成本很低：

import { onLCP, onINP } from web-vitals;

function sendToAnalytics({ name, value, navigationId }) {
  // 每个导航独立上报，navigationId 区分不同路由
  fetch(/analytics, {
    method: POST,
    body: JSON.stringify({ metric: name, value, navigationId })
  });
}

// 传统硬导航指标（首屏）
onLCP(sendToAnalytics, { reportSoftNavs: false });
onINP(sendToAnalytics, { reportSoftNavs: false });

// 软导航指标（路由切换）
onLCP(sendToAnalytics, { reportSoftNavs: true });
onINP(sendToAnalytics, { reportSoftNavs: true });

reportSoftNavs: true 开启后，指标报告会带上 navigationId，你的分析系统就能把每个路由的性能拆开看。

目前只有 Chromium 浏览器支持这两个 API，Safari 和 Firefox 还没跟进。但 Chrome 的市占率足够让这个信号变得有意义——你终于能拿到大部分用户的路由级性能数据，而不是继续在黑暗里猜。

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

INP 已经替代 FID 成为 Core Web Vitals 指标两年多了，但 SPA 的 INP 测量一直有问题：用户点路由切换，INP 不会更新；你看到的 INP 始终是首屏那个数字。这让 SPA 的 INP 优化像蒙着眼睛投篮。

Soft Navigations API 补上了这个漏洞。真实影响有几个层面：

产品层面：你终于能用数据证明「路由 B 的切换比路由 A 慢 300ms」，而不是靠用户投诉驱动优化。

SEO 层面：Google 表示 Core Web Vitals 会影响排名，而 SPA 的软导航性能从来没进过评分体系。一旦 API 稳定，Google 爬虫可能逐步把软导航指标纳入排名因子。

团队层面：Lighthouse 分数再也不能代表用户的真实体验了——得看 CrUX 里按路由拆分的数据。工具链的判断逻辑要随之更新。

三步下一步

第一，在 Chrome 里开启 Origin Trial 验证你的 SPA。访问 chrome://flags/#enable-soft-navigation 打开这两个 API，用 web-vitals 的软导航分支在本地跑一遍，看看各路由的 LCP/INP 真实数字。

第二，把路由级性能数据接入你的 RUM 系统。在 analytics 请求里加上 navigationId，这样你在 dashboards 里可以按路由筛选性能数据。DataDog、Amplitude 这类工具都支持自定义事件属性。

第三，把 Lighthouse 报告和 CrUX 路由数据对比看。Lighthouse 跑的是首屏，CrUX 里现在能看到的也是首屏——两者之间差距有多大，路由级数据补上来之后才会真正暴露。

性能优化这件事，最怕的不是慢，是看不见。Chrome 这次把灯开了，先看见的人先动手。