【前端】探索webpack3项目build速度优化， 优化个p

背景

webpack3 + babel7 + uglifyjs-webpack-plugin的项目，build起来是什么体验。 大抵是写了两个月后，发现build时间从120s激增到400s。而这400秒中，有50多秒是UglifyJsPlugin贡献的。（更耗时的其实是babel-loader，但是咱拿他没办法）

uglifyjs-webpack-plugin

这玩意儿是什么呢，其实就是对js进行压缩和混淆的插件（包含去除未使用用变量， 去除console， 去除debugger等），使用nodejs编写，常用于webpack3中。而在webpack4-5中，已经弃用了，替代品叫做terser-webpack-plugin， 可能快一丢丢。

然后，目前追求更进一步的性能提升，那就是用编译性语言替代nodejs来对js压缩混淆。

常见的有

• go语言esbuild： 用于webpack5中的esbuild-webpack-plugin以及vite。
• rust语言swc： 忘了，似乎用于 umi@4
• rust语言rsbuild: 字节整的，用于平滑替换webpack5生态。好像兼容了90%的插件，目前似乎0.7.8版本。
  这几个的问题在于，最低只能编译到es2015，也就是不支持ie全系列。无法避免ie的话，还是老老实实babel-loader吧
  

webpack3 压缩混淆js 优化踩坑。

• webpack-parallel-uglify-plugin@1： 毫无用处，负优化。
• happypack: 毫无用处，负优化。
• 别的似乎没什么优化方案了。

结论

别优化了，又不是不能用。

• 从webpack3提取pubic和src，丢到webpack5 +rsbuild打包
• 从360s -> 20s… emm不得不说真是绝活。
  

再看看webpack3的，真是我测。