有一天，收到了一个项目。执行npm run build打包测试了一下，总耗时上，首次打包45028ms，二次打包32344ms。内心是崩溃的。想着每执行一次打包，都得多浪费一点shengming，于是只好优化一下。
一、webpack-bundle-analyzer并不很耗时
看了下webpack配置文件，其中使用了webpack-bundle-analyzer这个插件，它不仅会分析打包文件的模块构成占比，而且会启动一个浏览器页面（如下图），怀疑它可能是比较耗时的，于是将其注释掉。
然后，再次执行打包。得到首次打包耗时46627ms，二次打包耗时31127ms。看来，并没有什么用。
二、移除speed-measure-webpack-plugin初见成效
又看到打包流程中有个speed-measure-webpack-plugin，这个需要持续不断地往控制台更新进度，于是把它注释掉。再次执行打包，得到首次打包耗时37290ms，二次打包耗时23843ms。OK，降下去大几秒，初见成效。
三、hard-source-webpack-plugin与cache-loader搭配使用有奇效
再采用hard-source-webpack-plugin来试一下，于是在webpack.prod.config.js上的plugins中添加了：
new HardSourceWebpackPlugin(),
这时，首次打包46186ms，二次打包36192ms。看着没什么效果。二次打包的时候，还老是时不时的报个错：
hashing(node:142152) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The "data" argument must be one of type string, TypedArray, or DataView.
于是想到给所有的资源加个ts\tsx\sass\scss\less\css资源加个cache-loader。加完之后，首次打包22678ms，二次打包8812ms。有奇效！而且，上面hard-source-webpack-plugin带来的那个报错也消失了。
看来，hard-source-webpack-plugin与cache-loader之间应该存在某种联系，于是，决定把hard-source-webpack-plugin移除。移除hard-source-webpack-plugin之后，发现首次打包时间退回到了31266ms，二次打包是18025ms。看来，这个hard-source-webpack-plugin不是没用，而是要跟cache-loader一起用。
因为项目的目录下有个server目录，里面有很多文件，实际上是不需要构建的，所以我们尝试缩小模块搜索的范围。于是在resolve配置项下添加：
modules: ['node_modules', path.resolve(__dirname, 'src')],
首次打包变成24807ms，二次打包变成8999ms。并没什么用。
看来，实际情况和想象还是很可能不一样，实践出真知。
四、TerserPlugin的comment相关配置对打包后文件大小有显著影响
添加如下配置之后：
new TerserPlugin({
parallel: true,
terserOptions: {
format: {
comments: false,
},
},
extractComments: false,
}),
打包后资源大小从26,334,098 字节之后变成10,853,505 字节，变化非常明显。
