JavaScript 框架的价格

没有比在网站上运行一堆 JavaScript 代码更快的减慢网站速度的方法了（没有双关语）。 使用JavaScript时，你至少要在项目性能上付出四倍的代价。 以下是该网站的 JavaScript 代码加载用户系统的内容：

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

这个组合结果是 非常贵.

我们的项目中包含越来越多的 JS 代码。 随着组织转向由 React、Vue 等框架和库支持的网站，我们使网站的核心功能非常依赖于 JavaScript。

我见过很多使用 JavaScript 框架的非常重的网站。 但我对这个问题的看法有很大的偏见。 事实上，与我合作的公司之所以来找我，正是因为他们面临着复杂的网站性能问题。 因此，我很好奇这个问题有多普遍，以及当我们选择一个或另一个框架作为某个网站的基础时我们要支付多少“罚款”。

这个项目帮助我解决了这个问题。 HTTP档案.

数据

HTTP Archive 项目总共跟踪了 4308655 个指向常规桌面站点的链接和 5484239 个指向移动站点的链接。 与这些链接相关的众多指标之一是在相应站点上找到的技术列表。 这意味着我们可以对使用不同框架和库的数千个站点进行采样，并了解它们向客户端发送了多少代码以及这些代码给用户系统带来了多少负载。

我收集了 2020 年 XNUMX 月的数据，这是我能访问到的最新数据。

我决定将所有站点的聚合 HTTP Archive 数据与使用 React、Vue 和 Angular 的站点数据进行比较，尽管我也考虑使用其他源材料。

为了使它更有趣，我还在源数据集中添加了使用 jQuery 的站点。 这个图书馆仍然很受欢迎。 它还介绍了一种与 React、Vue 和 Angular 提供的单页应用程序 (SPA) 模型不同的网站开发方法。

HTTP 档案中的链接代表已被发现使用我们感兴趣的技术的网站

框架或库
移动网站链接
常规网站的链接

jQuery的
4615474
3714643

应对
489827
241023

Vue公司
85649
43691

角度方向
19423
18088

希望和梦想

在我们继续分析数据之前，我想谈谈我的希望。

我相信在理想的世界中，框架将超越满足开发人员的需求，并为我们网站的日常用户提供一些具体的好处。 生产力只是这些好处之一。 这里还考虑到了可达性和安全性。 但这只是最重要的事情。

因此，在理想的情况下，某种框架应该可以更轻松地创建高性能网站。 应该这样做，要么是因为框架为开发人员提供了构建项目的良好基础，要么是因为它对开发施加了限制，提出了一些要求，使得开发某些东西变得困难事实证明这很慢。

最好的框架应该做到这两点：提供良好的基础，并对工作施加限制，使您能够取得不错的结果。

分析数据的中值不会给我们提供我们需要的信息。 事实上，这种方法超出了我们的注意力 很多重要的事情。 相反，我从我拥有的数据中得出了百分位数分数。 这些是 10、25、50（中位数）、75、90 个百分位数。

我对第 10 个和第 90 个百分位数特别感兴趣。 第 10 个百分位代表特定框架的最佳性能（或至少或多或少接近最佳）。 换句话说，这意味着使用特定框架的网站中只有 10% 达到此级别或更高级别。 另一方面，第 90 个百分位数是硬币的另一面 - 它向我们展示了事情有多糟糕。 第 90 个百分位数是尾随站点 - 那些拥有最多 JS 代码或在主线程上处理代码所需时间最长的最后 10% 的站点。

JavaScript 代码量

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

传输到移动设备的 JavaScript 代码量 (KB)

百分位数
10
25
50
75
90

所有网站
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 

角度网站
445.1 
675.6 
1066.4 
1761.5 
2893.2 

反应网站
345.8 
441.6 
690.3 
1238.5 
1893.6 

发送到移动设备的 JavaScript 代码量

传输到桌面设备的 JavaScript 代码量 (KB)

百分位数
10
25
50
75
90

所有网站
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 

角度网站
468.8 
716.9 
1144.2 
1930.0 
3283.1 

