如何使用Google CrUX来分析和比较JS框架的性能？
近年来，框架已经占据了Web开发，而React正在引领这一潮流。这些天来，很少有新的网站或网络应用不依赖一些框架或CMS等平台的情况。
虽然React的口号是 "构建用户界面的JavaScript库"，而不是一个框架，但我认为这艘船已经起航：大多数React开发者认为它是一个框架，并以此来使用它。或者他们把它作为一个更大的应用框架的一部分来使用，比如NextJS、Gatsby或RemixJS。
但是，作为网络开发者，我们为这些框架提供的改进的开发者体验付出了什么代价？更重要的是，如果有的话，我们的用户要为我们的这种选择付出什么代价？
最近Noam Rosenthal发表了两篇文章，分析了各种框架所提供的共同优势和能力，以及它们的相关成本。我强烈建议大家去看看这两篇文章。Noam提到的成本之一是由于使用框架和其他库而增加的下载量，特别是JavaScript捆绑量。特别是，下载的JavaScript数量的增加会对网站性能产生直接影响。而且，框架使用的其他方面也会影响性能。
在这篇文章中，我将根据谷歌浏览器用户体验报告（简称CrUX）收集的现场数据，分析与各种框架相关的性能成本。我认为这些信息既有趣又有用，特别是考虑到目前前端和全栈开发者可选择的各种框架和平台。
然而，在审查这些数据时，重要的是不要把相关性和因果关系混为一谈。使用某个特定框架构建的网页比另一个框架有更好或更差的性能，并不意味着框架本身总是有问题的。例如，这可能是因为某些框架更常用于构建较重的网站。
也就是说，这些数据可以帮助我们在实施前端项目时就选择哪个框架做出明智的决定。在可能的情况下，我更喜欢那些具有较高良好性能比的框架。
从现场收集核心网络生命体征
正如我之前提到的，我这次分析的主要数据来源是Google CrUX。CrUX是一个基于云的数据库，从实时的Chrome浏览器会话中收集真实用户测量数据（RUM）。如果你选择了同步浏览历史，没有设置同步口令，并且启用了使用统计报告，那么每当你使用Chrome浏览器加载网页时，有关你的会话信息就会自动报告给CrUX。特别是，收集的测量数据包括为每个会话测量的三个核心网络指标。
近年来，这些指标已成为现代网络性能分析的基石。
对于每一个这样的指标，谷歌已经定义了可以被认为是好（绿色）、平均/需要改进（橙色）和差（红色）的范围。
从2021年6月开始，这些指标已经成为谷歌搜索的一个排名因素。这也增加了它们的重要性。
除了为每个这样的会议收集现场数据外，还使用WebPageTest工具对网站进行了合成测量。这些实验室测量结果被收集到另一个叫做HTTP档案的在线存储库。这包括使用Wappalyzer服务分析一个网页使用了哪些技术，包括哪些JavaScript框架。
谷歌利用其BigQuery项目使其有可能对这两个集合执行查询。然而，从这些数据中获得洞察力的最简单方法是使用Rick Viscomi创建的核心网络活力技术报告。(Rick是谷歌的工作人员DevRel工程师，负责管理CrUX和HTTP档案。)这份报告提供了一种手段，可以交互式地将各种基于网络的平台和技术的性能相关数据绘制成图表，并轻松地将它们进行相互比较。
在这篇文章中，我主要依靠从分析使用Core Web Vitals技术报告的数据中获得的洞察力。
在分析这些数据时，有一些注意事项需要注意：
- 虽然现场数据是按页面收集的，但技术报告是按来源显示的。原点值是该原点的所有页面的值的总和，根据页面流量计算出加权平均。
- 另一方面，好的产地的比率是不加权的。这意味着，一个流量相对较少，但足以被纳入数据集的来源，与一个非常受欢迎、高流量的来源被同等计算。这方面的计算可以通过过滤流行排名的来源来缓解
- HTTP Archive只分析每个来源的主页。这意味着框架的确定只针对主页，而属于该来源的所有其他页面都会被汇总，不管它们是否使用框架，甚至使用其他框架。
- 子域被作为不同的起源来衡量。
比较JavaScript框架的CWV
让我们先来比较一下各种JavaScript框架的性能。具体来说，在使用这些框架建立的网站中，在所有三个CWV指标中获得良好（绿色）分数的网站所占比例。在所有三个CWV指标上都有良好得分的网站应该在性能上提供更好的用户体验，也有资格获得最大的谷歌搜索排名提升。
我对数据进行了过滤，只包括美国的会话，以消除不同框架之间不同地理分布的影响。图中的ALL线指的是CrUX中的所有网站，而不仅仅是那些使用框架的网站，它被用作比较的参考。
在美国，主要框架的网站中，所有绿色CWV的百分比，在移动端上的会议。(大图预览
)
注意：这里的移动设备不包括iOS设备，如iPhone。这是因为iOS上的Chrome只是Safari核心的一个薄薄的包装，并不测量或报告CWV。（iOS上的所有浏览器都是如此，它们在内部都只是Safari。）
首先，我们可以看到，不同的框架产生了明显不同的结果。此外，无论好坏，这些结果在过去的一年中大多是稳定的。(Preact是一个例外，我将很快解释这种变化的原因)。这表明分数是有意义的，而不是侥幸，或统计异常的结果。
根据这些测量结果，正如Noam Rosenthal的文章所指出的，使用框架确实需要付出性能成本：通过与ALL基线的比较，我们看到使用任何这些框架构建的网站通常比没有框架的网站更不可能有良好的CWV。虽然一些框架如React、Preact和Svelte确实接近总体平均水平，但有趣的是，没有一个框架的性能比其他框架明显更好。
React和Preact基本上是并驾齐驱的--考虑到Preact比React小得多，有些人可能对此感到惊讶：大约4KB的下载量与32KB的下载量（在两种情况下都是经过粉碎和压缩的）。显然，在大多数情况下，这28KB的下载差异并不明显。Jason Miller，Preact的创建者最近对此有这样的说法。
Preact与任何特定的SSR或服务解决方案没有关系，这对CWV的影响占主导地位。虽然Preact的使用可能与CWV有一些关联（实际上只有FID），但它远没有页面交付中的技术选择那么直接。
- Jason Miller 🦊⚛（@_developit）2022年2月11日
我将在本文后面更详细地检查服务器端渲染（SSR）和静态网站生成（SSG）作为页面生成/交付选项的影响。
Vue和AngularJS都处于第二梯队--在移动端获得良好的CWV的可能性约为20-25%，而在桌面端则为15-20%。(同样，不包括iOS。)这就是说，Vue似乎正在取得进展，并慢慢缩小与React在性能方面的差距。
Preact性能的大幅下降与框架本身或其使用的任何变化无关。相反，它与Preact被Wappalyzer识别有关。不幸的是，这项服务错过了2021年11月之前对Preact的大部分使用。因此，Preact的早期结果应被忽略，因为它是无效的。
检查顶级网站
当我们把视野限制在美国前100万个网站时（基于流量），一个有趣的变化是，Vue几乎赶上了React，因为使用Vue的网站具有良好的性能的比例上升了，而React则令人惊讶地下降了。
美国排名前100万的网站中，拥有领先框架的所有绿色CWV的网站百分比，以及在移动端上的会话。(大型预览
在美国排名前100万的网站中，拥有所有绿色CWV的领先框架的网站百分比，桌面上的会话。(大号预览
我们在前10万个网站中也看到了同样的行为，React的比例实际上下降了，所以Vue稍微超过了它。我没有尝试对结果进行更多的限制，因为一些框架的使用数量下降得如此之低，以至于它们不再具有足够的统计学意义。
但从我们所掌握的数字来看，Vue的性能在高流量的网站上有所提高，这也许表明用Vue实现良好的性能需要在该框架上有更多的专业知识，而不仅仅是能够使用它？这是因为高流量的网站更有可能是由那些有能力雇用具有更多专业知识的开发人员的组织建立的。此外，更大的组织有能力在优化性能的基础设施上花费更多。
另一方面，当限制以流量衡量的网站数量时，React网站实际上会下降。
为什么拥有更多专业知识的React开发人员显然不太可能产生快速加载的网站？
嗯，这是一个非常有趣的谜题，我将尝试解决。
分析每个指标
除了将CWV作为一个整体来研究外，技术报告还可以对每个指标进行单独研究。让我们先看看FID。
具有绿色FID的领先框架的网站百分比，在美国的手机上的会话。(大号预览
你可能已经预料到，使用框架的网站会在响应性指标上付出代价，因为它应该是受大量使用JavaScript影响最大的指标。但是，在实践中，情况并非如此。事实上，FID指标基本上没有意义，所有框架都获得了几乎完美的分数。
即使是看集合中的所有网站的汇总，情况也是如此。出于这个原因，谷歌正在研究一个更好的响应性指标，并要求对他们已经在测试的实验性指标进行反馈。
考察LCP指标更有意义。
在美国，拥有绿色LCP的领先框架的网站百分比，在移动领域的会话。(大号预览
有趣的是，LCP分数在整体上与CWV很匹配，但更加分散。ALL、React、Preact和Svelte大约高出10%，而Vue和AngularJS基本保持一致。但当我们限制在前100万个网站时，我们看到Preact和Svelte又提高了一些，但React却没有。结果是，Vue追上了它。
美国排名前100万的网站中，拥有领先框架的绿色LCP的网站百分比，在移动端上的会话。(大号预览
最后让我们看一下CLS，从所有网站开始。
美国领先框架的绿色CLS的网站百分比，在移动端上的会话。(大号预览
而对于前100万个网站：
美国排名前100万的网站中，拥有绿色CLS领先框架的网站百分比，在移动端上的会话。(大号预览
在这里，我们看到React和Preact，尤其是React，都在大幅下降，结果是Vue超过了它们两个。
换句话说，对于Vue来说，当我们只检查顶级网站时，良好的LCP和CLS的比例都在提高。另一方面，对于React来说，LCP基本保持不变，而CLS实际上有所下降。
这可能表明，使用React的顶级网站性能下降的一个原因是页面上的广告量增加了。广告经常对CLS产生不利影响，因为当它们出现时，会把其他内容推倒。然而，我认为情况并非如此，因为它不能解释React和其他框架之间的行为差异。另外，你会期望广告也会影响LCP，但我们看到LCP基本上保持不变。
为了更好地理解这种行为，让我们检查一下技术报告中可视化的其他网页方面。
分析其他网页方面
除了性能分数之外，技术报告还可以分析资源下载的大小。众所周知，一个页面所使用的JavaScript数量会对其性能产生直接影响，因为所有的代码都需要被下载、解析和执行。让我们比较一下各种框架所下载的JavaScript数量。
美国移动端的JavaScript下载大小（KB）。(大号预览
)
不出所料，使用框架的网站下载的JavaScript明显多于一般的网站。这是由于单页应用程序（SPA）所需的所有功能，如路由和客户端渲染。
同样不足为奇的是，使用Svelte构建的网站比其他这些框架下载的JavaScript更少。这是由于Svelte的编译器在构建时处理了很多其他框架需要在运行时执行的功能。因此，Svelte不需要部署这些功能所需的代码。也有可能是使用Svelte的开发者比使用其他平台的开发者更重视提供精简的网页。
也就是说，Svelte网站和React网站的中位数相差226KB，这只意味着具有良好CWV的网站数量增加了2.4%。这凸显了浏览器在处理较大的JavaScript有效载荷方面所取得的惊人进步，例如在下载过程中通过解析主线程以外的JavaScript。我认为浏览器和CDN中的缓存也对此有贡献。
同样有趣的是，使用Preact的网站和应用程序实际上比使用React的网站和应用程序下载更多的JavaScript。也许这些网站选择Preact是为了减少其总重量。无论如何，这可能解释了为什么我们没有看到Preact比React有明显的性能改进：无论Preact提供了什么好处，都被应用程序代码本身所抵消。
当我们看前100万名时，我们看到JavaScript的数量增加了，只有Vue是一个有趣的例外。
美国前1,000,000个网站的移动端JavaScript下载量（KB）。(大号预览
)
这可能解释了为什么我们看到Vue在顶级网站上有如此明显的改进，而不是其他框架。在其他框架的情况下，似乎无论顶级网站的开发者拥有怎样的专业知识，都不能转化为减少的JavaScript下载量。事实上，情况恰恰相反--也许是由于这些网站提供的额外功能。
另一个非常有趣的比较是下载的图像数据量。
在这里我们看到，使用React、Svelte和Angular构建的网站下载的图像数据明显少于一般网站。这可能与这些网站利用现代技术减少图片下载有关，如懒惰加载和较新的图片格式。有趣的是，Angular网站下载的图像数据明显少于任何其他框架。
看一下顶级网站，我们看到图片下载量全面大幅增加。
这可能与顶级网站的内容更丰富有关。特别是，顶级网站可能有更多的广告，这些广告主要是图片。而且，正如我们将看到的，也有其他可能的解释。
SSR和SSG的影响
正如杰森-米勒在我之前引用的推文中所说，涉及网页交付的技术选择对CWV指标的影响最大，尤其是对LCP。服务器端渲染（SSR）和静态网站生成（SSG）等技术从一开始就向浏览器提供内容丰富的HTML，使其能够在内容到达时立即显示。这通常比客户端渲染技术生成的视觉内容要早得多，特别是当内容丰富的HTML被缓存在CDN或浏览器本身时。然而，在使用JavaScript框架时，正确实现这种操作方法所需的基础设施可能是一种挑战。因此，近年来我们见证了多个网络应用程序框架的引入，这些框架为领先的JavaScript框架和UI库提供了开箱即用的这种功能。
鉴于这一切，我们期望使用这些网络应用程序框架构建的网站比仅使用JavaScript框架或库构建的网站具有明显更高的良好CWV指标比例。
为了确定情况是否确实如此，我使用Core Web Vitals技术报告来比较React、Vue和Svelte总体上具有良好CWV的网站比例与建立在它们之上的领先Web应用框架的相同比例。
我们立即注意到，SvelteKit能够提供比其他一切都高得多的性能。也就是说，在这个数据集中只有33个网站使用SvelteKit。这个数字太低了，无法对其持续提供良好性能的能力做出结论。但是，随着使用量的增加，它的性能是否能够保持，将是一件有趣的事情。
我们可以看到，虽然Gatsby框架确实提供了比React总体上高得多的良好CWV比例，但NextJS的情况并非如此。虽然NuxtJS确实提供了比一般Vue更好的比率，但这个比率仍然低于React。
另外，我为什么要把Wix包括在这个图中呢？毕竟，Wix不是一个建立在JavaScript框架之上的Web应用框架。或者说它是吗？
实际上，Wix是用React实现的，因此，每一个Wix网站也被识别为React网站，就像Gatsby和NextJS一样。换句话说，即使你在使用Wix时没有明确地写React代码--毕竟它是一个拖放式网站建设工具--它确实为你生成了一个React网站。此外，Wix也像Next.js一样采用了SSR，并像NextJS和Gatsby一样使用CDN。而且它的良好性能比它们都要高。
现在让我们考虑一下使用这些技术中的每一项所建立的网站的数量。
Wix不仅大大超过了流行的网络应用程序框架，而且事实上，在美国约有三分之一的React网站实际上是Wix的网站
这很重要，因为在如此高的比例下，Wix的性能明显影响了React网站整体的性能测量。幸运的是，正如我们在性能图中看到的那样，Wix实际上比一般的React网站有更高的良好CWV比率。换句话说，Wix实际上提高了为React测量的性能分数。
但是，当我们限制在美国的前100万个网站时，比例发生了很大变化。
当只看前100万个网站时，Wix和所有其他网络应用框架在React网站总数中的比例明显下降。在这个数据集中，只有14%的React网站是用Wix构建的。这意味着，当只看顶级网站时，Wix对React总体性能的影响大大降低。这是一个重要的原因，当只检查顶级网站时，React的良好性能比实际上会下降，这与其他JavaScript框架不同。
换句话说，Wix是解决React出乎意料的性能概况之谜的方法。
网络应用程序框架的性能指标
但NextJS和NuxtJS呢？为什么它们没有提供我们在Gatsby（以及Wix）上看到的全面的预期性能优势？单独分析每个指标可能会发现这种行为的根本原因。
和以前一样，FID指标对总体性能比基本上没有影响，因为所有框架都实现了97%以上的良好FID比。
当我们比较CLS比率时，事情变得更加有趣。
我们可以看到，NextJS实际上超过了React，但Gatsby仍然领先。另外，NuxtJS在Vue和React之间，处于中间位置。
由于所有这些框架都有基本相同的良好FID比率和接近良好的CLS比率，这表明这些框架之间的差异的主要原因是LCP。
正如预期的那样，我们看到Gatsby明显领先于React，而且React总体上也领先于Next.js。鉴于NextJS采用了SSR / SSG和现代图像格式，这令人惊讶。当然，这是在利用该框架时需要注意的问题。
近几个月来，NuxtJS在这方面取得了重大进展，并在良好的LCP方面超过了NextJS，这与React的总体情况基本相同。
让我们看看LCP的差异是否可以用图片下载大小来解释，因为较大的图片往往不利于LCP。
有趣的是，使用NuxtJS和Vue的网站下载的图片数据明显多于使用React的网站，尽管如此，NuxtJS还是能够实现相当好的LCP比率。
Gatsby和NextJS在下载的图片数据量方面都很高效。这意味着Gatsby所提供的改进的良好的LCP比率并不仅仅源于图像大小的减少。对我来说，这表明Gatsby很可能能够更早地开始下载最大的图片，并更好地将其与其他页面资源进行优先排序。
有趣的是，Gatsby主页使用WebP的图像，而NextJS主页使用AVIF。
总结
我在本文中评论的所有框架都有高于0%的良好性能比率，这意味着你可以使用其中任何一个框架建立快速加载的网站，正如CWV所衡量的那样。同样，所有这些框架都有低于100%的良好性能比，这意味着你也可以用它们中的任何一个建立慢速加载的网站。
也就是说，我们看到各种框架的良好性能比之间存在明显差异。这意味着，使用一个特定框架构建的网站具有良好性能的可能性与另一个框架相比可能会有很大的不同。当然，这是在决定使用哪个框架时需要考虑的问题。
另一方面，我们也看到，这种差异可能会产生误导--例如，最初看来，React的良好性能比率明显高于Vue。但是，当我们通过只看较高流量的网站，有效地排除了大多数Wix网站，这些网站被包含在React的统计中，Vue实际上追上了React。
此外，某些以更强调性能而闻名的框架，如Preact和Svelte，对CWV来说不一定有优势。当谷歌在CWV中引入一个新的响应性指标来取代FID时，他们的影响是否会增加，这将是很有趣的事情。
更令人惊讶的是，一些Web应用框架也没有优势，尽管它们内置支持SSG/SSR和使用CDN。换句话说，使用Web应用框架并不是性能的银弹。
特别是，NextJS和NuxtJS在提高使用它们构建的网站具有良好的CWV的概率方面，似乎还有一段路要走。他们的图表有明显的上升趋势，特别是NuxtJS，但仍然明显低于Gatsby或Wix，甚至是所有网站的总体比例。希望他们的改进能继续下去，并成功追赶上。
