有关 SPA、核心 Web Vitals 和 Google 解决当前衡量限制的计划的常见问题解答。
自 2020 年 5 月首次推出 Web Vitals 计划以来，Chrome 团队收到了许多有关该计划的提问和反馈。
我们收到最多的问题，可能也是最难回答的问题，可能是如何在单页应用 (SPA) 中衡量 Core Web Vitals，以及 SPA 架构如何影响 Core Web Vitals 得分。
由于问题非常细致，因此这些问题很难回答。因此，在本文中，我们将尽力回答最常见的问题，并尽可能提供详细信息和背景信息。
不过，在深入探讨具体内容之前，有一点需要强调：Google 对用于构建网站的架构或技术没有任何偏好。我们认为，SPA 和多页面应用 (MPA) 都能为用户提供优质体验。我们推出网页指标计划的目的是提供可独立于技术衡量体验的指标。虽然目前并非在所有情况下都能做到这一点（由于网络平台的限制），但我们正在积极努力缩小这些差距。
常见问题解答
核心 Web 指标是否包含 SPA 路由转换？
不可以。每个 Core Web Vitals 指标都是相对于当前的顶级网页导航进行衡量的。如果网页动态加载新内容并更新地址栏中的网址，则不会影响 Core Web Vitals 指标的衡量方式。指标值不会重置，并且与每个指标测量结果关联的网址是用户导航到的用于发起网页加载的网址。
Core Web Vitals 指标能否将 SPA 路由更改视为传统网页加载？
很抱歉，不能。至少目前还不能。
目前，还没有标准化的方法来构建 SPA，即使在流行的 SPA 和路由库中，应用之间的用户体验也可能截然不同：
- 有些 SPA 仅在加载新的“整页”内容时更新网址，而其他网站会在内容发生细微更改或界面状态发生更改时更新网址。
- 有些 SPA 使用 History API 更新网址，而有些 SPA 使用哈希更改来支持旧版浏览器（还有一些 SPA 根本不更新网址）。
- 有些 SPA 会先加载内容，然后更新网址；而有些 SPA 会先更新网址，然后加载内容。
- 有些 SPA 会在单个 JavaScript 任务中同步加载所有内容，而另一些 SPA 则会在多个任务中异步转换内容（没有明确的转换结束事件）。
- 某些 SPA 始终从网络加载内容，而另一些 SPA 会预加载所有内容，以便从内存中立即加载路由更改。
这些差异使得很难大规模定义和识别构成 SPA 路由更改（甚至 SPA 本身）的因素。
在某些情况下，SPA 路由更改在逻辑上与 MPA 网页加载相同，在这种情况下，如果可以应用现有的 Core Web Vitals 指标，将会非常有用。
不过，如果没有可靠的启发词语来可靠地将“真实”路线更改与所有其他网址更改区分开来，以及没有明确的信号来标记此类转换的开始和结束，那么在这些情况下报告核心网页指标会使数据变得模糊不清，降低其实用性，或无法代表网站上的真实用户体验。
SPA 在 Core Web Vitals 方面是否比 MPA 更难取得理想成效？
SPA 架构中没有任何固有因素会阻止 SPA 中的网页像 MPA 中的类似网页一样快速加载，并且在所有 Core Web Vitals 指标上的得分也一样出色。
不过，在满足 Core Web Vitals 阈值方面，经过适当优化的 MPA 确实有一些优势，而 SPA 目前还不具备这些优势。原因在于，在 MPA 架构中，每个“网页”都会作为完整网页导航加载（而不是动态提取内容并将其插入现有网页），这意味着访问 MPA 的用户更有可能从网站加载多个网页，这反过来意味着，MPA 的所有网页加载分布中，涉及部分或全部缓存子资源的比例会更高。
当然，要想让 MPA 在 Core Web Vitals 指标方面比 SPA 表现更好，需要满足以下几点：
- MPA 需要进行优化的子资源缓存，以确保在第 75 个百分位时，同源网页的加载速度确实比跨源网页的加载速度快。
- 访问 MPA 的用户需要访问多个网页，以便网站获得缓存的好处，从而加快网页加载速度。
由于 Core Web Vitals 评估会考虑网页访问的第 75 百分位数，因此如果数据集中包含更多效果良好的网页访问，则第 75 百分位数的访问在分布范围内达到推荐阈值的可能性就会增加。
请注意，比较 Core Web Vitals 得分时，需要考虑的一个重要因素是数据的汇总方式，即分布中的数据集是包含您网站或来源中的所有网页，还是仅包含特定网页网址的网页加载。
在汇总来源中所有网页的得分时，个别加载速度较快的网页可以提高整个来源的 75 百分位数。不过，按个别网页汇总时，一个网页的得分不会影响下一个网页的得分。换句话说，按网页汇总 MPA 的得分时，结账页上快速的缓存加载速度不会提升网站着陆页上缓慢的初始加载速度得分。
您可以使用 PageSpeed Insights 或 Chrome 用户体验报告 API 查看网站在不同汇总方法下的得分，该 API 会报告各个网页网址和整个来源的得分。
SPA 架构会影响核心网页指标得分，另一种方式是通过考虑网页的整个生命周期的指标。由于访问 SPA 的用户往往会在整个会话期间停留在同一“页面”上，因此与 MPA 相比，SPA 的累积指标可能会更严苛。
2021 年 4 月，我们宣布了对 CLS 指标的更改，这在一定程度上解决了这个问题。以前，CLS 会在整个网页生命周期内累积，而现在，它只会在特定时间段内累积，本质上是给定网页上最严重的布局偏移突发。
不过，即使采用了新的 CLS 定义，SPA 仍然处于劣势，因为 CLS 值在路由转换后不会“重置”，就像 MPA 中的完整网页加载一样。这也可能会导致混淆，因为路线转换后发生的布局偏移将归因于网页加载时的网址，而不是偏移时地址栏中的网址（详见下文）。
如果 SPA 架构可以提升用户体验，那么这种改进不应该反映在指标中吗？
是的，应该可以。不过，如前所述，鉴于目前 Web 上实现 SPA 的所有不同方式，很难大规模量化用户体验的改进幅度。
事实上，与网页加载本身相比，网络性能行业（包括 Google）在为网页的加载后性能开发以用户为中心的指标方面投入的时间和精力并不多。这并不是因为加载后的性能不重要，而是因为加载后的用户体验和互动更加多样且定义不明确，因此很难为其设计指标。
不过，即使我们确实有明确定义的加载后指标来衡量 SPA 性能，也不会因为加载后体验有所改善而忽略加载体验。
“网页指标”计划的目标之一是，在网页加载和使用过程中尽可能多地促进和激励提供良好的用户体验。如果您可以获得足够的良好体验来弥补不良体验，我们不希望鼓励出现这种情况。用户希望网页快速加载并快速转换到新内容，我们尝试设计了有利于提供此类体验的指标。
因此，虽然网站的 MPA 版本在 Core Web Vitals 指标的 75 分位数方面可能比完全相同网站的 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 指标不断改进并涵盖更多完整的浏览体验，拥有构建良好且提供出色用户体验的 SPA 的团队应该会看到其 Core Web Vitals 得分反映出这一点。
如果 Core Web Vitals 得分仅针对 SPA 的着陆页报告，那么如何调试路线转换后“网页”上发生的问题？
报告 Core Web Vitals 指标实测数据的 Google 工具（例如 Search Console 和 PageSpeed Insights）会从 Chrome 用户体验报告 (CrUX) 获取数据。CrUX 会按来源或网页网址（即加载时的网页网址）汇总数据。
由于上述所有原因，CrUX 无法按 SPA 路线汇总数据。不过，作为熟悉您自己架构的网站所有者，您可以自行衡量这一点。许多分析工具都允许您在发生 SPA 路线更改时发出信号，并相应地更新您的衡量数据。
使用分析工具衡量 Core Web Vitals 指标时，请确保同时衡量当前路由网址和原始网页网址。这样，您就可以调试整个网页生命周期中发生的各个问题，并按原始网页网址进行汇总，以便与 Google 工具衡量和报告指标的方式保持一致。
如需详细了解此主题以及相关最佳实践，请参阅在现场调试性能。
Google 在采取哪些措施来确保 MPA 与 SPA 相比没有不公平的优势？
如上所述，在某些情况下，经过适当优化的 MPA 可能会报告在第 75 个百分位数的更好 Web Vitals 得分，因为其缓存网页访问的百分比可能会更高。反之，目前，任何核心 Web 指标都无法捕获对经过适当优化的 SPA 的用户体验带来的真正改进。
Google 意识到，这种做法会产生的激励措施与 Web Vitals 计划的目标不完全一致，因此我们正在积极寻找解决方法。目前，我们正在探索两种潜在解决方案，一种是短期方案，一种是长期方案：
- 分别评估跨源网页访问和同源网页访问。
- 设计新的 API，以便更好地衡量 SPA。
单独评估跨源网页访问和同源网页访问
目前，核心网页指标会将所有网页访问汇总到一个存储分区中，不会区分新访问和回访，也不会区分着陆页和结账页，也不会区分缓存状态可能会影响性能的任何其他汇总类型。
若要对 SPA 和 MPA 效果之间的差异进行标准化处理，一种方法是针对不同类型的访问应用不同的权重，甚至可能采用完全不同的阈值建议。
虽然我们肯定希望奖励有效的缓存实现，但我们不希望快速的网站内导航能够掩盖着陆页加载缓慢的问题。我们也不希望网站仅仅为了提高指标得分而将长网页拆分为一系列较短的网页。
通过分别评估跨源网页访问和同源网页访问，我们可以确保这两种体验都很重要，而不让某种体验在给定网站上的相对受欢迎程度扭曲任何特定指标的分布。
设计新的 API，以实现更好的 SPA 衡量
我们正在积极开发的另一种解决方案（与上述解决方案并行）是新的 App History API，它有助于标准化当前的 SPA 模式，并让您更轻松地衡量和了解 SPA 的大规模使用情况。
App History API 引入了新的 navigate 事件，该事件具有两个专门针对 SPA 衡量的关键功能：
- 一个
userInitiated标志，仅当导航是通过链接点击、表单提交或浏览器的返回或前进界面启动的，才会设置为 true。 transitionWhile()方法，该方法接受一个 promise，以便开发者在他们发起执行导航的工作完成时发出信号。
userInitiated 标志可用于确定 SPA 路由转换的语义起点，指明明确的用户意图。transitionWhile() 承诺解析有助于浏览器将绘制与特定路线转换相关联，以便确定与该转换相关的最大内容绘制。
在此基础上，我们甚至可以将 SPA 路由转换时间汇总到 MPA 中同源网页加载时间所在的同一存储分区中。这令人兴奋，因为这样一来，从 MPA 迁移到 SPA 的网站就可以实际比较迁移前后的效果。
当然，我们还需要进行更多研究，才能确定是否能够准确做出这些判断。如果您对这些提案有建议或反馈，请发送电子邮件至 web-vitals-feedback@googlegroups.com。
最后总结
Google 非常重视改进网页指标，并确保这些指标能够衡量对用户重要的优质体验并对其提供激励。不过，我们也承认，目前存在衡量差距。这些指标目前并未涵盖用户体验的方方面面，但我们正在积极努力填补这些空白。
尽管目前存在一些限制，但我们认为现有指标所涵盖的方面对网站的健康状况和成败至关重要。如果网站（无论架构如何）未达到建议的阈值，我们认为仍有改进空间。
希望这篇博文能帮助您对这个复杂而细致的主题有所了解。 和往常一样，如果您对当前或未来的 Web Vitals 指标有任何反馈，请发送电子邮件至 web-vitals-feedback@googlegroups.com。