反应网站
308.6 
469.0 
841.9 
1472.2 
2197.8 

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

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

这些数据的有趣之处在于，某些框架和库可能被认为是比其他框架和库更好的项目起点。 使用 jQuery 的网站看起来最好。 他们的桌面网站包含的 JavaScript 比所有网站多 15%，而他们的移动网站包含的 JavaScript 多 18%。 （诚​​然，这里的数据存在一些偏差。事实是 jQuery 存在于许多网站上，因此这些网站自然比其他网站与网站总数的相关性更密切。但这并不影响如何源数据是每个框架的输出。）

虽然 15-18% 的代码增长是一个显着的数字，但与其他框架和库相比，jQuery 征收的税非常低。 第 10 个百分点的 Angular 网站向桌面设备发送的数据比所有网站多 344%，向移动设备发送的数据多 377%。 React 站点位居第二，向桌面设备发送的代码比所有站点多 193%，向移动设备发送的代码多 270%。

我前面提到，虽然使用框架意味着项目一开始就会包含一定量的代码，但我希望框架能够以某种方式限制开发人员。 特别是，我们正在讨论限制最大代码量。

有趣的是 jQuery 网站遵循了这个想法。 虽然它们在第 10 个百分位数水平上比所有网站稍重（15-18%），但在第 90 个百分位数水平上，它们比所有网站稍轻 - 在桌面和移动版本中均轻约 3%。 这并不是说这是一个非常显着的好处，但可以说，jQuery 站点至少没有巨大的 JavaScript 代码量，即使在其最大的版本中也是如此。

但对于其他框架却不能这么说。

就像第 10 个百分点的情况一样，Angular 和 React 上第 90 个百分点的网站与其他网站有所不同，但不幸的是，它们的差异更糟。

在第 90 个百分位数处，Angular 网站向移动设备发送的数据比所有网站多 141%，向桌面设备发送的数据多 159%。 React 网站向桌面设备发送的数据比所有网站多 73%，向移动设备发送的数据多 58%。 第 90 个百分点的 React 站点的代码大小为 2197.8 KB。 这意味着这些网站向移动设备发送的数据比最接近的基于 Vue 的竞争对手多了 322.9 KB。 基于 Angular 和 React 的桌面网站与其他网站的差距更大。 例如，React 桌面站点向设备发送的 JS 代码比类似的 Vue 站点多了 554.7 KB。

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

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

JavaScript 代码到达浏览器后，需要将其置于工作状态。 特别是许多问题是由那些必须在主浏览器线程中使用代码执行的操作引起的。 主线程负责处理用户操作、计算样式以及构建和显示页面布局。 如果你用 JavaScript 任务压垮主线程，它将没有机会及时完成其他任务。 这会导致页面操作的延迟和“刹车”。

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

与移动设备上的脚本处理相关的 CPU 时间（以毫秒为单位）

百分位数
10
25
50
75
90

所有网站
356.4
959.7
2372.1
5367.3
10485.8

jQuery 站点
575.3
1147.4
2555.9
5511.0
10349.4

Vue 网站
1130.0
2087.9
4100.4
7676.1
12849.4

角度网站
1471.3
2380.1
4118.6
7450.8
13296.4

反应网站
2700.1
5090.3
9287.6
14509.6
20813.3

与移动设备上的脚本处理相关的 CPU 时间

与桌面设备上的脚本处理相关的 CPU 时间（以毫秒为单位）

百分位数
10
25
50
75
90

所有网站
146.0
351.8
831.0
1739.8
3236.8

jQuery 站点
199.6
399.2
877.5
1779.9
3215.5

Vue 网站
350.4
650.8
1280.7
2388.5
4010.8

角度网站
482.2
777.9
1365.5
2400.6
4171.8

反应网站
508.0
1045.6
2121.1
4235.1
7444.3

与桌面设备上的脚本处理相关的 CPU 时间

在这里你可以看到一些非常熟悉的东西。

