文章目录
- 背景
- uglifyjs-webpack-plugin
- webpack3 压缩混淆js 优化踩坑。
- 结论
背景
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的,真是我测。