文章首发于掘金，原文来自谷歌，字数3.4千字，文章中高级词汇较多，句子长且复杂，翻译比较难，我尽量用简单易懂的语言，为此我在每个问题的末尾，单独加了一个解读，帮助大家理解。尽管如此，难免会有疏漏，欢迎广大读者斧正，同时也欢迎大家点赞、转发。
感谢字节同学翻译最后部分，感谢支持
写在前面
仁者见仁
谷歌提出的只是部分见解，因为他们更致力于大而全的“通用”，这就直接导致在指标值的设定上就很宽松，再加上国内前端同学，几乎所有精力都放在了过程，比如开发工具的对比上，比如什么工程化，不是说工程化、组件化等开发提效不重要，但更重要的不应该是网站性能或者用户体验的投入吗？转念一想，这一点上，我们是否做的“不够多”?
取其精华
即便如此，本文依旧非常值得推荐阅读，推荐理由如下：
- 首先，你能了解谷歌对于提升用户体验做出的努力，也能直接的看到当前努力结果的一些不足。
- 其次，更新你对核心指标的理解
- 最后，了解到当前技术的一些趋势和动向，反思前端行业在用户体验这方面的投入力度
正文
自从2020年5月份引入网站指标，chrome团队收到了很多问题和反馈。
其中最多也或许是最难的，就是SPA页面的指标如何测量，以及SPA架构对核心指标是否有影响。
这些问题都很难回答，因为每个问题涉及的细节都很多，所以今天在这篇文章中，我们将尽最大努力，把最常见的问题，尽可能回答地详细和全面。
讲解之前，需要声明，谷歌并不推荐某种技术或者架构构建网站。我们认为SPA和MPA都能给用户带来很棒的体验，创建核心指标这个项目就是为了提供测量体验的指标。有的场景还有一些不足，我们也在积极地尝试弥补这些不足。
常见问题
核心网站指标包括SPA路由的切换吗？
核心网站指标只记录当前指标，特别需要指出，这里的当前指的是页面级别。如果页面动态引入新内容，同时更新页面地址栏的url，对于核心指标收集是不影响的，指标值也不会清空，而且每个指标是跟跳转后的url相关，与之前页面url无关。
解读：如果动态引入内容，但是url未发生变化，不会收集，但得分就不能正确反应页面的实际情况
核心网站指标中SPA路由切换和传统页面一样吗？
遗憾的是，目前为止，不一样。
目前SPA的构建方式没有标准化，即便是使用流行的SPA或者路由库，用户体验都可能千差万别：
- 一些SPA仅仅在新的"整个页面"内容加载时才更新URL，但也有一些哪怕仅仅只是更新小部分内容、甚至只是UI状态变化，就会更新URL
- 许多SPA使用history api更新url，但也有一些使用hash路由以兼容老浏览器（还有一些spa框架根本不更新URL）
- 许多SPA先加载内容然后更新URL，但是也有一些先更新URL再更新内容
- 许多SPA一次加载所有内容，同步方式，使用单个js任务，但也有一些使用异步方法，多个任务加载内容（而且没有明显的结束）
- 许多SPA总是通过网络加载内容，但也有一些预加载所有内容到前台，以便路由切换时能从内存中直接加载。
这些差异让定义、区别SPA的路由变化，甚至是定义SPA都变得异常困难。
在一些场景下，SPA路由切换逻辑上应该等同于MPA加载一个页面，在这种场景下，如果核心网站指标能够适用的话，会非常棒。
但是，没有经过对所有URL变化的可靠确认真正的路由跳转的探索，以及能清晰标识跳转开始和结束的时候，收集核心指标可能会污染数据，难以代表真实的用户体验数据。
解读：spa和mpa不一样，spa存在多种实现方式，也没有完全标准化
SPA在核心指标上性能不如MPA？
SPA架构中没有任何因素会影响页面的加载和在核心指标上的得分，其条件和MPA的页面是相似的。
但是，MPA页面经过一定优化后，确实在核心指标上比SPA更满足。原因是MPA架构中的页面，其加载是完整的，（而不是动态拉取内容然后插入到当前页面），浏览MPA的页面的用户更可能一次加载布置一个页面，当然这就让MPA有一大部分内容，比如主页面或者次级页面的资源能够被缓存。
当然，MPA要想胜过SPA页面需要满足以下条件：
- MPA需要优化次级资源的缓存，保证同源页面加载确实比非同源页面更快，这里的快均指的是75百分位。
- MPA用户需要多个页面都访问过，才能享受缓存优势，页面加载更快。
因为核心指标评估网站75分位的访问，所以在数据集中，性能表现良好的页面的访问越多，这就可能让75分位的页面在推荐值内。
注意：在比较性能得分时需要知道数据是如何聚合的，数据集是否包含所有的页面，还是只是单个特定页面URL。
在聚合网站页面的得分时，一些特定页面访问速度很快的话，就可能提高整体网站的75分位的占比。但是只考虑某个或者某些页面时，单个页面的得分是影响其他页面得分的。换句话说，聚合MPA页面得分时，因缓存快速加载的页面的得分，是不会提高落地页的初次加载的得分。
有很多方式可以查看网站得分，比如PageSpeed Insights或者 Chrome User Experience Report API，后者能给出单独页面的url和整站的得分。
SPA架构能影响核心指标，其中还有方面是需要考虑到页面的整个生命周期。因为用户访问SPA时，在整个回话中，一般是都停留在同一个页面，随着时间聚集的指标比MPA更harsher。
2021年4月份，我们宣布了在CLS这个指标的变化，能够部分解决这个问题。以前CLS会随着整个页面的生命周期来计算，现在只计算特定窗口制定页面的最糟糕的布局偏移。
但是即便有了新的CLS，SPA仍然处在劣势，因为CLS的指标不会在路由跳转后“重置”，也就是说和mpa页面加载不一样。这就可能导致疑惑，因为在路由跳转后的布局偏移计算到了加载后的url上面去了，而不是布局偏移后的新页面，更多详情可以戳我。
解读：spa页面如果能做好缓存，效果应该比mpa页面用户体验更好。
如果SPA架构能提高用户体验，不应该体现在指标上吗？
是的，应该体现。尽管前面提到了很多，但考虑到当前spa应用的不同情况，又很难精确量化用户体验提升了多少。
有关网站性能这方面历史上对于页面加载后的性能的投资，这里的投资指的是用户体验方面的时间和精力，完全是远远不如直接加载页面的投资那样多的。这并不是说页面加载后性能不重要，而是因为页面加载后的体验和交互千差万别，难以直接衡量和设计度量的指标。
但是即便我们没有很棒的衡量页面加载后的指标来测量SPA的性能，我们也不会因为加载性能比较好而去忽略加载后的性能。
网站核心指标其中一个目标是在加载和使用网站时的方方面面都能促进和激励更好的用户体验。
我们并不想鼓励出现体验不好的情况，用户希望页面加载足够快的同时，能够切换到最新的内容的速度也要快，我们正尝试设计新的api来满足这类需求。
尽管同版本的MPA页面可能在75分位比spa版本可能得分要好，但spa版本仍然可能满足“良好”的门槛。如果对于大多数用户来说spa不“良好”，可能是其最初的加载体验被视为不“良好”，即便后续页面的体验可能很优秀。
将来我们计划研发新的指标，用来激励是加载后的体验更棒，同时我们也相信，这是激励高质量SPA同时也不牺牲加载体验的最佳方式。我们已经提出一个新指标，叫做Interaction to Next Paint (INP) ，用来测量页面整个生命周期内的交互延迟，我们也在积极开发新的加载后的指标，其中就包括测量spa路由切换的指标。(点我查看)
解读：谷歌也在在针对spa做更多的尝试。
我们的架构从MPA改为SPA，指标得分降低了。这是正常情况吗？
答案不确定。如果架构出现大变化，得分变化的原因可能有很多，但是热缓存量减少可能是会是一部分因素。
有一个快速方法可以检测，就是把MPA和SPA的落地页使用Lighthouse测试。如果spa版本中一个或多个页面指标得分降低了，那可能确实是升级后加载体验降低了。
我该把网站从SPA改成MPA来让指标得分升高吗？
最好不要，只有对SPA不满意时，才建议迁移到MPA，而且最好先确定MPA一定能带来更好的用户体验。
随着时间来看，网站核心指标会改善并覆盖更多浏览器端上的体验，如果SPA已经有不是很差的用户体验，将来肯定能从网站核心指标得分上看出来。
解读：spa应该是趋势
如果网站核心指标只报告了SPA的落地页，我该如何在路由切换后调试页面发生的问题？
鉴于情况，本段暂不翻译，详情查看原网站。
谷歌正在做什么来确保MPA与SPA相比没有不公平的优势？
如上所述，在某些场景下，适当优化的MPA 在75分位会展现更好的Web Vitals分数，基于它可能有更高的概率访问页面缓存。相反，在适度优化的SPA中，真正的用户体验的改善没有被任何核心Web Vitals指标体现。
在Google，我们意识到这会诱发与Web Vitals计划的目标不完全一致的措施，我们正在积极寻找解决这个问题的方法。目前，我们正在探索两种潜在的解决方案，一种是短期的，另一种是长期的：
- 分别评估跨源和同源页面访问。
- 设计新的API以实现更好的SPA测量。
分别评估跨源和同源页面访问# 现在，Core Web Vitals指标将所有页面访问聚合到一个bucket中-它们不区分新访问与返回访问或登录页面与登出页面或任何其他聚合类型，这其中缓存状态可能会对性能产生影响。
将SPA和MPA表现之间的差异正常化的一种方法是对不同类型的访问应用不同的权重，甚至可能使用完全不同的阈值建议。
虽然我们确实想推行有效的缓存实现，但我们不希望站点内快捷导航去掩盖缓慢的落地页加载。我们也不希望激励网站仅仅为了提高指标分数而将长页面分解为短页面的集合。
通过分别评估跨源和同源页面访问，我们可以帮助确保这两种类型的体验都很重要，而不会让一种类型在给定网站上的相对普及扭曲任何特定指标的分布。 设计新的API以实现更好的SPA测量#
另一个正在积极研究的解决方案是一个新的App History API，它将有助于标准化当前的SPA模式，并更容易衡量和理解大规模SPA使用情况。 App History API引入了一个新的导航事件，它具有两个特定于SPA测量的关键特性：
- 一个用户发起 的标志，只有当导航通过链接点击、表单提交或浏览器的后退或前进UI启动时，该标志才会设置为true。
- 一个transitionWhile() 方法，它接受一个Promise，允许开发人员在他们启动以执行导航的工作完成时发出信号。
用户初始化标志可用于确定SPA路由转换的语义起点，明确的用户意图。
transitionWhile()确保解析可以帮助浏览器将绘制与特定的路由转换相关联，这样它就可以确定与该转换相关的最大内容绘制。
在上一节中提出的想法的基础上，甚至可以将SPA路由转换时间与MPA中的同源页面加载聚合到同一个bucket中。这令人兴奋，因为它允许站点从MPA迁移到SPA，以实际比较前后的性能。
谷歌致力于提高网站核心指标，旨在保证测量结果和激励高质量的体验给用户。尽管如此，我们必须承认当前测量体系距离真实的用户体验仍然存在差距。这些指标并不能完全覆盖到用户体验的全部内容，但我们正积极填补这些差距。
尽管有一些限制，我们相信当前的指标确能反应网站的健康程度，如果网站不满足建议值，确实是有提高的空间。
