SPA 架构如何影响 Core Web Vitals

关于 SPA、Core Web Vitals 以及 Google 解决当前衡量限制的计划的常见问题解答。

Philip Walton
Yoav Weiss

自从 2020 年 5 月首次推出 Web Vitals 计划以来，Chrome 团队收到了许多关于该计划的精彩问题和反馈。

我们收到最多问题的主题，可能也是最难回答的问题，是如何在单页应用程序 (SPA) 中衡量 Core Web Vitals，以及 SPA 架构如何影响 Core Web Vitals 分数。

这些问题很难回答，因为问题非常细致入微，因此在本文中，我们将尽力回答最常见的问题，并尽可能提供详细信息和背景。

不过，在深入探讨具体细节之前，重要的是要声明 Google 对使用何种架构或技术来构建网站没有任何偏好。我们认为 SPA 和多页应用程序 (MPA) 都能够为用户提供高质量的体验，而我们 Web Vitals 计划的目的是提供独立于技术的体验衡量指标。虽然今天并非在所有情况下都能实现这一点（由于 Web 平台的限制），但我们正在积极努力弥合这些差距。

常见问题解答

Core Web Vitals 指标是否包含 SPA 路由转换？

否。每个 Core Web Vitals 指标都是相对于当前顶级页面导航来衡量的。如果页面动态加载新内容并更新地址栏中的页面 URL，则不会影响 Core Web Vitals 指标的衡量方式。指标值不会重置，并且与每个指标衡量相关的 URL 是用户导航到的、启动页面加载的 URL。

Core Web Vitals 指标是否可以将 SPA 路由更改视为与传统页面加载相同？

遗憾的是，不能。至少目前还不能。

今天没有构建 SPA 的标准化方法，即使在流行的 SPA 和路由库中，用户体验也可能因应用程序而异

  • 有些 SPA 仅在加载新的“整页”内容时才更新 URL，而其他站点则针对微小的内容更改甚至只是 UI 状态更改更新 URL。
  • 有些 SPA 使用 History API 更新 URL，而另一些则使用哈希更改以支持旧版浏览器（还有一些根本不更新 URL）。
  • 有些 SPA 先加载内容，然后再更新 URL，而另一些则在加载内容之前更新 URL。
  • 有些 SPA 在单个 JavaScript 任务中同步加载所有内容，而另一些则跨多个任务异步过渡内容（没有明确的过渡结束事件）。
  • 有些 SPA 始终从网络加载内容，而另一些则预加载所有内容，以便路由更改可以从内存中立即加载。

这些差异使得大规模定义和识别构成 SPA 路由更改甚至 SPA 本身的内容非常困难。

在某些情况下，SPA 路由更改在逻辑上与 MPA 页面加载相同，在这种情况下，如果可以应用现有的 Core Web Vitals 指标，那就太好了。

但是，如果没有可靠的启发法来可靠地识别所有其他 URL 更改中的“真实”路由更改，以及标记此类转换开始和结束的明确信号，那么在这些情况下报告 Core Web Vitals 指标将混淆数据，并使其不太有用或不能代表网站上的真实用户体验。

SPA 在 Core Web Vitals 方面的表现是否比 MPA 更难？

SPA 架构本身并没有任何固有的东西会阻止 SPA 中的页面加载速度与 MPA 中的类似页面一样快，并且在所有 Core Web Vitals 指标上的得分也一样好。

但是，经过适当优化的 MPA 在满足 Core Web Vitals 阈值方面确实具有 SPA 目前不具备的一些优势。原因是，使用 MPA 架构，每个“页面”都作为整页导航加载（而不是动态获取内容并将其插入到现有页面中），这意味着访问 MPA 的用户更有可能从网站加载多个页面，这反过来意味着 MPA 的所有页面加载分布中，较大部分将涉及部分或全部子资源被缓存。

当然，为了使 MPA 在 Core Web Vitals 指标上比 SPA 表现更好，需要满足以下几个条件

  • MPA 需要优化子资源缓存，以确保同源页面加载确实比第 75 百分位数处的跨源页面加载更快。
  • 访问 MPA 的用户需要访问多个页面，以便站点获得缓存优势，从而实现更快的页面加载速度。

由于 Core Web Vitals 评估考虑了第 75 百分位数的页面访问，因此在数据集中拥有更多表现良好的页面访问将增加分布的第 75 百分位数处的访问在建议阈值内的可能性。

请注意，在比较 Core Web Vitals 分数时，需要考虑的一个重要事项是如何聚合数据，即分布中的数据集是否包含您网站或来源的所有页面，还是仅包含特定页面 URL 的页面加载。

