重点解决的问题
在webpack打包的过程中有没有想过这其中的打包过程是怎么样的呢？有没有什么办法能反映出这个打包的过程和结果呢？webpack打包太慢需要优化怎么办呢？或许以下这几款插件能帮助到你，记得点个赞哈哈。
以下插件均兼容webpack4
ProgressBarPlugin
这款插件能把打包的进度以进度条的形式显示出来，同时也可以自定义显示百分比的格式样式。
资源地址
https://www.npmjs.com/package/progress-bar-webpack-plugin
安装&使用
npm i progress-bar-webpack-plugin
var ProgressBarPlugin = require('progress-bar-webpack-plugin');
// ...
plugins: [
new ProgressBarPlugin({
format: ' build [:bar] ' + chalk.green.bold(':percent') + ' (:elapsed seconds)',
clear: false
})
]
注意
这里进度百分比如果要彩色显示的话，需要多安装一个包chalk
const chalk = require('chalk');
评价
这款插件可以说是非常实用的，从此告别傻傻的等待。
SpeedMeasurePlugin
寻寻觅觅找了半天，却在灯火阑珊处，看到的第一眼就认定了，没错，就是它。这款插件能将每一个plugin每一个loader的打包时间以及总打包时长统计出来。
资源地址
https://www.npmjs.com/package/speed-measure-webpack-plugin
安装&使用
npm i speed-measure-webpack-plugin
// webpack.config.js
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();
const webpackConfig = smp.wrap({
module:{
rules:[
// ...
]
},
plugins: [
// ...
]
});
module.exports = webpackConfig;
这里配置的意思是需要直接将原来的webpack配置传入到插件提供的方法里，然后导出。
注意
这里每一个loader/plugins的打包时长相加并不等于总时长。因为在webpack中，通常loader/plugins的处理过程是异步的，除非有相互依赖的情况。只要找出耗时最长的过程，尽量去优化它，就能显著减少打包时长。
评价
可以讲是优化分析提高效率的必备工具。
BundleAnalyzerPlugin
又是一个非常nice的插件，谁用谁知道，在打包结束之后能将各个包的内容、信息、占比以图形化界面表现出来，界面中还有其他的交互和过滤器。
安装&使用
npm i webpack-bundle-analyzer
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
// ...
module.exports = {
plugins: [
new BundleAnalyzerPlugin({
analyzerMode: 'static',
openAnalyzer: true,
logLevel: 'info'
})
]
}
注意
按照默认配置的话，在打包的最后会启动一个服务，需要手动去关闭，如果后续还有其他动作的话（如集成CI）就会阻塞调，这是我们不希望的，使用推荐大家使用上面的配置。
评价
这个插件都很熟悉了，也是属于必备工具之一。
DashboardPlugin
想要耍帅的看这里，该插件拥有非常酷炫的界面，以读秒的方式记录打包进度，也能对输出包的大小进行分析，显示每个包里各个内容的占比。
资源地址
https://www.npmjs.com/package/webpack-dashboard
安装&使用
npm i webpack-dashboard
// webpack.config.js
var DashboardPlugin = require("webpack-dashboard/plugin");
// ...
plugins: [new DashboardPlugin()];
// package.json
"scripts": {
"build": "webpack-dashboard -- webpack --mode production"
}
注意
有一点很奇怪，貌似插件的兼容性有点问题，如果像官网那样去设置端口号的话，编译完成后的分析结果无法完整显示出来。这里给出的解决方案是直接使用new DashboardPlugin()，不要设置自定义端口号。
评价
界面是挺好看的，但是用多几次就会发现，其实没有想象中的实用。不能一目了然很直观的分析出问题，可以尝尝鲜，但不大建议使用。
DuplicatePackageCheckerPlugin
当webpack打包了相同的包时这款插件能给出相应的提示。例如打包了两个loadsh包，最后输出结果时就会有提示。
资源地址
https://www.npmjs.com/package/duplicate-package-checker-webpack-plugin
安装&使用
npm i duplicate-package-checker-webpack-plugin
const DuplicatePackageCheckerPlugin = require("duplicate-package-checker-webpack-plugin");
module.exports = {
plugins: [new DuplicatePackageCheckerPlugin()]
};
评价
如果webpack配置配得好的话，这款插件的用处就不大。不过也能帮助我们分析和优化潜在的问题。
总结
一般来说ProgressBarPlugin，SpeedMeasurePlugin，BundleAnalyzerPlugin这三款插件搭配使用，就能解决大部分有关webpack打包性能分析的问题了。
欢迎关注公众号
或者你感兴趣的内容
Re从零开始系列
- 《Re从零开始的组件库构建与发布流程》
- 《Re从零开始的UI库编写生活之规范制定》
- 《Re从零开始的UI库编写生活之按钮》
- 《Re从零开始的UI库编写生活之表单》
- 《Re从零开始的UI库编写生活之表格组件》
- 《Re从零开始的UI库编写生活-步骤管理组件Steps》
- 《Re从零开始的UI库编写生活-Tree组件》
- 《Re从零开始的后端学习之配置Ubuntu+Ngnix+Nodejs+Mysql环境》
- 《Re从零开始的后端学习之配置LAMP环境》
