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