当聚合来源中所有页面的分数时，单个快速页面可以提高整个来源的第 75 百分位数。但是，当按单个页面聚合时，一个页面的分数不会影响下一个页面的分数。换句话说，当按页面聚合 MPA 的分数时，在结帐页面上看到的快速缓存加载不会提高站点着陆页上体验到的慢速初始加载的分数。

您可以使用 PageSpeed Insights 或 Chrome 用户体验报告 API 检查您网站在不同聚合方法下的得分，该 API 报告单个页面 URL 和整个来源的得分。

SPA 架构影响 Core Web Vitals 分数的另一种方式是对于考虑页面完整生命周期的指标。由于访问 SPA 的用户往往在整个会话期间都停留在同一“页面”上，因此随着时间推移而累积的指标对 SPA 来说可能比 MPA 更苛刻。

在 2021 年 4 月，我们宣布了对 CLS 指标的更改，部分解决了这个问题。以前，CLS 会在整个页面生命周期内累积，而现在它仅在特定的时间窗口内累积，本质上是给定页面上最糟糕的布局偏移突发。

但是，即使使用新的 CLS 定义，SPA 仍然处于不利地位，因为 CLS 值在路由转换后不会像 MPA 中的整页加载那样“重置”。这也会导致混淆，因为路由转换后发生的布局偏移将归因于页面加载时的 URL，而不是发生偏移时地址栏中的 URL（更多详细信息如下）。

如果 SPA 架构改善了用户体验，那么这种改进是否应该反映在指标中？

是的，应该如此。尽管如前所述，鉴于当今 Web 上实施 SPA 的方式千差万别，量化体验改进的程度非常困难。

事实是，Web 性能行业（包括 Google）在历史上并没有投入几乎与页面加载本身一样多的时间和精力来开发以用户为中心的指标来衡量页面的加载后性能。这并不是因为加载后性能不重要，而是因为加载后 UX 和交互非常多样化且定义不明确，因此很难为其设计指标。

但是，即使我们确实有明确定义的加载后指标来衡量 SPA 性能，我们也不希望仅仅因为加载后体验有所改善而忽略加载体验。

Web Vitals 计划的目标之一是促进和激励尽可能多地提高网页加载和使用方面的良好用户体验。我们不希望鼓励这样一种情况，即如果可以通过足够多的良好体验来弥补糟糕的体验，那么糟糕的体验就是合理的。用户希望页面加载速度快并且能够快速过渡到新内容，我们已尝试设计有利于这些类型体验的指标。

因此，虽然网站的 MPA 版本在第 75 百分位数的 Core Web Vitals 指标上可能比完全相同的网站的 SPA 版本表现更好，但 SPA 版本仍应努力达到“良好”阈值。如果 SPA 版本对于大多数用户来说未能达到“良好”阈值，那么即使后续的页面内导航体验非常出色，初始加载体验可能仍然不被认为是良好的。

未来，我们计划开发鼓励出色加载后体验的指标，我们相信这是以不损害初始加载体验的方式激励高质量 SPA 的最佳途径。我们已经交付了一个名为Interaction to Next Paint (INP) 的新指标，该指标衡量整个页面生命周期中的交互延迟，并且我们还在积极开发其他加载后指标，包括衡量 SPA 路由转换的指标（请参阅下文）。

我们将网站从 MPA 切换到 SPA，但我们的分数下降了。这是预期的吗？

这取决于情况。架构大迁移后，您的分数可能会发生变化的原因有很多，但热缓存加载次数减少可能是部分原因。

检查的快速方法是使用 Lighthouse 测试您的一个着陆页的 MPA 和 SPA 版本。如果 SPA 版本的任何 Core Web Vitals 指标的 Lighthouse 分数较低，则很可能更新后加载体验确实变差了。

我应该将我的网站从 SPA 切换到 MPA 以在 Core Web Vitals 上获得更高的分数吗？

可能不应该。只有当您对 SPA 堆栈不满意，并且有理由相信 MPA 会提供更好的用户体验时，才应从 SPA 切换到 MPA。

随着时间的推移，随着 Core Web Vitals 指标的改进并涵盖更多完整的浏览体验，提供出色 UX 的精心构建的 SPA 团队应该会看到他们的 Core Web Vitals 分数反映出这一点。

如果 Core Web Vitals 分数仅针对 SPA 的着陆页报告，那么如何在路由转换后在“页面”上发生的调试问题？

