Get best of the week

JavaScript框架的价格

没有比在网站上使用一堆JavaScript代码更快的方法来减慢网站（例如双关语）的速度。使用JavaScript时，您必须为此付出至少四倍的项目性能费用。网站的JavaScript代码是通过以下方式加载用户系统的：

  • 通过网络下载文件。
  • 加载后解析并编译解压后的源代码。
  • JavaScript代码执行。
  • 内存消耗。

这种组合非常昂贵。 而且我们在项目中包含了越来越多的JS代码。随着组织转向基于框架和库（例如React，Vue等）的网站，我们使网站的主要功能非常依赖JavaScript。





我看到很多使用JavaScript框架的非常繁琐的网站。但是我对这个问题的看法有很大偏见。事实上，与我合作的公司之所以与我联系是因为他们在网站性能方面遇到了复杂的问题。结果，我好奇地发现了这个问题的广泛性，以及当我们选择一个或另一个框架作为某个站点的基础时，我们要付出什么样的“罚款”。HTTP Archive

项目帮助我弄清楚了这一点。

数据


HTTP存档项目总共跟踪到专用于台式机设备的常规站点的4,308,655链接，以及跟踪到移动站点的5,484,239的链接。与这些链接相关的许多指标中，有一个在相应站点上找到的技术列表。这意味着我们可以构建使用各种框架和库的数千个站点的样本，并找出它们发送给客户的代码量以及用户系统创建此代码的负载量。

我收集了2020年3月的数据，这些是我可以访问的最新数据。

我决定比较所有站点的聚合HTTP存档数据与检测到React，Vue和Angular的站点数据，尽管我正在考虑使用其他源材料。

为了使它更有趣-我还向源数据集添加了使用jQuery的网站。这个图书馆仍然很受欢迎。它还提供了一种网站开发方法，该方法不同于React，Vue和Angular提出的单页应用程序（SPA）模型。

HTTP存档中的链接，表示发现了我们感兴趣的技术的使用的站点
框架或库链接到移动网站链接到常规网站
jQuery的46154743714643
反应489827241023
Vue8564943691
角度的1942318088

希望和梦想


在继续进行数据分析之前，我想谈谈我希望获得的期望。

我认为，在理想的世界中，框架不仅应满足开发人员的需求，而且应为使用我们网站的普通用户提供一定的具体优势。性能只是这些好处之一。在这里，可访问性和安全性仍然浮现在脑海。但这只是最重要的。

因此，在理想的世界中，某个框架应该有助于创建高性能站点。之所以要这样做，要么是因为该框架为开发人员提供了一个不错的基础来构建项目，要么是由于该框架对开发施加了限制，并为此提出了要求，使开发变得缓慢的事情变得复杂了。

最好的框架应同时做到：提供良好的基础，并对工作施加限制，以取得体面的结果。

分析中位数数据值不会提供必要的信息。而且，实际上，这种方法在我们的关注范围之外还有许多重要意义。相反，我从以百分位数表示的数据指标中推论得出。这是10、25、50（中位数），75、90％。

我对第10和第90个百分位数特别感兴趣。第十个百分位代表特定框架的最佳性能（或至少或接近或接近最佳）。换句话说，这意味着只有10％的使用特定框架的网站可以达到此目标，或者达到更高的水平。另一方面，第90个百分位是硬币的另一面-它向我们展示了糟糕的情况。第90个百分位是编织站点-站点的最后10％以JS代码量最大或在主流中处理其代码所需的时间最长为特征。

JavaScript代码卷


首先，分析不同站点通过网络传输的JavaScript代码的大小是有意义的。

传输到移动设备的JavaScript代码（Kb）的数量

1025507590
93.4 196.6 413.5 746.8 1201.6 
jQuery-110.3 219.8 430.4 748.6 1162.3 
Vue-244.7 409.3 692.1 1065.5 1570.7 
Angular-445.1 675.6 1066.4 1761.5 2893.2 
React-345.8 441.6 690.3 1238.5 1893.6 


JavaScript-,

JavaScript- (),