对于初学者来说，使用 jQuery 的网站在主线程上处理 JavaScript 的花费比其他网站要少得多。 在第 10 个百分点上，与所有网站相比，移动设备上的 jQuery 网站在主线程上处理 JS 代码的时间要多出 61%。 对于桌面 jQuery 站点，处理时间增加了 37%。 在第 90 个百分位数处，jQuery 站点的分数非常接近总分。 具体来说，移动设备上的 jQuery 站点在主线程中花费的时间比所有站点少 1.3%，在桌面设备上，它们在主线程中花费的时间少 0.7%。

我们评级的另一面是主线程负载最大的框架。 这又是 Angular 和 React。 它们之间的唯一区别是，尽管 Angular 站点向浏览器发送的代码量比 React 站点多，但处理 Angular 站点代码所需的 CPU 时间却更少。 远不及。

在第 10 个百分位数处，Angular 桌面站点处理 JS 代码的主线程时间比所有站点多 230%。 对于移动网站，这个数字是 313%。 React 站点的性能最差。 在桌面设备上，他们处理代码的时间比所有网站多 248%，在移动设备上，他们处理代码的时间多 658%。 658% 不是拼写错误。 在第 10 个百分位数处，React 站点花费 2.7 秒的主线程时间来处理现有代码。

与这些巨大的数字相比，第 90 个百分位数的数字至少看起来好一点。 与所有站点相比，Angular 项目在桌面设备上主线程上花费的时间多出 29%，在移动设备上花费的时间多出 27%。 对于 React 站点，类似的指标分别为 130% 和 98%。

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

这里有一个潜在的并发症（谢谢 耶利米 为了引起我对这个功能的注意，并从这个角度仔细检查数据）。 事实上，许多网站都使用多种前端工具。 特别是，我看到很多网站将 jQuery 与 React 或 Vue 一起使用，因为这些网站从 jQuery 迁移到其他框架或库。 结果，我回到数据库，这次只选择那些与仅使用 React、jQuery、Angular 或 Vue 的网站相对应的链接，而不是它们的任何组合。 这就是我得到的。

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

百分位数
10
25
50
75
90

仅使用 jQuery 的网站
542.9
1062.2
2297.4
4769.7
8718.2

仅使用 Vue 的网站
944.0
1716.3
3194.7
5959.6
9843.8

仅使用 Angular 的网站
1328.9
2151.9
3695.3
6629.3
11607.7

仅使用 React 的网站
2443.2
4620.5
10061.4
17074.3
24956.3

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

首先，这并不奇怪：当一个站点仅使用一个框架或一个库时，此类站点的性能通常会提高。 每个仪器的性能在第 10 个和第 25 个百分位处看起来更好。 这说得通。 使用一个框架创建的网站应该比使用两个或多个框架或库创建的网站更快。

事实上，我们检查的每个前端工具的分数在所有情况下看起来都更好，但有一个奇怪的例外。 令我惊讶的是，在第 50 个百分位及以上，当使用 React 的网站仅使用 React 时，其表现会更差。 顺便说一下，这就是我在这里展示这些数据的原因。

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

如果一个项目同时使用 React 和 jQuery，那么该项目很可能处于从 jQuery 迁移到 React 的过程中。 也许他有一个混合了这些库的代码库。 由于我们已经看到 jQuery 站点在主线程上花费的时间比 React 站点少，这可能告诉我们，在 jQuery 中实现某些功能有助于稍微提高站点性能。

但随着项目从 jQuery 转向 React 并越来越依赖 React，情况发生了变化。 如果网站是真正高质量的，并且网站开发人员仔细使用 React，那么这样的网站一切都会好起来的。 但对于一般的 React 站点来说，大量使用 React 意味着主线程的负载会增加。

移动设备和桌面设备之间的差距

我查看数据的另一种方式是探索移动和桌面体验之间的差距有多大。 如果我们谈论比较 JavaScript 代码量，那么这样的比较并不会揭示出任何可怕的东西。 当然，如果可下载代码的数量减少就好了，但移动和桌面代码的数量并没有太大差异。