报告 Core Web Vitals 指标字段数据的 Google 工具（如 Search Console 和 PageSpeed Insights）从Chrome 用户体验报告 (CrUX) 获取数据。CrUX 按来源或页面 URL（即加载时的页面 URL）聚合数据。

出于上述所有原因，CrUX 无法按 SPA 路由聚合数据。但是，作为熟悉自己架构的网站所有者，您可以自行衡量这一点，并且许多分析工具允许您在发生 SPA 路由更改时发出信号，并且它们会相应地更新您的衡量数据。

使用分析工具衡量 Web Vitals 指标时，请确保同时衡量当前路由 URL 和原始页面 URL。这将使您既可以调试整个页面生命周期中发生的各个问题，又可以按原始页面 URL 进行聚合，以便与 Google 工具衡量和报告指标的方式相匹配。

有关此主题的更多详细信息和最佳实践，请参阅：在现场调试性能。

Google 正在采取哪些措施来确保 MPA 不会比 SPA 具有不公平的优势？

如上所述，在某些情况下，经过适当优化的 MPA 可以报告更好的第 75 百分位数 Web Vitals 分数，因为 MPA 可能具有更高比例的缓存页面访问。相反，在经过适当优化的 SPA 中，用户体验的真正改进目前尚未被任何 Core Web Vitals 指标捕获。

在 Google，我们认识到这会产生与 Web Vitals 计划目标不完全一致的激励措施，并且我们正在积极寻找解决此问题的方法。目前，我们正在探索两种潜在的解决方案，一种是短期解决方案，另一种是长期解决方案

  1. 分别评估跨源和同源页面访问。
  2. 设计新的 API，以实现更好的 SPA 衡量。

分别评估跨源和同源页面访问

今天，Core Web Vitals 指标将所有页面访问聚合到一个存储桶中，它们不区分新访问与回访，也不区分着陆页与结帐页，也不区分任何其他聚合类型，在这些聚合类型中，缓存状态可能会对性能产生影响。

规范化 SPA 和 MPA 性能之间差异的一种方法是对不同类型的访问应用不同的权重，甚至可能使用完全不同的阈值建议。

虽然我们绝对希望奖励有效的缓存实现，但我们不希望快速的站内导航能够掩盖缓慢的着陆页加载。我们也不希望激励站点仅仅为了提高指标分数而将长页面分解为一系列较短的页面。

通过分别评估跨源和同源页面访问，我们可以帮助确保两种类型的体验都很重要，而不会让给定站点上一种类型的相对受欢迎程度扭曲任何特定指标的分布。

设计新的 API，以实现更好的 SPA 衡量

正在积极开展的另一个解决方案（与上述解决方案并行）是新的 App History API，这将有助于标准化当前的 SPA 模式，并使大规模衡量和理解 SPA 使用情况变得更容易。

App History API 引入了一个新的 navigate 事件，该事件具有两个特定于 SPA 衡量的关键功能

  • 一个 userInitiated 标志，仅当导航是通过链接点击、表单提交或浏览器的后退或前进 UI 启动时，才会将其设置为 true。
  • 一个 transitionWhile() 方法，该方法接受一个 promise，允许开发人员发出信号，指示他们启动以执行导航的工作何时完成。

userInitiated 标志可用于确定 SPA 路由转换的语义起点，指示明确的用户意图。transitionWhile() promise 解析可以帮助浏览器将绘制与特定的路由转换相关联，从而使其能够确定与该转换相关的最大内容绘制。

在上一节中提出的想法的基础上，甚至可以将 SPA 路由转换时间聚合到与 MPA 中的同源页面加载相同的存储桶中。这令人兴奋，因为它将允许从 MPA 迁移到 SPA 的站点实际比较迁移前后的性能。

当然，在我们知道是否可以准确地做出这些判断之前，还需要进行更多研究。如果您对这些提案有建议或反馈，请发送电子邮件至 web-vitals-feedback@googlegroups.com。

最后想法

Google 致力于改进 Web Vitals 指标，并确保它们衡量和激励对用户至关重要的高质量体验。话虽如此，我们确实承认今天存在衡量差距。指标目前并未涵盖用户体验的方方面面，但我们正在积极努力弥合这些差距。

尽管存在当前的局限性，但我们相信现有指标确实捕获的领域对于 Web 的健康和成功至关重要，并且在网站（无论架构如何）未能达到建议阈值的程度上，我们相信仍有改进空间。

我希望这篇文章有助于阐明这个复杂而细致入微的主题。与往常一样，如果您对当前或未来的 Web Vitals 指标有反馈，请发送电子邮件至 web-vitals-feedback@googlegroups.com。