背景

上一篇文章咱们剖析了：为什么 esbuild 这么快。

还有数据比照：

能够看到：esbuild 一骑绝尘, 以绝对优势当先。

然而看看最上面, 赫然是咱们最相熟的 webpack。

那么, webpack 的构建为什么慢呢？到底慢在哪呢？

上面是我的一些思考，分享给大家，心愿对大家有所帮忙。

注释

首先咱们先看一下 webpack 构建的大抵流程:

流程走的比拟长。

那么，整个流程的 性能瓶颈 在哪里呢？

我认为次要是在以下两个阶段：

1. 代码构建
2. 代码压缩

咱们别离来看。

1. 代码构建

代码构建阶段，须要做的一个很重要的事件是 模块依赖剖析, 生成Module Graph。

这部分有十分复杂的流程。

这部分非常复杂，也比拟耗时。

为此 webpack 也设计了对应的的 算法 去优化这部分，感兴趣的能够去钻研一下。

这部分的具体解析，有个视频讲的不错，感兴趣的能够去看一下：

说回构建。

古代浏览器对 esm 反对的越来越好，模块依赖剖析的工作，浏览器就能实现。

而且, 浏览器的很多包剖析工具是用 C/C++ 写的, 显然是要比 webpack 应用 js 去剖析整个 依赖图谱 更具劣势，速度上也是要快很多的。

2. 代码压缩

目前最成熟的 js 压缩工具是 UglifyJS。

它会剖析 js 的 代码语法树，了解代码含意，从而能做到诸如: 去掉有效代码，去掉日志输入代码，缩短变量名等优化。

webpack 应用 压缩插件 来实现这部分工作。

其中: webpack 应用的 terser, 是用 js 写的，源自于最早的 uglyfy.js , 性能很丰盛，然而速度十分十分慢。

这点，也是 webpack 速度慢的起因之一。

不过在代码压缩方面，vite 抉择的也是Terser。

对此，文档中有相干形容：

• build.minify:

  • 类型：boolean | ‘terser’ | ‘esbuild’
  • 默认：‘terser’

设置为 false 能够禁用最小化混同，或是用来指定应用哪种混同器。

默认为 Terser。

尽管 Terser 绝对 较慢 ，但大多数状况下构建后的 文件体积更小。

ESbuild 最小化混同 更快 , 但构建后的文件 绝对更大。

更多信息能够参考：
https://cn.vitejs.dev/config/…

另外，如果你有注意，就会发现一个景象:

1. Esbuild, 应用 GO 写的。
2. SWC，是用 Rust 写的。

都不是用 js 写的。

将来前端的编译工具，大略也会往这个方向走, 要么用 Go 写, 要么用 Rust 写，而不是把这种能造成 性能瓶颈 的货色用 js 来实现。

还有一点须要提一下。

在文章结尾的图中，看起来 webpack5 的速度比 webpack4 要慢:

但这 不代表 webpack 5 不好，大家不要误会啊。

webpack 5 外面 做了 大量的优化 ， 甩掉了不少历史包袱。

有一些 新个性 还有 十分有用 的, 比方：

• Module Federation
• Real Content Hash

不难想到，webpack 团队还是做出了很多致力的，❤️。

总结

这篇文章，是中午忽然有了思路，花了两个小时写进去。

心愿对大家有所启发，谢谢。