Google把软导航指标塞进了CrUX，单页应用的体验账本要重算了

searchenginejournal.com报道，Google已将一组实验性的Core Web Vitals指标加入Chrome UX Report（CrUX），这批指标专门用来统计应用内的页面切换行为，也就是所谓「软导航」。报道同时提到，Search Console预计会跟进这一变化。目前这些指标仍处于实验阶段，不是正式排名信号。

这件事的分量不在「多了几个数字」，而在于Google开始把「不刷新页面的页面跳转」纳入真实用户数据的采集范围。过去十几年，Core Web Vitals的整套测量逻辑默认每次导航都会产生一次新的文档加载。单页应用、客户端路由、局部渲染这些做法，恰好绕开了这个前提。

软导航到底指什么，为什么以前测不到

软导航指的是用户点击站内链接后，浏览器没有发起完整的文档请求，而是由JavaScript接管、替换部分内容并更新URL和历史记录。React Router、Vue Router、Next.js的客户端跳转都属于这一类。

传统CrUX数据的采集依赖页面加载事件。软导航不触发这些事件，于是用户在站内点了五次链接、看了五个页面，在CrUX眼里可能只算一次访问。这意味着一个体验很差的客户端路由实现，在Core Web Vitals报告里可能看起来毫无问题。指标和真实感受之间出现了系统性偏差，而受影响的恰恰是交互最复杂的那类站点。

对站长和营销人员的实际影响

短期内不会有排名波动。实验性指标进CrUX不等于进排名算法，Google在这类事情上一贯是先采集、再观察、最后才可能纳入评估。真正需要留意的是Search Console跟进之后会发生什么：一旦软导航数据出现在报告里，很多站点的性能画像会变得和现在不一样。

具体来说，以下几类站点值得提前关注：

• 内容型站点用客户端路由做站内跳转的，过去可能被低估的交互延迟会浮出水面
• 电商和SaaS产品里大量使用局部刷新的页面，其真实响应表现此前基本没被CrUX覆盖
• 把Core Web Vitals当作KPI来汇报的团队，历史数据的可比性会受影响，需要向相关方解释口径变化

反过来说，如果软导航指标显示你的客户端路由表现良好，这反而是一个此前拿不到的证明。在预算讨论里，「我们的SPA体验其实不差」这句话，以后可能有数据支撑。

开发者该盯的不是指标本身，是测量口径

软导航的测量比传统导航复杂得多。什么时候算一次导航开始、什么时候算结束、哪些DOM变化算作内容更新，这些定义会直接决定指标数值。实验阶段意味着定义还可能调整，现在围绕具体阈值做优化为时过早。

更务实的做法是检查自己的埋点和RUM方案是否已经在采集软导航数据。如果内部监控和CrUX的口径不一致，等Search Console上线后会出现两套数字打架的局面，解释成本很高。前端团队可以趁这个窗口期，把客户端路由的性能基线先建立起来。

接下来看什么

三个观察点。一是这批实验指标在CrUX里的字段命名和定义是否稳定下来，这决定了第三方工具多久能跟进。二是Search Console的具体呈现方式，是单独开一个报告还是并入现有Core Web Vitals模块，影响的是日常查看习惯。三是有没有站点因为软导航数据暴露问题而做出架构调整，那才是这套指标真正产生行为改变的证据。

在那之前，把这件事当作一个信号：Google对「页面」的定义正在从文档加载转向用户感知的视图切换。这个转向如果走完，受影响的不会只是性能报告。