当项目越来越复杂时,会面临着构建速度慢和构建出来的文件体积大的问题。webapck构建优化对于大项目是必须要考虑的一件事,下面我们就从速度和体积两方面来探讨构建优化的策略。
分析工具
在优化之前,我们需要了解一些量化分析的工具,使用它们来帮助我们分析需要优化的点。
webpackbar
webpackbar可以在打包时实时显示打包进度。配置也很简单,在plugins数组中加入即可:
const WebpackBar = require('webpackbar')
module.exports = {
plugins: [ ... new WebpackBar() ]
}
speed-measure-webpack-plugin
使用speed-measure-webpack-plugin
可以看到每个loader和plugin的耗时情况。
和普通插件的使用略有不同,需要用它的wrap方法包裹整个webpack配置项。
const SpeedMeasurePlugin = require('speed-measure-webpack-plugin')
const smp = new SpeedMeasurePlugin()
module.exports = smp.wrap({
entry: './src/main.js',
...
})
打包后,在命令行的输出信息如下,我们可以看出哪些loader和plugin耗时比较久,然后对其进行优化。
webpack-bundle-analyzer
webpack-bundle-analyzer
以可视化的方式让我们直观地看到打包的bundle中到底包含哪些模块内容,以及每一个模块的体积大小。我们可以根据这些信息去分析项目结构,调整打包配置,进行优化。
在plugins数组中加入该插件。构建完成后,默认会在http://127.0.0.1:8888/
展示分析结果。##### 参考webpack视频讲解:进入学习
const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin
module.exports = {
plugins: [ ... new BundleAnalyzerPlugin() ]
}
webpack-bundle-analyzer
会计算出模块文件在三种情形下的大小:
- stat:文件未经过任何转换的原始大小
- parsed:文件经过转换后的输出大小(比如babel-loader转换ES6->ES5、UglifyJsPlugin压缩等等)
- gzip:parsed后的文件,经过Gzip压缩的大小
使用speed-measure-webpack-plugin
和webpack-bundle-analyzer
本身也会增加打包时间(webpack-bundle-analyzer
特别耗时),所以建议这两个插件在开发分析时使用,而在生产环境去掉。
优化构建速度
多进程构建
运行在Node.js之上的 Webpack 是单线程的,就算有多个任务同时存在,它们也只能一个一个排队执行。当项目比较复杂时,构建就会比较慢。如今大多数CPU都是多核的,我们可以借助一些工具,充分释放 CPU 在多核并发方面的优势。
比较常见的有happypack
、thread-loader
。
happypack
happypack能够将构建任务分解给多个子进程去并发执行,子进程处理完后再把结果发送给主进程。使用配置如下,就是把原有的loader的配置转移到happyPack中去处理。
const Happypack = require('happypack')
module.exports = {
module:{
rules:[
{
test: /\.js$/,
use: 'happypack/loader?id=babel' //问号后面的查询参数指定了处理这类文件的HappyPack实例的名字
},
]
},
plugins:[
new Happypack({
id: 'babel', //HappyPack实例名,对应上面rules中的“id=babel”
use: