CrUX加了软导航版的Core Web Vitals，单页应用的分数会怎么变

摘要：Chrome在10月13日的CrUX数据里加了三个实验指标，把单页应用里不刷新页面的站内跳转也算进LCP、INP、CLS。大约七成网站几乎没有这种跳转，分数不会变；软导航占一半以上的站，LCP达标率能从26%涨到87%。全网Core Web Vitals达标率从55.9%变成59.5%，涨了3.6个百分点，官方写的6.4%是相对涨幅。现有的稳定指标暂时不变，Search Console计划在2027年5月指标转正后切换。

做独立站的人，多少都被Core Web Vitals折腾过。分数不达标，PageSpeed里一片红，开发说已经优化到头了，老板问为什么还是不及格。

如果你的站是用React、Vue、Next.js这类框架做成单页应用的，这里面有一部分不及格其实冤。10月13日，Chrome团队在CrUX（Chrome用户体验报告）里加了三个实验指标，专门修正单页应用一直被算错的问题。Search Engine Journal第一时间做了报道，原始信息来自Chrome团队Annie Sullivan在web.dev上发的博客。

这篇把这次变化讲清楚：加了什么、什么算软导航、哪些站会变、分数怎么变，以及站长现在要不要动。

这次CrUX到底加了什么

CrUX是Google从真实Chrome用户那里收集来的性能数据，Search Console的核心网页指标报告、PageSpeed Insights里“真实用户体验”那一块，用的都是它。所以CrUX怎么算，基本就决定了你在Google那边看到的分数。

这次新增的是三个字段，和现有的三项指标一一对应：

测量的东西和原来一样，还是加载速度、响应速度、视觉稳定性，区别只在于把软导航也当成一次独立的页面访问来算。

数据从10月发布的CrUX起就能用，渠道有三个：BigQuery数据集、CrUX API和CrUX History API。不写代码的话，Google自己的CrUX Vis工具加了一个“包含软导航”的开关，打开就能看同一个网站两种口径的对比。

有一点要先说清楚：Google现有的稳定指标这次没有动。PageSpeed Insights、Search Console里看到的分数，目前还是老算法。新指标先以实验身份并行公布，Chrome的目标是2027年5月结束实验阶段，之后Search Console会改用新数据。

什么样的跳转算软导航

传统网站每点一个链接，浏览器就向服务器要一个新页面，整页重新加载，这叫硬导航。单页应用不一样，第一次打开时加载一整套程序，之后在站内点来点去，页面并不刷新，而是由JavaScript把内容换掉、把地址栏的网址改掉，这就是软导航。

在新指标出来之前，CrUX只认得硬导航。用户在单页应用里点了十个页面，CrUX只记录最开始那一次加载，后面九次跳转里发生的所有交互和布局偏移，全都算在落地页头上。打个比方，就像一个人逛商场逛了一下午，最后把所有排队的时间都记在了进门那一刻。

Chrome给软导航定了三个条件，同时满足才算：

• 由用户的操作触发，比如点击，而不是页面自己跳。
• 地址栏里的网址发生了用户看得见的变化。
• 这次操作带来了一次可见的绘制，也就是页面内容确实变了。

这套判定由Soft Navigations API负责，Chrome 151起默认开启，这个版本是7月28日发布的。官方文档也承认，这个定义会有误判：有些用户觉得是换页了、但不满足条件的情况会漏掉，有些只是局部更新、却改了网址的交互会被算进来。有疑问可以去规范的GitHub仓库提反馈。

还有一个容易忽略的细节：只有Chrome 151及以上版本的用户会上报软导航数据，其他浏览器和旧版Chrome不会。所以新指标的样本是全部Chrome用户里的一部分，而且会随着用户升级慢慢变多。

哪些站会变，哪些站不会

先说结论：大多数网站不会有任何变化。Annie Sullivan在博客里说得很直白，如果你的网站不用JavaScript动态替换内容、更新网址，就别指望指标有变化。

Chrome按每个网站的软导航占全部页面浏览的比例做了分组，数据是这样的：

