关于WebPack的构建优化的一次记录

记录一次关于WebPack打包优化的解决过程。

前景

在用项目是用vue2+WebPack，延续了好几代开发人员，交接到手时，一次npm run build需要20分钟左右的事件，修改编译也经常会内存溢出。非常吃电脑性能。于是，想要着手解决打包慢的问题。

{"webpack": "^3.10.0",
"vue": "^2.5.13"}

我的做法

分析工具分析性能情况

首先，使用webpack-bundle-analyzer包进行打包性能的分析。在webpack.prod.config.js中引入.

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin; //webpack打包性能分析启用
...
  plugins: [
        new BundleAnalyzerPlugin({
            analyzerMode: 'static',
            reportFilename: 'report.html',
             openAnalyzer: false,
            logLevel: 'info',
             defaultSizes: 'gzip',
             generateStatsFile: true,
             statsFilename: 'stats.json',
         })
]

然后，我们就可以运行npm run build啦。npm run build打包命令记得加上progress。

 "build": "cross-env NODE_OPTIONS=--max_old_space_size=8192 webpack --progress --hide-modules --config build/webpack.prod.config.js",

在运行之后，可以在./dist下找到除了打包生成的静态文件外，还有report.html和stats.json的性能报告。双击打开report.html，就可以看到打包文件大小占比。

大体积包按需引入

通过分析，可以看到哪些包大小比较大。例如，我发现elementui和echarts相关的面积比较大，所以我就换成按需引入。

重复引入改成一次引入

我发现我的通用组件存在重复引入的现象，而且它的体积还是比较大的，然后我改成了注册成全局组件。修改后发现大幅度提升性能！

取得的效果

一次打包只需要2分钟，而且发现在编译运行时对电脑的内存占用变低了，页面部署后的速度也变快了。

总结

比较大体积的通用组件，若使用频率较高，注册为全局组件，对webpack而言是一次引入，若每个页面单独引入，对webpack而言会是多次编译引入，会吃性能。

还有一些其他的优化方式，由于这次的优化已经能解决问题，所以我就没有再继续探索了。大家可以参考：webpack构建优化实战_webpack --profile-CSDN博客