背??景在上一篇文章中，我们分析了为什么esbuild这么快。还有一个数据对比：可以看到esbuild以绝对优势领先。但是看看最下面，是我们最熟悉的webpack。那么为什么webpack构建缓慢呢？哪里慢了？以下是我的一些心得，分享给大家，希望对大家有所帮助。正文首先我们来看一下webpack构建的大致流程：流程比较长。那么，整个流程的性能瓶颈在哪里呢？我觉得主要是以下两个阶段：代码构造代码压缩我们分别来看。1.代码构建在代码构建阶段，要做的一件很重要的事情就是分析模块依赖关系，生成ModuleGraph。这部分有一个非常复杂的过程。这部分非常复杂且耗时。为此，webpack也设计了相应的算法来优化这部分。如果你有兴趣，可以研究一下。这部分的详细分析，有一个视频不错。有兴趣的可以看看：聊聊建筑。现代浏览器对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/...另外，如果你留心的话，你会发现一个现象：Esbuild，用GO写的。SWC，是用Rust编写的。它们都不是用js写的。未来前端编译工具很可能会往这个方向发展，要么用Go写，要么用Rust写，而不是用js去实现这种会形成性能瓶颈的东西。还有一点需要说明。在文章开头的图片中，看起来webpack5比webpack4慢：但这并不意味着webpack5不好，不要误会我的意思。webpack5做了很多优化，甩掉了很多历史包袱。有一些新特性非常好用，比如：ModuleFederationRealContentHash不难想象webpack团队付出了很多努力，??。总结这篇文章，是半夜突然灵机一动，花了两个小时写的。希望对你有所启发，谢谢。