反差很明显：全网只有一成左右的站重度依赖软导航，可到了头部大站，这个比例升到三四成。大平台、大应用更爱用单页架构，这也说得通。

放到外贸和独立站的场景里，可以粗略这样判断：

• 用WordPress传统主题、Shopify官方主题建的站，每次点击都是整页加载，基本属于不受影响的那七成。
• 用Next.js、Nuxt、Gatsby这类框架做的站，或者走无头电商路线、前台用Shopify Hydrogen之类方案的，很可能有大量软导航，属于会变的那一类。
• 有些站是混合的，首页和产品页整页加载，但筛选、翻页、切换规格时用JavaScript改网址，这部分也会被算成软导航。

不确定自己属于哪种，最简单的办法是打开Chrome开发者工具的性能面板，Chrome已经在实时指标视图里标出软导航。也可以在控制台粘贴下面这段代码，然后在站内点几个链接，有输出就说明有软导航：

new PerformanceObserver(l => l.getEntries().forEach(e => console.log('soft nav', e.name)))
  .observe({ type: 'soft-navigation', buffered: true });

站内以前讲过框架站的收录问题，React和Next.js框架站怎么做SEO那篇说的是渲染模式选错导致抓成空壳，和这次的性能计分是两件事，但用的往往是同一批站。

三个指标分别怎么变

对软导航占一半以上的那批站，三项指标都会变好，但变好的原因不同。

LCP：后续页面本来就快，现在终于被算进来

变化最大的是LCP。软导航占75%到100%的安卓端网站，LCP达标的比例从稳定指标下的26%，变成实验指标下的87%。

看到这个数字别急着下结论说单页应用更快。Annie Sullivan特意解释过，单页应用整体并不比多页网站快，涨分的原因在于任何网站的后续点击都更快。第一次加载要下载代码和资源，后面的跳转可以复用已经下好的东西。以前CrUX只看单页应用最慢的那次首屏，等于只给它算了最难的一题，现在把后面那些容易的也算上了，分数自然上来。多页网站的后续访问本来就在统计里，所以这次只是把单页应用拉回到同一个算法上。

还有个技术细节：软导航的LCP只看这次跳转之后新画出来的内容。页面顶部一张大横幅图首次加载时是LCP元素，后续跳转时如果横幅没变、只是下方文字换了，那文字就成了这次的LCP元素。所以同一个网址，冷启动打开和站内跳转过去，LCP元素可能不是同一个。

首次加载那一下并没有因此变快。落地页的LCP照旧取决于服务器响应、资源大小和渲染路径，这部分该做的优化一样不能少，站内TTFB与多层缓存那篇讲过服务器这一端。

INP：不再拿整个会话里最慢的一次来算

INP的变化来自计算范围。原来单页应用的整个会话都算一个页面，INP取的是这一大段时间里最慢的那次交互，用户在站里待得越久、点得越多，越容易碰上一次卡顿，分数就越差。现在按每个页面视图分别算，以软导航为主的网站，安卓端的INP达标率大约翻了一倍。

不过官方也提醒了，就算有了这个加成，重度单页应用在INP达标率上整体还是落后于多页网站。路由切换时主线程上跑大段JavaScript，照样会拖慢响应。INP的优化方法可以看站内INP优化的主线程实战。

CLS：偏移按页面分段，不再一路累加

CLS的道理和INP类似。原来一次长会话里所有的布局偏移都累加在落地页上，现在按页面视图分段。改完之后，桌面端的重度单页应用和多页网站基本持平，安卓端还略差一点。CLS本身的排查方法，站内CLS累积布局偏移怎么优化讲过。

还有一个变化：内页终于有网址级数据了

三项分数之外，这次改动还有一个容易被忽略的好处，和SEO的关系比分数涨跌更直接。

以前单页应用里，只有用户直接打开的那个网址会被CrUX记录。用户从首页进来，再点到分类页、产品页，后面这些页面在CrUX看来根本没被访问过。结果就是Search Console的核心网页指标报告里，单页应用的内页常常显示数据不足，站长想知道哪个产品页慢，根本查不到。

