背??景在上一篇文章中，我们分析了：为什么esbuild这么快，还有数据对比：可以明显看出esbuild以绝对优势领先。看最下面，就是我们最熟悉的webpack了。那么，为什么webpack的构建速度慢呢？慢在哪里？以下是我的一些想法，分享给大家，希望对大家有所帮助。正文首先我们来看一下webpack构建的大致流程：webpack构建流程比较长。那么，整个流程的性能瓶颈在哪里呢？我觉得主要有以下两个阶段：1.代码构建在代码构建阶段，要做的一件很重要的事情就是分析模块依赖关系，生成ModuleGraph。这部分有一个非常复杂的过程。webpackbuildgraphhttps://medium.com/webpack/the-chunk-graph-algorithm-week-26-29-7c88aa5e4b4e这部分非常复杂和耗时。为此，webpack也设计了相应的算法来优化这部分。如果你有兴趣，可以研究一下。这部分的详细分析，有一个视频不错。有兴趣的可以看看：https://youtu.be/Lzh8A0p3z8g说说搭建。现代浏览器对esm的支持越来越好，浏览器可以完成模块依赖分析的工作。而且很多浏览器的包分析工具都是用C/C++写的，这明显比webpack用js分析整个依赖图更有优势，速度也快很多。2.代码压缩最成熟的js压缩工具是UglifyJS。它会分析js的代码语法树，理解代码的含义，从而进行优化比如：去除无效代码，去除日志输出代码，缩短变量名等。webpack使用minificationplugins来做这部分工作。其中：webpack使用的terser是js写的，起源于最早的uglyfy.js。功能丰富，但是速度非常非常慢。这也是webpack慢的原因之一。不过在代码压缩方面，vite也选择了Terser。这在文档中有描述：build.minify:Type:boolean|'简洁'|'esbuild'默认值：'terser'设置为false以禁用缩小或指定要使用的混淆器。默认为Terser。虽然Terser相对较慢，但在大多数情况下构建的文件大小更小。ESbuild最小化混淆速度更快，但构建的文件相对较大。更多信息请参考：https://cn.vitejs.dev/config/#build-minify另外，如果你留心的话，你会发现一个现象：Esbuild，用GO写的。SWC，是用Rust编写的。它们都不是用js写的。未来前端编译工具很可能会往这个方向发展，要么用Go写，要么用Rust写，而不是用js去实现这种会形成性能瓶颈的东西。还有一点需要说明。在文章开头的图片中，看起来webpack5比webpack4慢：但这并不意味着webpack5不好，不要误会我的意思。webpack5做了很多优化，甩掉了很多历史包袱。有一些新的特性，也很有用，比如：ModuleFederationRealContentHash不难想象webpack团队下了很多功夫，??。总结这篇文章，是半夜突然灵机一动，花了两个小时写的。本文转载自微信公众号“前端皮小丹”，可通过以下二维码关注。转载本文请联系前端皮小丹公众号。
