「 不懂就问 」为何 webpack 这么慢 ？

背景

上一篇文章咱们分析了：为何 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 团队仍是作出了不少努力的， ❤️ 。

总结

这篇文章， 是半夜忽然有了思路， 花了两个小时写出来。

但愿对你们有所启发， 谢谢。