1025507590
105.5 226.6 450.4 808.8 1267.3 
jQuery-121.7 242.2 458.3 803.4 1235.3 
Vue-248.0 420.1 718.0 1122.5 1643.1 
Angular-468.8 716.9 1144.2 1930.0 3283.1 
React-308.6 469.0 841.9 1472.2 2197.8 


传输到桌面设备的JavaScript代码的数量

如果我们仅谈论站点发送到设备的JS代码的大小，那么一切看起来都与您期望的一样。也就是说，如果使用其中一种框架，则意味着即使在理想情况下，该网站的JavaScript代码的数量也会增加。这不足为奇-您不能使JavaScript框架成为该站点的基础，并期望该项目的JS代码量非常少。

在这些数据中值得注意的是，某些框架和库可以被认为是比其他框架和项目更成功的起点。 jQuery网站看起来最好。在台式机版本的网站上，它们比所有网站包含的JavaScript多15％，而在移动版本上，其包含的JavaScript多18％。 （我必须承认，在这里您可以观察到数据的某些失真。事实是jQuery存在于许多站点上，因此很自然，这些站点比其他站点更靠近站点总数。但是，这并不影响方式。显示每个框架的源数据。）

尽管代码量增加了15-18％是一个值得注意的数字，但与其他框架和库相比，我们可以得出结论，jQuery收取的“税”非常低。排名第十的Angular网站向桌面设备发送的数据比所有网站和移动设备发送的数据多344％，向移动设备发送的数据多377％。在严重性方面排名第二的React网站向桌面设备发送的代码比所有网站多发送193％，向移动设备发送的代码多270％。

我已经提到过，尽管使用框架意味着在项目中将包含一定数量的代码，但是在开始工作之初，我希望框架能够以某种方式限制开发人员。特别是，我们正在谈论限制最大代码量。

有趣的是，jQuery网站遵循这个想法。尽管它们在第10个百分位级别上比所有站点（15-18％）稍重，但在第90个百分位级别上它们却比所有站点稍轻-在台式机和移动版中均减少了约3％。不能说这是一个非常重要的好处，但是可以说，jQuery网站至少在巨大的JavaScript代码方面，即使在其最大版本中，也没有什么不同。

但是其他框架不能说相同的话。

与第10个百分位数一样，Angular和React上的第90个百分位数站点与其他站点不同，但是不幸的是，它们之间的差异更糟。

与所有站点相比，Angular站点向移动设备发送的数据多于所有站点141％，向桌面发送的数据多159％，占第90个百分点。React网站向桌面设备发送的邮件比所有网站发送的邮件多73％，向移动设备发送的邮件多58％。第90个百分位数上的React网站的代码大小为2197.8 Kb。这意味着，与基于Vue的竞争对手相比，此类站点向移动设备发送的数据量多322.9 Kb。基于Angular和React的桌面站点之间以及其他站点之间的差距更大。例如，桌面React网站向设备发送的JS代码比类似Vue网站多发送554.7 KB的JS代码。

在主线程中处理JavaScript代码所花费的时间


以上数据清楚地表明，使用所研究的框架和库的网站包含大量的JavaScript代码。但是，当然，这只是我们方程式的一部分。

JavaScript代码到达浏览器后，需要使其进入工作状态。特别是许多问题是由那些必须使用浏览器主流中的代码执行的操作引起的。主线程负责处理用户操作，计算样式，构建和显示页面布局。如果您使用JavaScript事件填充主流，那么它将无法及时解决其他任务。这会导致页面工作的延迟和“刹车”。

HTTP存档数据库包含有关在V8引擎的主线程中处理JavaScript代码花费多少时间的信息。这意味着我们可以收集这些数据并找出主线程处理各个站点的JavaScript需要花费多少时间。

与移动设备上的脚本处理有关的CPU时间（以毫秒为单位）
百分位数1025五十7590
所有网站356.4959.72372.15367.310485.8
jQuery网站575.31147.42555.95511.010349.4
Vue网站1130.02087.94100.47676.112849.4
角位1471.32380.14118.67450.813296.4
反应站2700.15090.39287.614509.620813.3


与移动设备上的脚本处理有关的

CPU时间（毫秒）与台式设备上的脚本处理有关的CPU时间（毫秒）

