原文链接：https://web.dev/vitals-spa-faq/

文章首发于掘金，原文来自谷歌，字数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路由切换的指标。(点我查看)