新指标改了这一点。每次软导航都会被单独记录，相关数据挂在跳转到的那个目标网址名下，按常规的资格条件统计。所以只要某个内页通过站内跳转获得了足够的真实访问，它就会有自己的网址级数据。CrUX的网址级数据本来就有流量门槛，访问太少的页面照样不会单独出现，但单页应用内页拿不到数据的老问题，会缓解不少。

要分清的是，这只关系到真实用户的性能统计。Googlebot抓取网页时并不会在站内点来点去，它是一个网址一个网址直接请求的，对它来说每次都是硬导航。所以单页应用的每个网址仍然要能被直接打开、直接渲染出完整内容，这一点和以前一样，跟这次的指标改动无关。站内JS渲染的页面Google抓不到时怎么排查讲的就是这一侧的问题。

全网达标率涨了多少，别被6.4%带偏

CrUX的发布说明给了全网的对比数字，这批数据对应9月的数据集，10月13日发布，覆盖18376044个网站：

这里有个容易看错的地方。发布说明里写的“上升6.4%”是相对涨幅，59.5除以55.9约等于1.064；实际的达标网站比例只多了3.6个百分点。转述的时候写成“达标率提高6.4个百分点”，就把数字说大了将近一倍。几项指标都是同一个算法，看这类官方数据时，先确认一下写的是百分比还是百分点。

3.6个百分点乘以1800多万个网站，按实验口径，大约有66万个网站会从不达标变成达标。数字不小，但它们大多是本来就被算冤了的单页应用，网站本身没有变快。

这件事从提出到落地走了几年

单页应用被Core Web Vitals算错，不是新问题。Chrome团队早就在web.dev上的单页应用常见问题里承认过这个缺口，给的建议一直是自己做监控、自己按路由切分。真正的标准化，是一步一步推出来的：

前后算下来，从文档到计入CrUX用了三年多，离进Search Console还有半年以上。这个节奏本身就说明，Google对改动核心指标的口径非常谨慎，任何新算法都要先公开数据、听反馈，再慢慢替换。站长不必追着每一次实验数据调整优化方向，等它进了Search Console再按新口径复盘也来得及。

当然，等待不等于什么都不做。如果你正在规划改版，打算从传统主题换成无头架构或者框架站，这次的指标变化值得写进评估里：新架构上线后，真实用户数据的口径会和旧站不同，改版前后的分数不能直接拿来比。改版前先在CrUX Vis里记下旧站的基线，上线后两种口径都看，才能判断速度是真变快了，还是只是算法换了。

站长现在要不要动

大部分站不用动，少数站可以提前看一眼。按网站类型分开说。

传统整页加载的站：知道这件事就够了

WordPress、Shopify官方主题、自己写的多页网站，这次的变化基本与你无关。CrUX Vis里打开软导航开关，两条曲线应该几乎重合。以前该优化的LCP、INP、CLS照样要优化，没有因为这次改动变得更轻松。

单页应用和框架站：先看两种口径差多少

这类站可以在CrUX Vis里输入自己的域名，打开“包含软导航”的开关，对比两种口径。如果实验指标明显好于稳定指标，说明你的站以前确实被低估了，到2027年Search Console切换后，报告里的分数大概率会好看一些。

但有两件事别做。别因为新指标好看就停掉性能优化，实验指标官方明说每个月都可能调整，现在的数字不是定论。也别因为这个去改架构，把多页网站改成单页应用换不来真实的速度，只是换了个算法，还会带来收录上的新麻烦。

要优化的话，重点放在路由切换那一刻。软导航开始的时间是从用户点击那一下算起的，点击事件处理函数里跑的代码也算在里面。点了之后先请求接口、等数据回来再渲染的，这段等待会直接体现在软导航的LCP里。切换时预取数据、先渲染骨架，是比较常见的做法。站内Speculation Rules预渲染那篇讲的是多页网站让站内跳转变快的办法，思路可以互相参考。

