解答了有关 SPA、Core Web Vitals 以及 Core Web Vitals 如何处理这些问题的常见问题。
发布时间：2021 年 9 月 14 日；上次更新时间：2026 年 8 月 11 日
自 2020 年 5 月首次推出 Web Vitals计划以来，Chrome 团队收到了许多关于该计划的精彩问题和反馈。
我们收到的问题中，可能最多的是关于如何在单页应用 (SPA) 中衡量 Core Web Vitals，以及 SPA 架构如何影响 Core Web Vitals 得分。这个问题可能也是最难回答的。
这些问题很难回答，因为问题本身非常微妙，因此在这篇博文中，我们将尽力回答最常见的问题，并尽可能提供详细信息和背景信息。
不过，在深入探讨具体细节之前，请务必注意，Google 对用于构建网站的架构或技术没有任何偏好。我们认为，SPA 和多页应用 (MPA) 都能为用户提供优质体验，而我们推出“网页指标”计划的目的是提供可衡量体验的指标，这些指标与技术无关。
常见问题解答
以下是我们最常收到的有关此主题的一些问题。欢迎通过我们的反馈群组或提出问题来提供反馈，以便我们在此常见问题解答中添加相应内容。
Core Web Vitals 指标是否包含 SPA 路由转换？
最初推出时，每个核心网页指标都是相对于当前顶级网页导航来衡量的。如果网页动态加载新内容并更新地址栏中的网页网址，则不会影响 Core Web Vitals 指标的衡量方式。
指标值未重置，与每次指标衡量相关联的网址是用户导航到的网址，该网址会启动网页加载。
Chrome 151 引入了新的 API，可用于衡量 SPA 路由转换过程中的核心网页指标。在撰写本文时（2026 年 8 月），这些 API 才刚刚开始在 web-vitals 等效果衡量库、RUM 解决方案和 Chrome 开发者工具等工具中使用。Chrome 尚未公布将这些指标纳入 Chrome 用户体验报告 (CrUX) 的时间范围。此外，其他浏览器引擎尚不支持这些新 API，因此对于这些浏览器，只能在完整网页加载时衡量 Core Web Vitals。
为什么这是一个难以解决的问题？
目前，还没有构建 SPA 的标准化方法，即使在热门的 SPA 和路由库中，用户体验也可能因应用而异：
- 部分 SPA 仅在加载新的“整页”内容时更新网址，而其他网站则会在内容发生细微更改甚至仅是界面状态发生更改时更新网址。
- 有些 SPA 使用 History API 更新网址，而另一些则使用哈希值更改来支持旧版浏览器（还有一些根本不更新网址）。
- 部分 SPA 先加载内容，然后更新网址，而其他 SPA 则先更新网址，然后再加载内容。
- 有些 SPA 会在单个 JavaScript 任务中同步加载所有内容，而另一些 SPA 会在多个任务中异步过渡内容（没有明确的过渡结束事件）。
- 有些 SPA 始终从网络加载内容，而另一些 SPA 会预先加载所有内容，以便从内存中即时加载路线更改。
这些差异使得我们很难大规模定义和识别构成 SPA 路由更改的因素，甚至很难识别 SPA 本身。
在某些情况下，SPA 路由更改在逻辑上与 MPA 网页加载相同，在这种情况下，如果能应用现有的 Core Web Vitals 指标，那就太好了。
不过，如果没有可靠的启发式方法来可靠地识别所有其他网址更改中的“真实”路线更改，也没有明确的信号来标记此类过渡的开始和结束，那么在这些情况下报告核心网页指标会使数据变得混乱，并使其无法准确反映网站上的真实用户体验。
软导航工作通过两个新的性能 API 为此问题提供了解决方案：
PerformanceSoftNavigation，用于衡量用户互动何时导致了绘制和网址更改。无论使用何种框架，上述三者的组合都能提供“软导航”的标准化定义，并消除之前提到的一些差异。这样一来，便可将性能时间轴拆分为单独的“导航”，从而针对每次导航分别衡量 CLS 和 INP。InteractionContentfulPaint，用于衡量互动后的“有内容的绘制”，从而可以针对这些软导航衡量 FCP 和 LCP。
通过结合使用这两个 API，可以同时在完整网页加载和软导航中衡量核心网页指标。
对于 Core Web Vitals，SPA 路由更改是否与完整网页加载相同？
不是，这两种类型的导航之间仍存在许多差异，可能会导致 Core Web Vitals 指标有所不同。
软导航是指网页上包含内容，并且正在更新部分或全部内容以显示新的“网页”。在许多方面，这类似于未缓存的完整网页加载与缓存了部分或全部网页资源的网页加载之间的区别，但程度更极端，因为某些内容可能会保持呈现状态。
从理论上讲，主要区别在于软导航的速度可能会快得多。不过，两者之间还存在一些更细微的差异。
新的软导航 API 仅考虑新内容。因此，如果某个网页更新了 <h1> 和文本内容，但保留了相同的主打图片，那么如果该主打图片没有重新绘制，则不会将其视为 LCP 候选对象。这会导致用于计算 LCP 时间的元素有所不同，具体取决于同一网页是作为完整网页加载还是作为从另一个现有网页进行的软导航加载。
同样，由于运行网站所需的许多 JavaScript 已加载，因此软导航的 INP 可能会更低。同样，软导航可能具有较少（或更多！）如果相同的内容在完整网页加载时会导致 CLS，但在软导航时无需加载或重新渲染，则为 CLS。
此外，在完整网页加载（从导航互动处理完成后开始衡量）与软导航（从互动开始时间开始衡量）中，衡量时间也略有不同。
如前所述，这些差异中的许多都类似于未缓存网页与已缓存网页之间的差异，Core Web Vitals 试图衡量的概念仍然适用。不过，在调查核心网页指标问题时，了解这些细微差别很有价值。
与 MPA 相比，SPA 是否更难在 Core Web Vitals 方面取得良好表现？
SPA 架构本身并不会阻止 SPA 中的网页像 MPA 中的类似网页一样快速加载，也不会阻止 SPA 中的网页在所有 Core Web Vitals 指标上获得同样出色的得分。
不过，经过适当优化的 MPA 在达到核心网页指标阈值方面确实具有 SPA 所不具备的一些优势。通过之前讨论的软导航工作，此问题已在很大程度上得到缓解，但如果尚未使用这些新 API，则可能仍会发生此问题。 这是因为，在 MPA 架构中，每个“网页”都是作为全网页导航加载的（而不是动态提取内容并将其插入到现有网页中），这意味着访问 MPA 的用户更有可能从该网站加载多个网页，进而意味着 MPA 的所有网页加载分布中，有更大比例的网页加载会涉及缓存部分或全部子资源。
当然，要使 MPA 在 Core Web Vitals 指标方面的表现优于 SPA，需要满足以下几个条件：
- MPA 需要具有优化的子资源缓存，才能确保同源网页加载速度确实比第 75 百分位的跨源网页加载速度更快。
- 访问 MPA 的用户需要访问多个页面，网站才能获得缓存带来的好处，从而加快页面加载速度。
由于 Core Web Vitals 评估会考虑网页访问的第 75 百分位，因此，如果数据集中的网页访问次数更多且效果良好，那么分布中第 75 百分位的访问更有可能在建议的阈值范围内。
请注意，在比较核心网页指标得分时，需要考虑的一个重要因素是数据的汇总方式，即分布图中的数据集是否包含您网站或来源的所有网页，还是仅包含特定网页网址的网页加载。
在汇总来源中所有网页的分数时，单个快速网页可以提高整个来源的第 75 百分位数。不过，如果按各个网页进行汇总，一个网页的分数不会影响下一个网页的分数。换句话说，在按网页汇总 MPA 的得分时，结账页面上看到的快速缓存加载不会提高网站着陆页上体验到的缓慢初始加载的得分。
您可以使用 PageSpeed Insights 或 Chrome 用户体验报告 API 查看网站在不同汇总方法下的得分，这些工具会报告单个网页网址和整个来源的得分。
SPA 架构影响 Core Web Vitals 得分的另一种方式是，对于考虑网页完整生命周期的指标，SPA 架构可能会产生影响。由于访问 SPA 的用户往往会在整个会话期间停留在同一“网页”上，因此随时间累积的指标对 SPA 的影响可能比对 MPA 的影响更大。
通过软导航工作，我们认为在核心网页指标的衡量方面，SPA 不应有任何缺点。不过，在所有工具和报告解决方案中全面集成这些 API 需要时间。
如果 SPA 架构可以提升用户体验，那么这种提升是否应该反映在指标中？
Yes, it should. 鉴于如今在网络上实现 SPA 的方式各不相同，很难大规模量化体验的改进程度。现在，我们已经找到了解决效果衡量问题的方法，并且在使用这些新 API 时，改用 SPA 带来的任何改进都应反映在指标中。
事实上，与网页加载本身相比，网页性能行业（包括 Google）历来在开发以用户为中心的指标来衡量网页加载后的性能方面投入的时间和精力要少得多。这并不是因为加载后性能不重要，而是因为加载后用户体验和互动更加多样化且不太明确，因此很难为其设计指标。
但即使现在我们有更多加载后指标来衡量 SPA 性能，我们也不会因为加载后体验有所改善而忽略加载体验。
“Web Vitals”计划的目标之一是尽可能在网页加载和使用过程中的各个方面促进和激励良好的用户体验。我们不希望出现以下情况：如果能获得足够多的良好体验来弥补不良体验，那么不良体验就是合理的。用户希望网页加载速度快且能快速过渡到新内容，因此我们尝试设计出有利于这些类型体验的指标。
我们将网站从 MPA 切换到 SPA，但得分却下降了。这是正常情况吗？
这要视具体情况而定。在进行重大架构迁移后，分数可能会因多种原因而发生变化，但热缓存加载次数减少可能是导致部分变化的原因。
一种快速检查方法是使用 Lighthouse 测试某个着陆页的 MPA 版本和 SPA 版本。如果 SPA 版本的任何 Core Web Vitals 指标的 Lighthouse 分数较低，则很可能表示更新后加载体验确实变差了。
我是否应该将网站从 SPA 切换到 MPA，以便在核心网页指标方面获得更好的得分？
一般不会。只有在您对 SPA 堆栈不满意，并且有理由相信 MPA 会提供更好的用户体验时，才应从 SPA 切换到 MPA。
通过软导航工作，我们认为已经解决了衡量问题，因此仅出于此原因而迁移是不合理的。
不过，如果您有理由表明性能将会提升，而不仅仅是指标会提升，那么这可能就是从 SPA 改为 MPA（或反之）的理由！
如果仅针对 SPA 的着陆页报告核心网页指标得分，我该如何调试在路由转换后发生的“网页”问题？
报告核心网页指标实测数据的 Google 工具（例如 Search Console 和 PageSpeed Insights）的数据来自 Chrome 用户体验报告 (CrUX)。CrUX 会按来源或网页网址（即加载时的网页网址）汇总数据。
我们正在努力让 CrUX 在其汇总数据中包含按 SPA 路由划分的数据。不过，作为网站所有者，您现在可以使用新的 API 提前按 SPA 路线衡量 Core Web Vitals，了解分数可能会发生哪些变化。
如需详细了解相关信息和最佳实践，请参阅：衡量软导航。
Google 正在采取哪些措施来确保 MPA 不会比 SPA 具有不公平的优势？
如前所述，通过软导航，我们认为目前所做的工作意味着 SPA 在这方面不会有任何劣势，不过在所有工具和报告解决方案中实现全面集成还需要一段时间。
分别评估跨源和同源网页访问
目前，核心网页指标会将所有网页访问汇总到一个数据桶中，不会区分新访问与回访、着陆页与结账页，也不会区分任何其他可能因缓存状态而影响性能的汇总类型。
一种方法是对不同类型的访问应用不同的权重，从而使 SPA 和 MPA 的效果差异归于正常，甚至可以采用完全不同的阈值建议。
虽然我们确实希望奖励有效的缓存实现，但我们不希望快速的站内导航能够掩盖缓慢的着陆页加载。我们也不希望为了提高指标得分而鼓励网站将长网页拆分成一系列较短的网页。
通过分别评估跨源和同源网页访问，我们可以帮助确保这两种类型的体验都很重要，而不会让给定网站上一种类型的相对受欢迎程度影响任何特定指标的分布。
最后总结
Google 致力于改进 Web Vitals 指标，确保这些指标能够衡量并鼓励提供对用户而言至关重要的高质量体验。不过，我们承认目前确实存在衡量差距。现在，这些指标能够涵盖 SPA 路线过渡，从而弥补了主要差距之一。
我们还认为，除了用于衡量软导航的核心网页指标之外，这些新 API（尤其是 InteractionContentfulPaint）还有其他用途和潜在优势。现在，这些功能推出时的主要原因已得到解决，我们非常高兴能继续在此基础上进行构建。
希望本文有助于您了解这个复杂而细致的主题。 与往常一样，如果您对当前或未来的网页指标有任何反馈，请发送电子邮件至 web-vitals-feedback@googlegroups.com。