JavaScript框架的成本
没有比使用一堆JavaScript更快(双关语)降低站点速度的方法了。
JavaScript的问题是，你最终要缴纳不少于四倍的绩效税：
而且我们的出货量越来越高。随着组织转向由React、Vue.js和Friends等框架驱动的站点，我们使站点的核心功能越来越依赖于JavaScript。
我看到很多网站都在使用它们，但我的观点是非常偏颇的，因为与我合作的公司与我合作恰恰是因为它们面临着性能挑战。我很好奇这种情况有多普遍，当我们把这些框架作为默认起点时，我们要付出多大的代价。
HTTP Archive总共跟踪4，308，655个桌面URL和5，484，239个移动URL。在这些URL的众多数据点HTTP Archive报告中，有一个针对给定站点检测到的技术的列表。这意味着我们可以挑选出使用各种框架的数千个站点，并查看它们运送了多少代码，以及这些代码花费了多少CPU。
我在2020年3月运行了所有的查询，这是当时运行的最近一次。
我决定将记录的所有站点的聚合HTTP Archive数据与具有REACT、Vue.js和ANGING DETECTED 1的站点进行比较。
为了好玩，我还添加了jQuery-它仍然非常流行，而且它也代表了一种使用JavaScript构建的方法，与React、Vue.js和Angel提供的单页面应用程序(SPA)方法略有不同。
在一个理想的世界里，我相信一个框架应该超越开发者的体验价值，为使用我们网站的人提供具体的价值。性能只是其中的一部分-可访问性和安全性也在脑海中浮现-但它是必不可少的一部分。
因此，在理想情况下，框架要么提供更好的起点，要么提供约束和特征，使得构建性能不佳的东西变得更加困难，从而更容易实现良好的性能。
最好的框架可以做到这两点：提供一个更好的起点，并帮助限制事情可能变得多么失控。
看看我们数据的中位数不会告诉我们这一点，而且实际上遗漏了大量信息。取而代之的是，对于每个统计数据，我提取了以下百分位数：第10、25、50(中位数)、75和90。
我对第10和第90个百分位数特别感兴趣。第10个百分位数表示给定框架的最佳水平(或者至少相当接近最佳水平)。换句话说，使用给定框架的所有站点中只有10%达到或更好。另一方面，第90个百分位数则与光谱相反-它向我们展示了事情可能会变得多么糟糕。第90个百分位数代表长尾，即最后10%的站点具有最大的字节数或最多的主线程时间。
作为起点，查看通过网络传递的JavaScript数量是有意义的。
对于纯粹的有效负载大小，第10个百分位数的结果与您预期的差不多：如果正在使用这些框架中的一个，即使在最理想的情况下，也会有更多的JavaScript。这并不令人惊讶-您不能添加一个JavaScript框架作为默认起点，然后期望出厂时交付的JavaScript会更少。
值得注意的是，一些框架比其他框架具有更好的起点。使用jQuery的网站是其中的佼佼者，首先桌面设备上的JavaScript多了约15%，移动设备上多了约18%。(无可否认，这里有一点偏见。jQuery在很多网站上都可以找到，所以很自然地，它与整体数字的关系会比其他网站更紧密。不过，这并不会改变每个框架的原始数字显示方式。)
虽然即使是15-18%的增幅也是值得注意的，但与光谱的另一端相比，jQuery的税收感觉非常低。有棱角的网站在桌面上的JavaScript发货量在第10个百分位数上增加了344%，在移动设备上的发货量增加了377%。排在第二位的Reaction网站在台式机上的JavaScript发送量增加了193%，在移动设备上的发送量增加了270%。
我刚才提到，即使起点有点偏离，我希望框架仍然可以通过以某种方式限制上限来提供价值。
有趣的是，jQuery驱动的站点遵循这种模式。虽然它们在第10个百分位数时稍高一些(15-18%)，但比第90个百分位数的总和略小-在台式机和移动设备上都约为3%。这两个数字都不是特别重要，但至少在JavaScript字节传送量方面，使用jQuery的站点似乎没有明显糟糕的长尾。
就像第10个百分位数一样，在第90个百分位数，棱角分明和反应驱动的网站往往会与其他网站保持距离，而且不是以一种非常讨人喜欢的方式。
在第90个百分位数，角站点在移动设备上的字节发送量增加了141%，在桌面上的字节发送量增加了159%。使用Reaction的网站在台式机上的字节发送量增加了73%，在移动设备上增加了58%。第90个百分位数的权重为2，197.8KB，Reaction站点向移动用户发送的JavaScript比第二接近的Vue.js多322.9KB。ANGLING和REACTION之间的桌面差距甚至更大--REACTION驱动的站点比Vue.js驱动的站点多出554.7KB的JavaScript。
从数据中可以清楚地看出，采用这些框架的站点往往会在字节数方面付出很大代价。当然，这只是方程式的一部分。
一旦JavaScript到达，它就必须开始工作。发生在浏览器主线程上的任何工作都特别麻烦。在样式计算、布局和绘制期间，主线程负责处理用户输入。如果我们用大量的JavaScript工作来阻塞它，主线程就没有机会及时完成这些工作，从而导致延迟和堵塞。
HTTP Archive记录V8主线程时间，因此我们可以查询该主线程在所有JavaScript上工作时间。
首先，与分析的其他三个站点相比，检测到jQuery的站点在主线程上花费的JavaScript工作时间要少得多。在第10个百分位数，在移动设备上完成的JavaScript主线程工作增加了61%，在桌面设备上完成的工作增加了37%。在第90个百分位数处，jQuery站点获得了非常接近总体的收益，在移动设备的主线程上花费的时间减少了1.3%，在台式机上花费的时间减少了7%。
相反的一端-与花在主线程上的时间最长相关的框架-再次由角度和反应组成。唯一的区别是，虽然角度站点比Reaction站点提供了更多的JavaScript，但它们实际上在CPU上花费的时间更少--少得多。
在第10个百分位数，角度站点在桌面设备上用于JavaScript相关工作的CPU时间比在桌面设备上多230%，在移动设备上比在移动设备上多313%。Reaction网站排在最后，在桌面设备上花费的时间增加了248%，在移动设备上花费的时间增加了658%。不，658%不是打字错误。在第10个百分位数，使用Reaction的站点在主线程上花费2.7秒来处理所有发送下来的JavaScript。
与那些大数字相比，排在第90个百分位数的情况至少看起来要好一点。角度站点的主线在桌面设备上花在JavaScript上的时间增加了29%，在移动设备上花费的时间增加了27%。Reaction网站在台式机上花费的时间增加了130%，在移动设备上花费的时间增加了98%。
这些百分比看起来比第10个百分位数要好得多，但请记住，大量的数字相当可怕：在移动设备上，使用Reaction在第90个百分位数构建的站点的主线程工作量是20.8%。(我认为，在这段时间里到底发生了什么，这是一个后续帖子的主题。)。
有一个潜在的问题(感谢Jeremy确保我从这个角度仔细检查了统计数据)-许多站点将吸引多个库。特别值得一提的是，当jQuery或Vue.js迁移到该架构时，我看到很多站点将其与Reaction或Vue.js并驾齐驱。所以，我重新运行了查询，只是这一次我只包含了只包含Reaction、jQuery、ANGLING或Vue.js的URL，而没有包含它们的某种组合。
首先，不足为奇的一点是：当只使用一个框架时，性能改进的次数要比不使用的次数多得多。每个框架的数字在第10个百分位数和第25个百分位数处看起来更好。这事儿可以理解。使用一个框架构建良好的站点应该比使用两个或更多框架构建良好的站点执行得更好。
事实上，除了一个奇怪的例外，每个框架的数字在每个百分位数上看起来都更好。令我惊讶的是，当REACT是唯一使用的框架时，使用REACTION的站点在使用REACT时表现更差，这也是我最终包括这些数据的原因，在第50个百分位数和更高的百分位数时，使用REACTION的站点表现更差。
如果您同时运行了Reaction和jQuery，那么您更有可能处于迁移过程中做出反应，或者是混合代码库。因为我们已经看到使用jQuery的站点比使用Reaction的站点在主线程上花费的时间更少，所以让一些功能仍然由jQuery驱动是有道理的，这将使数量减少一些。
但是，当您不再使用jQuery，而更多地专注于独占地反应时，这种情况就会改变。如果站点构建得非常好，并且您使用的反应很节制，那么您就没有问题。但是对于普通站点来说，Reaction内部的工作越多，主线程就会受到越来越多的压力。
另一个值得关注的角度是，移动体验和桌面体验之间的差距到底有多大。从字节的角度来看，没有什么可怕的东西会跳出来。当然，我希望看到传递的字节更少，但是移动设备和台式设备接收的字节都不会比其他设备多很多。
虽然预计手机和笔记本之间会有一些差异，但看到这么高的数字告诉我，目前的框架在优先处理功能较弱的设备和帮助缩小差距方面做得不够。即使是在第10个百分位数，Reaction网站在移动设备上花在主线程上的时间也比在桌面设备上多431.5%。jquery是所有框架中差距最小的，但即便如此，它也相当于在移动设备上多花了188.2%的时间。当我们让CPU更努力地工作时--我们越来越多地这样做--那些使用功能较弱的设备的人最终会买单。
好的框架应该在基本要素(安全性、可访问性、性能)上提供更好的起点，或者具有内置的约束，这使得发布违反这些限制的东西变得更加困难。
值得一提的是，由于使用Reaction或ANGING的站点比其他站点在CPU上花费的时间更多，这并不一定等同于说Reaction在CPU上比Vue.js更昂贵。事实上，它很少提到正在使用的核心框架的性能，而更多地介绍了这些框架可能通过文档、生态系统和一般编码实践鼓励(无论是有意还是无意)进行开发的方法。
同样值得注意的是，我们这里没有：关于设备在此JavaScript上花费多少时间以用于后续视图的数据。SPA体系结构的论据是，一旦SPA就位，理论上您可以更快地加载后续页面。我自己的经验告诉我，这远远不是一个给定的事实，但我们这里没有具体的数据来证明这两个方向都是这样的。
清楚的是：现在，如果您使用框架来构建站点，即使在最好的情况下，您也会在初始性能方面进行权衡。
在正确的情况下，一些权衡可能是可以接受的，但重要的是，我们要有意识地进行这种交换。
我们有理由感到乐观。Chrome的工作人员一直在与其中一些框架密切合作，以帮助提高它们的性能，这让我感到鼓舞。
但我也很务实。新的体系结构往往会在解决性能问题的同时带来性能问题，并且需要时间来纠正这些问题。就像我们不应该指望新的网络可以解决我们所有的性能问题一样，我们也不应该指望我们最喜欢的框架的下一个版本会解决所有的问题。
如果您要使用这些框架中的一个，那么您必须采取额外的步骤来确保在此期间不会对性能造成负面影响。以下是一些重要的入门考虑事项：
做一个理智的检查：你真的需要使用它吗？如今，普通JavaScript可以做很多事情。
有没有更轻的选择(Preact、Svelte等)。这样你就有90%的路程了？
如果您使用框架，有没有什么可以提供更好、更自以为是的默认值(例如：Nuxt.js代替Vue.js，Next.js代替Reaction，等等)？
您会在工作流中引入哪些摩擦，使得添加超过绝对必要的JavaScript变得更加困难？
如果您正在使用开发人员人体工程学的框架，您是否需要将其发送到客户端，或者是否可以在服务器上进行处理？
不管您选择哪种技术，这些通常都是值得考虑的好事情，但是如果您从一开始就有性能缺陷，那么它们就特别重要。
例如，我们可以使用所有未检测到上述任何框架(jQuery、Reaction、Vue.js、ANGING)的站点。
以下是那些URL在移动设备上的JavaScript主线程工作的数字：更进一步，我们可以使用所有根本没有检测到JavaScript框架或库的站点。以下是这些应用程序的主线程时间：
无论采用哪种基线，数据看起来都不那么有利，也更具戏剧性。最终，我使用聚合数据作为基线，因为：
它避免了关于没有框架的站点是否足够复杂以进行准确比较的争论，从而避免了谈话的脱轨。你可以在不使用框架的情况下建立大型、复杂的网站--我曾与拥有框架的公司合作过--但这一论点会分散人们对数据得出的原本相当清晰的结论的注意力。
尽管如此，正如我向他们展示数据时一些人向我指出的那样，看到这些替代基线很有趣，因为它们确实清楚地表明了这些工具在多大程度上扰乱了平均水平。
2.我怀疑人们可以从框架开始，构建性能超过Next.js或Nuxt.js的东西。然而，这里的长尾数据表明，许多网站的情况可能并非如此。他们提供的所有管道都需要时间来建造，并把它建得很好。尽管如此，在做出决定之前，值得考虑的是我们愿意引入多少层抽象。