百分位数1025五十7590
所有网站146.0351.8831.01739.83236.8
jQuery网站199.6399.2877.51779.93215.5
Vue-350.4650.81280.72388.54010.8
Angular-482.2777.91365.52400.64171.8
React-508.01045.62121.14235.17444.3


与在台式机设备上处理脚本有关的CPU时间在

这里您可以看到非常熟悉的内容。

对于初学者来说，使用jQuery的网站在主线程上的JavaScript处理上的花费明显少于其他网站。与所有网站相比，移动网站上的jQuery网站与所有网站相比，处于第10个百分点，在主线程中处理JS代码的时间增加了61％。对于桌面jQuery网站，处理时间增加了37％。在第90个百分位级别，jQuery站点指标非常接近聚合指标。也就是说，移动设备上的jQuery网站在主流上的时间花费比所有网站少1.3％，而台式机设备上的时间减少了0.7％。

另一方面，有些框架的特征是主线程上的最大负载。再次是Angular和React。它们之间的唯一区别是，尽管Angular站点向浏览器发送的代码量比React站点多，但处理Angular站点的代码所需的处理器时间更少。远不及。

与所有站点相比，台式机Angular站点在处理JS代码上花费的主线程时间多10％，占第10个百分点。对于移动网站，这个数字是313％。React站点的性能最差。在台式机设备上，他们花在代码处理上的时间比所有站点多248％，在移动设备上花了658％。658％不是错字。在第10个百分点，React站点花费2.7秒的主线程时间来处理它们拥有的代码。

与这些庞大的数字相比，第90个百分位数看起来至少好一点。与所有站点相比，Angular项目在主线程中的台式机设备上花费的时间增加了29％，在移动设备上的时间花费了27％。对于React网站，相似的指标分别为130％和98％。

第90个百分位数的百分比偏差看起来比第10个百分位数的相似值更好。但是，这里值得记住的是，指示时间的数字似乎很可怕。说-在基于React的网站的移动设备主流中20.8秒。 （我相信这段时间实际发生的故事值得写一篇单独的文章）。

有一个潜在的困难（谢谢Jeremy提请我注意此功能，并从这一角度仔细考虑了数据）。事实是，许多站点都使用几种前端工具。特别是，我看到许多将jQuery与React或Vue一起使用的网站，因为这些网站已从jQuery迁移到其他框架或库。结果，我再次转到数据库，这次仅选择与仅使用React，jQuery，Angular或Vue而不是它们的某些组合的站点相对应的那些链接。那就是我所做的。

在站点仅使用一个框架或仅一个库的情况下，与移动设备上脚本处理有关的CPU时间（毫秒）

百分位数1025五十7590
, jQuery542.91062.22297.44769.78718.2
, Vue944.01716.33194.75959.69843.8
, Angular1328.92151.93695.36629.311607.7
, React2443.24620.510061.417074.324956.3


在仅使用一个框架或仅使用一个库的情况下，与移动设备上的脚本处理相关的CPU时间

首先，这并不奇怪：当在站点上仅使用一个框架或一个库时，此类站点的性能通常会更高改善而不是改善。每种仪器的指标在10％和25％百分位数下看起来更好。这说得通。使用一个框架制作的网站应比使用两个或多个框架或库制作的网站更具生产力。

实际上，每种研究的前端仪器的指标在所有情况下看起来都比较好，减去一个奇怪的例外。我感到惊讶的是，在第50个百分点或更高的级别上，如果React是唯一使用它们的库，则使用React的站点的性能会更差。顺便说一下，这就是我将这些数据带到这里的原因。

这有点奇怪，但是我仍然尝试寻找这种奇怪的解释。

如果一个项目同时使用React和jQuery，那么这个项目很可能是从jQuery到React过渡的一半。也许它具有混合了这些库的代码库。既然我们已经看到jQuery网站在主线程上花费的时间比React网站少，所以这可能告诉我们在jQuery上实现某些功能有助于稍微改善网站的性能。

但是随着从jQuery到React的项目越来越依赖React，情况发生了变化。如果该站点的质量很高，并且该站点的开发人员谨慎地使用React，那么使用此站点一切都会很好。但是对于一般的React站点，React的广泛使用意味着主线程承受的负载增加。

移动设备与台式设备之间的差距


