记录一次关于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博客