但如果您分析处理代码所需的时间，移动设备和桌面设备之间的巨大差距就会变得显而易见。

与桌面设备相比，移动设备上与脚本处理相关的时间增加（百分比）

百分位数
10
25
50
75
90

所有网站
144.1
172.8
185.5
208.5
224.0

jQuery 站点
188.2
187.4
191.3
209.6
221.9

Vue 网站
222.5
220.8
220.2
221.4
220.4

角度网站
205.1
206.0
201.6
210.4
218.7

反应网站
431.5
386.8
337.9
242.6
179.6

虽然手机和笔记本电脑之间的代码处理速度存在一些差异是可以预料的，但如此大的数字告诉我，现代框架没有足够针对低功耗设备，也没有缩小已确定的差距的愿望。 即使在第 10 个百分位数，React 站点在移动主线程上花费的时间也比在桌面主线程上花费的时间多 431.5%。 jQuery 的差距最小，但即使在这里，相应的数字也是 188.2%。 当网站开发人员以需要更多 CPU 时间来处理项目的方式制作项目时（这就是发生的情况，而且随着时间的推移，情况只会变得更糟），低功耗设备的所有者必须为此付出代价。

结果

好的框架应该为开发人员构建 Web 项目提供良好的基础（在安全性、可访问性、性能方面），或者应该具有内置的限制，使得创建违反这些限制的东西变得困难。

这似乎不适用于网络项目的性能（显然也不适用于他们的 可用性).

值得注意的是，仅仅因为 React 或 Angular 站点比其他站点花费更多的 CPU 时间来准备代码，并不一定意味着 React 站点在运行时比 Vue 站点更消耗 CPU 资源。 事实上，我们查看的数据很少说明框架和库的运行性能。 他们更多地讨论这些框架有意或无意地推动程序员采用的开发方法。 我们讨论的是框架的文档、其生态系统和常见的开发技术。

还值得一提的是我们在这里没有分析的事情，即在网站页面之间转换时设备花费多少时间执行 JavaScript 代码。 支持 SPA 的论点是，一旦单页应用程序加载到浏览器中，理论上用户将能够更快地访问网站的页面。 我自己的经验告诉我，这远非事实。 但我们没有数据来澄清这个问题。

显而易见的是，如果您使用框架或库来创建网站，那么您就在最初加载项目并准备好运行方面做出了妥协。 这甚至适用于最积极的情况。

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

但我们也有理由乐观。 我对 Chrome 开发人员与我们所介绍的一些前端工具背后的人员的密切合作感到鼓舞，以帮助提高这些工具的性能。

然而，我是一个务实的人。 新架构在解决性能问题的同时也经常产生性能问题。 而消除缺点也需要时间。 正如我们不应该期望那样 新的网络技术 将解决所有性能问题，您不应该期望我们最喜欢的框架的新版本能够解决这一点。

如果您想使用本材料中讨论的前端工具之一，这意味着您必须付出额外的努力来确保不会损害项目的性能。 在开始使用新框架之前需要考虑以下一些注意事项：

• 用常识检查一下自己。 您真的需要使用您选择的框架吗？ 如今，纯 JavaScript 可以做很多事情。
• 是否有比您选择的框架（例如 Preact、Svelte 或其他框架）更轻的替代方案，可以为您提供该框架 90% 的功能？
• 如果您已经在使用框架，请考虑是否有一些东西可以提供更好、更保守的标准选项（例如，Nuxt.js 代替 Vue、Next.js 代替 React 等）。
• 你会怎样 预算 JavaScript 性能？
• 你怎么 限制 开发过程中是否会导致在项目中引入超出绝对必要的 JavaScript 代码变得更加困难？
• 如果您使用易于开发的框架，请考虑 你需要 将框架代码发送给客户。 也许您可以解决服务器上的所有问题？

通常，无论您究竟选择什么来开发前端，这些想法都值得仔细研究。 但当您从事的项目本来就缺乏性能时，它们尤其重要。

亲爱的读者！ 您认为理想的 JavaScript 框架是什么？

来源： habr.com