原文标题：The Cost of Javascript Frameworks
原文地址：https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/
本文采用意译而非直译，有删减
网页中大量使用JavaScript会拖慢网页的速度。这是因为，我们在网页中使用JavaScript时，需要付出以下的成本：
- 从网络上下载js文件的开销。
- 下载后解析和编译未压缩文件的开销。
- 执行js代码的开销。
- 内存开销。
这些开销结合起来，就十分昂贵了。可以参考这篇文章：https://v8.dev/blog/cost-of-javascript-2019
如今，我们越来越多的网页都依赖与React.js、Vue.js 等JavaScript框架。在使用这些框架时，我们付出了多少代价呢？
我们可以从HTTP Archive（https://httparchive.org/）中找到答案。
数据
HTTP Archive 一共追踪了4,308,655 个桌面端Url，5,484,239个移动端Url。我们可以检测出这些站点都使用了什么框架。我还加上了jQuery，因为它现在依然十分流行，并且也代表了一种和React，Vue等框架不同的开发方式。下面是检测结果：
一些希望
在理想环境下，框架应该超越开发人员的经验价值，为网站用户提供具体的价值。性能只是可访问性和安全性的一部分，但也是不可缺少的一部分。框架应该提供一个更好的启动点或者提供规则、特性，帮助我们在开发时不会失控。
对于每个统计数据，我都抽取了分位值：10分位值，25分位值，50分位值（中位数），75分位值，90分位值。
10分位值和90分位值对于我来说十分有趣。10分位值表示给定框架的最佳实践（或至少相当接近最佳实践）。换句话说，使用给定框架的所有站点中，只有10%达到或超过这个标准。另一方面，90分位值恰恰相反。它向我们展示了事情会变得多么糟糕。90分位值表示了一些长尾情形 。最后10%站点的JavsScript文件过大或者主线程的执行时间过长。
JavaScript 文件大小
站点通过网络下载的JavaScript文件的大小，对于站点能尽快run起来是十分重要的。下载得文件越小，则网站的启动点更早；文件越大，网站的启动点更晚。所以，我们首先来看一下使用不同框架的站点中，js文件大小分布。
10分位值的数据应该和你预计的差不多。引用一个框架，必然会增加JavaScript文件的大小，这是很正常的。
值得注意的是，有些框架比其他框架有更好的网站启动点。使用jQuery的站点是最好的，首先是桌面设备上的JavaScript增加了约15%，移动设备上的JavaScript增加了约18%。（无可否认，这里有一点偏见。很多网站上都使用了jQuery，所以它跟整体数据的关联比较大。不过，这并不会改变每个框架的原始数据显示方式。）
使用框架或多或少都会影响网站的启动点。但是jQuery对于启动点的影响是十分小的。尽管在10分位值上，jQuery有点拖慢了网站的启动点，但是在90分位值上，jQuery表现得不错。
但是其他框架就不是这样了。使用Angular，对网站js文件的大小影响最大，React次之。Vue的表现仅次于jQuery。
JavaScript主线程耗时
上面的数据已经证明了，使用框架会增加网站的JavaScript大小。但是那只是一部分。
一旦JavaScript下载完成，它就必须开始工作了。在浏览器的主线程上进行的任何工作都特别麻烦。主线程负责在样式计算、布局和绘制期间处理用户输入。如果我们用了大量的JavaScript工作来阻塞它，那么主线程就没有机会及时地完成这些工作，这会导致网站卡顿。
HTTP Archive 记录了V8的主线程时间。我们可以看一下在各种框架下，V8主线程的执行时间。
使用jQuery的站点在主线程JavaScript执行时间上最短。在10分位值上，移动设备上的JavaScript主线程工作增加了61%，桌面上增加了37%。在90分位值上，jQuery站点获得了非常接近于总数的增长，在移动端的主线程上花费的时间减少了1.3%，在桌面端上花费的时间减少了7%。
在主线程上花费时间最多的仍然是React和Angular。虽然Angular会使JavaScript体积变得更大，但是在主线程V8上花费的时间却比React少。
在10分位值上，Angular站点在桌面设备上的JavaScript相关工作的CPU时间增加了230%，在移动设备上的CPU时间增加了313%。React站点的表现最差，在桌面设备上花费的时间增加了248%，在移动设备上花费的时间增加了658%。在10分位值上，使用React的站点要在主线程上花费2.7s来执行下载下来的js代码。
在90分位值上，各大框架的表现看起来还凑合，比整体数据多不了多少，除了React。移动端20.8s的主线程耗时是十分恐怖的。这段时间到底发生了什么呢？
有一个潜在的问题 —— 许多网站会同时使用多个框架。比如不少公司会同时使用 Vue、jQuery 或者 React、jQuery。所以，我重新查询了数据，这次只包含React、jQuery、Angular或Vue.js，而不是他们的组合。
移动端和桌面端的差别
另一个值得关注的角度是移动体验和桌面体验之间的差距有多大。从js文件大小的角度来看，没有太大的差别。但是从主线程js运行时长，就能看出巨大的差别了。下面的数据是移动端主线程运行时长比桌面端多出的百分比。
虽然手机和笔记本电脑之间可能会有一些差异，但看到这么高的数字告诉我，目前的框架还不足以优先考虑功能较弱的设备，并帮助缩小这一差距。即使在10分为数值，React站点在移动设备上的主线程上花费的时间也比在桌面设备上花费的时间多431.5%。jQuery是所有框架中差距最小的，但即便如此，它在移动设备上的主线程耗时也增加了188.2%。
总结
一个好的框架应该为基本要素（安全性、可访问性、性能）提供一个更好的起点，或者有内置的约束，使违反这些约束的东西更难发布。
但是在性能表现上，似乎没有框架做到了。
值得注意的是，由于使用Angular或React的站点在CPU耗时上更多，但是并不是说使用React或者Angular就需要比使用Vue.js花费更多的代价。事实上，我们不太经常提到核心框架的性能。我们更注重的，是框架本身所提供的编码方式、生态系统及开发方法等。
值得注意的是，我们这里没有什么：关于使用某种框架的站点的首屏时间。单页应用架构的论点是，一旦SPA就位，理论上可以获得更快的后续页面加载。我自己的经验告诉我，这远远不是一个给定的值，但我们这里没有具体的数据来证明这一点。
很明显的一点是：现在，如果你使用框架来构建你的站点，即使在最好的情况下，你也要在初始化性能方面做出权衡。
在适当的情况下，一些折衷可能是可以接受的，但我们必须有意识地进行这种交换。
新的体系结构往往会像解决问题一样经常产生性能问题，而且需要时间来纠正问题。正如我们不应该期望新的网络能解决我们所有的性能问题一样，我们也不应该期望我们最喜欢的框架的下一个版本也能解决它们。
如果你要使用这些框架中的一个，那么你必须采取额外的步骤来确保对性能不会产生太大的影响。以下是一些重要的点：
- 你真的需要框架嘛？如今普通的JavaScript已经可以做到许多事情了。
- 有没有更轻量级的替代品（Preact、Svelte等）可以解决你90%的问题？
- 如果你准备使用一个框架时，是否有更好的封装（Nuxt.js 而不是 Vue.js, Next.js 而不是 React）？
- 你对JavaScript的性能有什么预期？
- 你可以在工作流中加入哪些要素，使得代码更加的规范？
- 如果为了工程效率而使用框架，你是需要将框架下载到客户端还是直接在服务端就进行处理呢？
无论你选择何种技术，这些通常都是值得好好考虑的事情。但如果项目从一开始就存在性能缺陷，那么上述几个注意事项就特别重要。
写在后面
本文分析了各个工具（jQuery、React、Vue、Angular）对站点的影响，主要从js文件大小和js运行耗时两个方面入手，进行了数据对比。文章给出的各个框架的具体数据表现，挺有意思的。可以看到，使用这些工具对网页性能都会造成一定的影响。但之所以使用框架，是为了按照一定的规则约束，更快更好地写出易读、易于维护、易于扩展的代码，在性能上是需要有所权衡的。每一种框架下，也有不少办法可以将性能做到极致。结合场景选择最合适的框架就好了。