在CrUX Vis里怎么对比

CrUX Vis是Google的免费网页工具，不用登录。操作很简单：输入网站域名，选择设备类型，安卓手机和桌面要分开看，因为两边的差距不一样；然后打开包含软导航的开关，页面会把稳定指标和实验指标画在一起。它的曲线来自CrUX History API，每周更新一次，每个点是一段28天的滚动统计，所以看到的是趋势，昨天改的东西今天不会马上反映出来。

看对比时重点看两件事。第一是两条线的差距有多大，差距越大，说明软导航在你的流量里占比越高。第二是实验指标下哪一项仍然不达标，那一项才是真正要花力气的地方，往往是INP。

自己做真实用户监控的：检查统计工具支不支持

用web-vitals库或者第三方监控服务收集性能数据的，要问一下供应商是否已经支持按软导航分段。官方文档提醒，各家监控服务正在陆续测试这个新标准，有些现在用的是自己的估算办法，和CrUX的口径不一定一致。自己的监控数据和CrUX对不上时，口径不同是第一个要排查的原因。

接下来几个时间点

11月的CrUX发布会加入软导航版的FCP和导航类型数据。Web Vitals的指标有一套固定的生命周期：先是实验阶段，公开数据收集反馈；然后进入待定阶段，至少待六个月，给开发者留出适应时间；最后才转为稳定，进入Search Console这类工具。INP当年替换FID走的就是这条路。Chrome给出的转正目标是2027年5月，但写的是视反馈而定，日期可能会变，可以留意每个月的发布说明。

Core Web Vitals在排名里占多大分量，站内Core Web Vitals还值不值得投那篇讨论过。简单说，它是页面体验的一部分，不是决定性因素，这次的改动也不会让任何网站一夜之间排名大变。上一次CrUX新增指标是广告相关的数据，站内CrUX广告指标那篇也提过同样的规律：先实验、再观察，离进Search Console还有一段路。

常见问题解答

什么是软导航？

软导航是单页应用里的站内跳转：页面不整页刷新，由JavaScript替换内容并修改地址栏网址。Chrome的判定条件有三个，由用户操作触发、网址有可见变化、页面有可见的新绘制，三者同时满足才算一次软导航。

CrUX新增的软导航指标会影响Google排名吗？

目前不会。这三个指标还是实验状态，Google现有的稳定指标没有变，Search Console和PageSpeed Insights显示的仍是原来的口径。Chrome计划2027年5月结束实验阶段，之后Search Console才会切换到新数据。

我的WordPress或Shopify网站会受影响吗？

大概率不会。用传统主题建的WordPress和Shopify网站，每次点击都是整页加载，没有软导航，新旧指标几乎一样。CrUX全部网站里，约七成的软导航占比不到5%，指标不会有明显变化。

怎么查看自己网站的软导航指标？

最方便的是Google的CrUX Vis工具，输入域名后打开包含软导航的开关，就能对比两种口径。开发者也可以通过CrUX API、CrUX History API或BigQuery取数据，字段名以experimental开头、以with_softnavs结尾。

为什么单页应用的LCP在新指标下好了那么多？

以前CrUX只计算单页应用的第一次加载，这是最慢的一次。新指标把后续站内跳转也算进来，这些跳转能复用已下载的代码和资源，本来就快。官方强调这不代表单页应用整体比多页网站快。

Googlebot抓取单页应用时也算软导航吗？

不算。软导航指标统计的是真实Chrome用户在站内点击时的体验，Googlebot抓取时是直接请求每个网址，相当于每次都是整页加载。单页应用的每个网址仍然要能被直接打开并渲染出完整内容，才能被正常收录。

全网Core Web Vitals达标率提高了多少？

按9月的CrUX数据，三项全部达标的网站比例从55.9%变成59.5%，增加了3.6个百分点。发布说明里写的6.4%是相对涨幅，不是百分点。LCP、CLS、INP分别增加3.8、3.4和2.0个百分点。

权威参考资料