我查看所研究数据的另一观点是研究在移动设备和台式设备上使用网站之间的差距有多大。如果我们谈论比较JavaScript代码量，那么这样的比较不会显示任何可怕的东西。当然，看到较少的下载代码量会很好，但是移动代码和桌面代码的数量并没有太大差异。

但是，如果您分析处理代码所需的时间，则会发现移动设备和台式设备之间的差距非常大。

与台式机相比，与在移动设备上处理脚本有关的时间增加（百分比）
百分位数1025五十7590
所有网站144.1172.8185.5208.5224.0
jQuery网站188.2187.4191.3209.6221.9
Vue网站222.5220.8220.2221.4220.4
角位205.1206.0201.6210.4218.7
反应站431.5386.8337.9242.6179.6

尽管可以预料的是，手机和笔记本电脑之间的代码处理速度会有一些差异，但如此大量的数字告诉我，现代框架并未充分关注低功耗设备以及缩小差距的愿望。即使在第10个百分位，React站点在移动设备的主流中花费的时间也比在台式设备的主流中花费431.5％的时间。在jQuery中观察到最小的差距，但即使在此处，相应的指标也为188.2％。当网站开发人员进行他们的项目时，要花更多的处理器时间来处理它们（这种情况会随着时间的推移而变得更糟），低功耗设备的所有者必须为此付费。

摘要


好的框架应该为开发人员提供创建Web项目的质量基础（就安全性，可用性，性能而言），或者应该具有内置的限制，使得难以创建违反这些限制的内容。

这似乎不适用于Web项目的性能（显然也不适用于Web项目的可用性）。

值得注意的是，React站点或Angular站点比其他站点花费更多的CPU时间进行代码准备这一事实并不一定意味着React站点在工作过程中要比Vue站点负担更多的处理器。实际上，我们审查的数据几乎没有说明框架和库的性能。他们更多地讨论了这些框架可以有意识地推动程序员使用的开发方法。我们正在谈论框架的文档，框架的生态系统，常见的开发技术。

值得一提的是，我们在这里没有对其进行分析，即设备在网站的页面之间导航时花费了多少时间来执行JavaScript代码。支持SPA的理由是，从理论上讲，只要将单页应用程序加载到浏览器中，用户就可以更快地打开网站的页面。我自己的经验告诉我，这远非事实。但是我们没有数据可以澄清这个问题。

显然，如果使用框架或库来创建站点，则会在项目的初始加载和准备工作方面做出妥协。这甚至适用于最积极的情况。

在适当的情况下，很可能会做出一些妥协，但是开发人员有意识地做出让步很重要。

但是我们有理由保持乐观。 Chrome开发人员与我们已经审查过的一些前端工具进行了如此紧密的互动，以帮助改善这些工具的性能，这让我感到鼓舞。

但是，我是一个务实的人。新的体系结构解决它们时常常会产生性能问题。并且需要花费时间来修复缺陷。正如我们不应该期望使用新的网络技术来解决所有性能问题一样，我们也不应该期望我们所喜欢的框架的新版本能够实现这一点。

如果您想使用本材料中讨论的前端工具之一，则意味着您将不得不付出额外的努力来确保与此同时不损害项目的生产率。在开始使用新框架之前，有一些注意事项：

  • 根据常识测试自己。您真的需要使用所选的框架吗？如今，纯JavaScript的功能非常强大。
  • 除了所选框架（Preact，Svelte或其他工具）之外，还有没有更简单的替代方法可以为您提供此框架90％的功能？
  • 如果您已经在使用某种框架，请考虑是否存在提供更好，更保守的标准选项的示例（例如，用Nuxt.js代替Vue，用Next.js代替React，等等）。
  • 您的JavaScript性能预算是多少？
  • 您如何限制开发过程，以使大量JavaScript代码的实施复杂化到项目中而不是绝对必要的？
  • 如果为了方便开发而使用框架，请考虑是否需要将框架代码发送给客户。也许您可以解决服务器上的所有问题？

通常，这些想法值得一看，无论您选择了什么开发前端。但是在您从一开始就缺乏生产力的项目中工作时，它们尤其重要。

亲爱的读者们！您如何看待完美的JavaScript框架？

More articles:


All Articles