详解webpack构建优化

当项目越来越复杂时，会面临着构建速度慢和构建出来的文件体积大的问题。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/展示分析结果。

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 在多核并发方面的优势。参考webpack视频讲解：进入学习

比较常见的有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