请注意:本文主要是针对 webpack4 的 js 构建速度做优化。
用一句话总结本文,就是给 js 构建流程加 cache,让任务并行。
babel-loader
首先第一个主角 babel-loader,给babel-loader 加一个参数即可cacheDirectory: true。相关的配置还有 cacheIdentifier 和 cacheCompression,cacheIdentifier 是给 cache 配一个标识,cacheCompression 是babel-loader 默认会以 gzip 去压缩,如果你的文件量非常大可以尝试设为 false。
thread-loader
什么,光有 cahche 还是不够快吗,谁让你一次要改那么多文件。cache 只能在第一次构建之后起作用,而且第一次构建本身也依旧是耗时的事情。那么我们请出第二个主角 thread-loader,这货看名字就知道是干嘛的吧。简单说就是让你的多核 cpu 按一定配置来参与到打包流程中。加进来之后 js rule 的配置就变成以下
rules: [
{
test: /\.js$/,
include: /(src)/,
use: [
{
loader: 'thread-loader',
options: {
workers: os.cpus().length
}
},
{
loader: 'babel-loader',
options: {
cacheDirectory: true,
presets: [['es2015', { modules: false }], 'stage-0', 'react']
}
}
]
},
workers 的数量就是参与编译的 cpu 核心数量。thread-loader 的参数大致可以分为 workers 和 pool 两类:
- workerParallelJobs 一个 worker 进程中并行执行工作的数量,默认20
- workerNodeArgs 额外的 node.js 参数 ['--max-old-space-size', '1024']
- poolTimeout 闲置时定时删除 worker 进程,默认为 500ms
- poolParallelJobs 一个 pool 的并行任务数
如果项目的 css 文件也很多其实不妨为 css 也加上 thread-loader。
uglifyjs-webpack-plugin
js 完成编译之后通常还会有一个 uglify 的过程,这里如法炮制即可
optimization: {
minimizer: [
new UglifyJsPlugin({
cache: '.uglifyJsCache',
parallel: os.cpus().length,
uglifyOptions: {}
})
]
}
是不是很熟悉,加一个 cache 和 parallel 就可以了。
好了,本文到这里就结束了。如果本文对你有帮助不妨点个赞,如果有问题,非常欢迎来讨论(最好带上代码)。本文没有加时间的对比,因为我觉得没有什么意义,不同项目大小和参数设置会带来完全不同的效果。本文的方式适不适合你的项目,加一下试试就知道了。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。