解答了有关 SPA、Core Web Vitals 和 Google 解决当前衡量限制的计划的问题。
自 2020 年 5 月首次推出网页指标计划以来， 收到了许多关于 计划。
关于我们收到的问题最多的这个主题，也许就是 最难回答的问题可能就是 如何在 Google Play 上 单页应用 以及 SPA 架构如何影响 Core Web Vitals 得分。
这些问题很难回答，因为问题非常微妙， 在本篇博文中，我们将尽力回答一些最常见的问题， 提供尽可能多的细节和背景信息。
不过，在深入介绍具体细节之前，有必要说明一下 对用于构建 网站。我们认为 SPA 和多页应用 (MPA) 都能够 为用户提供优质体验的理念，这也是我们开发 Web 的初衷。 Vitals 计划旨在提供衡量用户体验的指标，无需依赖 技术的概念。虽然目前这并不适用于所有情况（由于 限制），我们正在积极努力解决 差距。
常见问题解答
Core Web Vitals 指标是否包含 SPA 路由转换？
不是。每项 Core Web Vitals 指标都是相对于当前 顶级网页导航。如果页面动态加载新 内容，并在地址栏中更新该网页的网址后，系统便不会再 对 Core Web Vitals 指标衡量方式的影响。指标值不是 与每个指标衡量结果相关联的网址即为 会转到发起网页加载的那个网页
Core Web Vitals 指标能否像处理传统网页加载一样处理 SPA 路由更改？
很遗憾，还不能。现在还不是。
目前构建 SPA 没有标准化方法，即使是 SPA 和路由库，那么用户体验 从应用到应用：
- 某些 SPA 仅在加载新的“整页”时更新网址内容，而 其他网站会在内容细微变化（甚至是界面状态）发生变化时更新网址 更改。
- 有些 SPA 使用 History API 更新网址，而另一些 SPA 则使用哈希 以便支持旧版浏览器（其他浏览器不会更新网址， ）。
- 有些 SPA 先加载内容，然后更新网址，而有些 SPA 则会更新网址 然后再加载内容
- 一些 SPA 会在单个 JavaScript 中一次性同步加载所有内容 而其他任务则是将内容以异步方式、跨多个 任务（没有明确的过渡结束事件）。
- 有些 SPA 始终从网络加载内容，而有些 SPA 则预加载所有 以便路线变更立即从内存加载。
这些差异有助于定义和识别 SPA 路由的构成 大规模操作都非常困难。
在某些情况下，SPA 路由更改在逻辑上与 MPA 网页加载完全相同， 在这种情况下，如果现有的 Core Web Vitals 指标 错误。
但是，没有可靠的启发法来可靠地识别“真实”从此处出发 所有其他网址更改，以及标记起始和结束位置的明确信号， 在这些情况下，报告 Core Web Vitals 指标可能不够准确 并降低数据的实用性或对真实用户体验的代表性 。
SPA 在 Core Web Vitals 上的表现是否比 MPA 更难？
SPA 架构本身并无会阻止网页 因此 SPA 的加载速度非常快，并且所有核心部分的得分都一样 网页指标 - 就像 MPA 中的类似网页一样。
不过，经过适当优化的 MPA 在满足核心 Web 要求方面确实具有 SPA 目前无法达到的 Vitals 阈值。原因是 MPA 每个“页面”会作为整页导航（而不是 动态提取内容并将其插入现有网页），这可以实现 意味着访问 MPA 的用户更有可能从 这反过来就意味着 MPA 的网页加载会涉及到网页中的 缓存内容。
不得不提，MPA 在 Core Web Vitals 指标方面的表现要优于 SPA 必须满足以下所有条件：
- MPA 需要优化子资源缓存，以确保 同源网页的加载速度确实比 第 75 百分位。
- 访问 MPA 的用户需要访问多个网页， 获得可加快页面加载速度的缓存优势。
由于核心网页指标评估考虑的是第 75 个 网页的第 百分位 访问次数，那么数据集内效果良好的网页访问次数越多， 分布在第 75 个百分位的访问次数将是 不超过建议的阈值。
请注意，在比较 Core Web Vitals 得分时，需要考虑的重要事项是 就是数据的汇总方式，也就是说，分布中的数据集 包含您网站或源中的所有网页，或者仅包含特定网站的网页加载 页面网址。
在对一个来源中所有网页的得分进行汇总时，各个速度快的网页 提高整个来源的第 75 百分位。但是，汇总时 一个网页的得分并不会影响 继续。换句话说，当按页面汇总 MPA 的得分时，快速缓存 结账页显示的加载次数不会提高初始慢速得分的得分 用户在登录 Google 时获得的 页面。
您可以使用 PageSpeed Insights 或 Chrome 用户体验报告 API ，其中会报告各个网页网址和整个源的得分。
SPA 架构影响 Core Web Vitals 得分的另一种方法是 这类指标考虑的是网页的完整生命周期由于用户访问 SPA 会停留在同一“页面”上累计指标 随着时间的推移，SPA 会比 MPA 更严格。
2021 年 4 月，我们宣布了 CLS 指标变更， 在一定程度上解决了这个问题。之前，CLS 会在 而现在它只会在特定时间范围内累积 这基本上是指定网页上最严重的布局偏移。
不过，即使采用新的 CLS 定义，SPA 也仍然处于不利地位 因为 CLS 值没有“重置”像之前那样 以 MPA 格式加载整个网页。这也会导致混淆 路线转换后发生的偏移将归因于 网页，而不是转移时地址栏中的网址 （更多详情 下文）。
如果 SPA 架构改善了用户体验，那么这种改进是否应该反映在指标中？
是的，应该。尽管我们前面已经提到过， 很难大规模地提高用户体验， 当今网络上 SPA 的实施方式。
事实上，网络性能行业（包括 Google）从来没有 投入了几乎同样多的时间和精力来开发以用户为中心的 指标 与网页加载本身的相同。这并不是因为后载 并不重要，因为加载后的用户体验和互动 变化更大，定义也更不明确，因此很难为 。
但是，即使我们确实已明确定义加载后指标来衡量 SPA 我们不能仅仅因为 改善了后期加载体验
Web Vitals 计划的其中一项目标是提倡和激励 在加载和使用网页时，会尽可能多地改善用户体验 我们不希望鼓励用户 用户 都希望网页能够快速加载并快速过渡到新内容，我们一直力争 设计指标。
因此，尽管 MPA 版本的网站在 Core Web 上的效果更好， Vitals 指标的第 75 百分位，与完全一样的 SPA 版本相比 SPA 版本仍应力求满足阈值。如果 SPA 版本不符合“良好”条件初始值，则初始值 但加载体验可能仍不尽如人意 - 即使随后 页内导航体验非常棒。
今后，我们计划制定相关指标，以便鼓励用户通过 并且我们认为这是鼓励高质量客户 这类 SPA 不影响初始加载体验。我们有 我们已经提供了一个名为 Interaction to Next Paint (INP) 的新指标，该指标会衡量整个网页生命周期中的互动延迟时间，我们正在积极开发其他 加载后指标，包括衡量 SPA 路由转换的指标 （请参阅下文）。
我们将网站从 MPA 改为 SPA，得分也随之下降。这是正常现象吗？
这要视具体情况而定。有很多原因可能会导致您的得分在 进行了重大架构迁移，但热缓存加载次数有所减少 可能造成部分变化。
一种快速的检查方法是：同时测试一个应用的 MPA 和 SPA 版本 着陆页 Lighthouse。如果 Lighthouse 在 SPA 的 Core Web Vitals 指标中得分较低 那么加载体验之后，加载体验 更新。
我是否应将网站从 SPA 切换为 MPA，以便在 Core Web Vitals 上获得更高的得分？
一般不会。除非你不满意，否则请勿从 SPA 改为 MPA 而且有理由相信 MPA 能提供更好的 用户体验。
随着 Core Web Vitals 指标的改进并涵盖更多完整数据 打造卓越用户体验的 SPA 团队应具备以下特点： 希望看到其 Core Web Vitals 得分能够反映这一点。
如果系统仅针对 SPA 的着陆页报告 Core Web Vitals 得分，该如何调试“网页”上出现的问题会发生什么情况？
可报告核心网页指标的实测数据（例如 Google 搜索）的 Google 工具 控制台和 PageSpeed Insights）从“Chrome 用户体验”页面获取数据 报告 (CrUX)。CrUX 按来源或网页网址（即 网页网址）。
由于上述所有原因，CrUX 无法按照 SPA 路由。不过，作为熟悉自己架构的网站所有者， 您可以自行衡量效果 并且许多分析工具都允许您 在 SPA 路线发生变化时发出信号，并更新测量结果 数据。
使用分析工具衡量网页指标时，请确保您： 同时衡量当前路线网址和原始网页的网址。这将 可让您调试整个页面上出现的各个问题 同时按原始网页网址进行汇总，以便与 Google 工具会衡量和报告这些指标
如需关于此主题的更多详细信息和最佳做法，请参阅：调试 字段。
Google 采取了哪些措施来确保 MPA 没有获得与 SPA 相比的优势？
如上所述，经过适当优化的 MPA 在某些情况下 网页指标的得分是第 75 百分位，这是因为 缓存网页访问次数的比例较高。反过来， 目前未捕获经过适当优化的 SPA 中的用户体验 任何核心网页指标
Google 认识到，这会造成无法完全契合的激励措施 Web Vitals 计划的目标，我们正在积极探索 来解决此问题。目前，我们正在探索两种可能的解决方案，一个短期内有效 以及一个更长的期限：
- 分别评估跨源和同源网页的访问。
- 设计新的 API，以实现更好的 SPA 衡量。
分别评估跨源和同源网页的访问
目前，“Core Web Vitals”指标会汇总所有网页访问次数 不会区分是新用户还是回访用户， 网页与结账页，或缓存状态的任何其他汇总类型 可能会对性能产生影响
对 SPA 和 MPA 性能之间的差异进行标准化的一种方法是， 对不同类型的访问应用不同的权重， 完全不同的阈值 建议。
虽然我们当然要奖励有效的缓存实现，但 希望站内快速导航能够弥补速度较慢的着陆页 。我们也不希望鼓励网站将较长的网页拆分为 收集较短的网页，以提高指标得分。
通过单独评估跨源和同源网页的访问，我们可以帮助 确保这两种体验都很重要， 某一类型在给定网站上的受关注程度会导致任何特定 指标。
设计新 API 以更好地衡量 SPA
目前正在积极开发的另一种解决方案（与上述方案并行）是 新的 App History API，有助于使当前的 SPA 模式，让您能够更轻松地大规模衡量和了解 SPA 使用情况。
App History API 引入了
navigate 事件，
具有两个专门针对 SPA 衡量的关键功能：
- 答
userInitiated标记，那么仅当导航是通过 链接点击、表单提交或浏览器的后退/前进界面。 - 答
transitionWhile()方法，该方法带有一个 promise，可让开发者 就完成了
userInitiated 标志可用于确定
SPA 路由转换，表明用户意图明确。transitionWhile()
promise 解析可帮助浏览器将绘制与特定路由相关联，
以便能够确定最大内容渲染时间
与此次转变相关的重要信息
基于上一部分介绍的创意，我们甚至可能 可将 SPA 路由转换时间汇总到与 在 MPA 中加载同源网页。这令人兴奋，因为它可以让网站 从 MPA 迁移到 SPA 。
当然，我们还需要进一步研究，才能知道 做出这些决定。如果您对这些方面有任何建议或反馈 提案，请发送电子邮件 web-vitals-feedback@googlegroups.com。
最后总结
Google 致力于改进网页指标，以及确保 它们会衡量和激励用户获享的高质量体验 用户。尽管如此，我们也承认，目前衡量机制存在缺口。通过 指标目前不能全面涵盖用户体验的方方面面，不过， 努力弥补这些差距。
尽管目前存在一些局限性，但我们认为现有指标存在的领域 捕获对网络的健康和成功至关重要，在一定程度上 确保网站（无论采用何种架构）未达到建议的阈值， 但我们认为仍有改进的空间。
我希望这篇帖子能够帮助您理解这个复杂而微妙的主题。 与往常一样，如果您对当前或未来的 Web Vitals 指标有反馈意见， 请发电子邮件 web-vitals-feedback@googlegroups.com。