【javascript】构建优化记录

前言

• 最近在优化一个老项目，记录下优化过程。

基本情况

• 这个项目已经被人升级到vue-cli3，但是是多入口页面，所以打包时间相当相当长，在部署的机器上1c8g上打包一般需要8分钟-9分钟左右。

优化记录

• 首先需要smp（speed-measure-webpack-plugin）测速度，才能知道如何优化。
• 发现一些无用loader 或者plugin直接去了。
• vue.config.js和smp有点冲突，只有在单页时smp.wrap configureWebpack才能拿到loader和plugin的信息，否则就只能在webpack-chain中配置，只能拿到loader的速度。
• 由于页面过多，以前打包时都使用–max_old_space_size=10240，所以增加HardSourceWebpackPlugin时直接报内存不足。后来改成4000，第一次打包花了10分钟（我这电脑不用这玩意一般打包6分钟），第二次直接崩溃，于是改内存为6000，第一次11分钟，第二次崩溃。重新打包，第一次10分钟，第二次3分钟。感觉用处不大，反而更费时间。
• 后来研究happypack，发现现在都是thread-loader替代它，于是使用thread-loader的预热功能，发现无法正常结束。于是去除预热功能。这玩意不需要额外配置，因为vue-cli中已经配好了。
• 于是想试试改exclude，给所有loader加上exclude打包，发现直接报错，不能给css等样式加上exclude node_module，否则里面的样式取不出来。
• 于是再试试include，因为include效果好点，于是感觉好像有点用处。速度确实提升了些。
• 由于vue-cli中编译ts用了ts-loader，我觉得页面多切换多个loader比较耗时，于是就把ts-loader给去了，使用babel的ts预设进行处理，在自己电脑上感觉速度是变快了，但是在部署机子上感觉速度提升不明显，甚至变慢了，于是我专门测试了下这2行为，由于我们95%以上的文件都是js或者vuejs形式，ts文件很少，所以最后测试结论是ts-loader比使用babel-loader的ts预设要快。（不要看很多文章上说babel编ts比ts-loader快）
• 下面就是搞cdn，由于入口过多，所以vue那么一大段代码编了n次，所以感觉提cdn应该是优化最快的方法。实际操作发现提升也并不是很明显， 因为前面加了include，所以不在src的文件直接拿来，速度上提升不大。
• 然后就看见压缩的terser上耗时太多，试着给terser添加include ，确实可以提速，但是发现生成的大小过大，不能接受。由于terser是3个包联合工作，所以试着升级vue-cli-service看能不能加快速度。实际感觉效果不是特别明显。也没有很快也没有很慢。
• 感觉目前只能优化到这速度，剩下的只能靠减少入口来解决了。