Vuejs项目的Webpack2构建优化

最近在做的项目因为相对较大（打包有100多个chunk），在build构建的时候速度一直上不去，甚是烦恼。由于用的是vue-cli的webpack2模板，一开始并没有想着要对其进行优化，一直觉得是webpack本身慢+硬件慢（在开发机上开发，内存和CPU都不是很强力）的原因。后来慢到实在受不了了，转移到本地（i7+16G）开发的时候，发现生产构建居然需要90s，实在太长了。所以开始着手Webpack2构建优化。

优化webpack构建速度，总的来说有几个思路：

优化本身项目结构，模块的引入、拆分、共用
优化结构路径、让webpack接管的文件能够快速定位
优化uglify编译速度
优化webpack本身编译速度

有些是在开发的时候代码层面上的，有些则是需要在webpack配置层面上的。对于开发层面上来说，按需引入是很重要的一点。通常为了方便我们可以直接引入一个echarts，但是实际上并不需要echarts的所有功能。而按需引入则能最大程度上让

总得来说作用最大的有这几个：

开启webpack的cache
开启babel-loader的cache
指定modules以及配置项目相关的alias
配置loader的include和exclude
用CommonsChunkPlugin提取公用模块
使用DllPlugin和DllReferencePlugin预编译
换用happypack多进程构建
css-loader换成0.14.5版本。
换用webpack-uglify-parallel并行压缩代码

以下的配置都是基于vue-cli的webpack模板进行的优化。

开启webpack的cache

打开webpack.base.conf.js，在module.exports里加上cache: true：

module.exports = {
  cache: true,
  // ... 其他配置
}

开启`babel-loader`的cache

开启了cache的babel-loader，在下次编译的时候，遇到不变的部分可以直接拿取cache里的内容，能够较为明显地提高构建速度。在loader选项里只需要对babel-loader开启cacheDirectory=true即可。

// ... 其他配置
module: {
  rules: [
    {
      test: /\.js$/,
      loader: ['babel-loader?cacheDirectory=true']
    },
    // ... 其他loader
  ]
}

配置`modules`以及配置项目相关的`alias`

这个部分的配置实际上都是对webpack接管的文件路径的一些配置。通过这些配置，webpack可以不必自己遍历去搜索模块等，而可以通过我们定义的路径，快速定位。尤其是node_modules的位置，这个位置可以通过modules选项配置，节省webpack去查找的时间。

而alias是别名。通过编写alias，既能让webpack查找文件定位更快，在开发的时候，也能少些很多相对路径的../..，在引入模块的时候很方便。

同样是打开webpack.base.conf.js，在module.exports的resolve属性里配置modules和alias。其中vue-cli会自动配置一些默认的alias。

resolve: {
  //... 其他配置
  modules: [path.resolve(__dirname, '../../node_modules')], // node_modules文件夹所在的位置取决于跟webpack.base.conf.js相对的路径
  alias: {
    //... 其他配置
    api: path.resolve(__dirname, '../../server/api') // api文件所在的位置取决于跟webpack.base.conf.js相对的路径，在项目中会自动转换跟项目文件的相对路径
    //... 其他配置
  }
}

如果配置了如上的alias，那么我们在项目里，要引用比如api.js这个模块，可以直接这样做了：

1 2	import * as api from 'api' // 'api'是个alias，webpack会直接去找`server/api`

而不用手动去根据项目文件和api所在路径的相对位置去书写import的路径了。

配置`loader`的`include`和`exclude`

loader的include和exclude也就是需要loader接管编译的文件和不需要loader接管编译的文件。

这里我们举babel-loader为例。通常情况下，我们不需要loader去编译node_modules下的js文件，而我们只需要编译我们项目目录下的js就行了。这样可以通过配置这两个选项，能够最小范围的限制babel-loader需要编译的内容，能够有效提升构建速度。

同样打开webpack.base.conf.js，在rules的babel-loader那块加上include和exclude。

// ... 其他配置
module: {
  rules: [
    {
      test: /\.js$/,
      loader: ['babel-loader?cacheDirectory=true'],
      include: [resolve('src')], // src是项目开发的目录
      exclude: [path.resolve('../../node_modules')] // 不需要编译node_modules下的js 
    },
    // ... 其他loader
  ]
}

使用`CommonsChunkPlugin`提取公用模块

我们经常会有这种场景：在a.vue组件里引入了a.js或者比如c.vue，在b.vue组件里也引入了a.js或者c.vue。这样，打包了之后将会把引入的模块重复打包。而CommonsChuncksPlugin就是把这样重复打包的模块给抽取出来单独打包的插件。这个能够显著降低最后打包的体积，也能提升一些打包速度。

在webpack.base.conf.js里的plugins可以加上这段：

plugins: [
  new webpack.optimize.CommonsChunkPlugin({
    async: 'shared-module',
    minChunks: (module, count) => (
      count >= 2    // 当一个模块被重复引用2次或以上的时候单独打包起来。 
    )
  }),

  //...
]

使用`DllPlugin`和`DllReferencePlugin`预编译

这个也是一个大杀器。将一些全局都要用到的依赖抽离出来，预编译一遍，然后引入项目中，作为依赖项。而webpack在正式编译的时候就可以放过他们了。能够很明显地提升webpack的构建速度。类似于Windows的dll文件的设计理念。dll资源能够有效的解决资源循环依赖的问题。能够大大减少项目里重复依赖的问题。

在webpack.base.conf.js所在的文件夹里建立一个webpack.dll.conf.js，我们将一些常用的依赖打包成dll。

首先配置一下DllPlugin的资源列表。

const path = require('path');
const webpack = require('webpack');

module.exports = {
  entry: {
    vendor: ['vue/dist/vue.esm.js','vue-router','axios','vuex'] // 需要打包起来的依赖
  },
  output: {
    path: path.join(__dirname, '../../public/js'), // 输出的路径
    filename: '[name].dll.js', // 输出的文件，将会根据entry命名为vendor.dll.js
    library: '[name]_library' // 暴露出的全局变量名
  },
  plugins: [
    new webpack.DllPlugin({
      path: path.join(__dirname, '../../public/js/', '[name]-mainfest.json'), // 描述依赖对应关系的json文件
      name: '[name]_library', 
      context: __dirname // 执行的上下文环境，对之后DllReferencePlugin有用
    }),
    new webpack.optimize.UglifyJsPlugin({ // uglifjs压缩
      compress: {
        warnings: false
      }
    })
  ]
}

为了方便之后构建，可以在package.json里加上这么一句scripts：

scripts: {
  //... 其他scripts
  "build:dll": "webpack --config ./webpack/build/webpack.dll.conf.js" // 填写你项目中webpack.dll.conf.js的路径
}

然后执行一下npm run build:dll，就可以在输出的目录里输出一个vendor.dll.js和vendor-mainfest.json两个文件。

之后打开webpack.base.conf.js。在plugins一项里加上DllReferencePlugin。这个plugin是用于引入上一层里生成的json的。

module.exports = {
  //... 其他配置
  
  plugins: [
    // ... 其他插件
    new webpack.DllReferencePlugin({
      context: __dirname,
      manifest: require('../../public/js/vendor-mainfest.json') // 指向这个json
    })
  ]
}

最后，在项目输出的index.html里，最先引入这个js：

1	<script type="text/javascript" src="public/js/vendor.dll.js"></script>

这样，webpack将不会再解析dll里的资源了。构建速度将会有质的提高。

换用`happypack`多进程构建

webpack的构建毕竟还是单进程的。采用happypack可以改为多进程构建。而对于小文件而言，happypack效果并不明显。而对于babel-loader编译的庞大的js文件群来说，则是一大利器。

首先安装：npm install happypack --save-dev或者yarn add happypack

然后修改webpack.base.conf.js的配置如下：

const os = require('os');
const HappyPack  = require('happypack');
const happThreadPool = HappyPack.ThreadPool({size: os.cpus().length}); // 采用多进程，进程数由CPU核数决定

//...
module.exports = {
  plugins: [
    // ...
    new HappyPack({
      id: 'js',
      cache: true,
      loaders: ['babel-loader?cacheDirectory=true'],
      threadPool: happThreadPool
    })
  ],
  module: {
    rules: [
      {
        test: /\.vue$/,
        loader: 'vue-loader',
        options: {
          loaders: {
            js: 'happypack/loader?id=js' // 将loader换成happypack
          }
        }
      },
      {
        test: /\.js$/,
        loader: ['happypack/loader?id=js'], // 将loader换成happypack
        include: [resolve('src')], // src是项目开发的目录
        exclude: [path.resolve('../../node_modules')] // 不需要编译node_modules下的js 
      },
      //...
    ]
  }
}

提速还是比较明显的。

`css-loader`换成`0.14.5`版本

可以查看这个issue，说是该版本之上的版本会拖慢webpack的构建速度。我自己实验了之后确实能快几秒钟。

换用`webpack-uglify-parallel`并行压缩代码

webpack自带的uglifyjs插件效果确实不错。只不过由于受限于单线程，所以压缩速度不够高。换成webpack-uglify-parallel这个插件之后能够有效减少压缩的时间。

首先安装：npm install webpack-uglify-parallel --save-dev 或者 yarn add webpack-uglify-parallel

找到webpack.prod.conf.js（由于开发模式不需要进行uglify压缩），将原本的：

plugins: [
  new webpack.optimize.UglifyJsPlugin({
    compress: {
      warnings: false
    },
    sourceMap: true
  })
  // ... 其他配置
]

替换为：

const UglifyJsparallelPlugin = require('webpack-uglify-parallel');
const os = require('os');

// ... 其他配置
plugins: []
new UglifyJsparallelPlugin({
  workers: os.cpus().length,
  mangle: true,
  compressor: {
    warnings: false,
    drop_console: true,
    drop_debugger: true
  }
})

效果综述

经过以上优化，原本90+s的构建时间，优化到30+秒效果还是很明显的。原本HMR模式初始化需要50+秒，也优化到了20+秒的程度。不过，还是有一个至今我自己还无法解决的问题，那就是HMR模式，rebuild时间会越来越长，直到超过初始化的20+秒。此时只能重新开关一次HMR模式。这一点我还无法找到具体原因是什么。不过，至少生产的构建时间得到了60%的优化，效果还是挺好的。

开启webpack的cache

开启babel-loader的cache

配置modules以及配置项目相关的alias

配置loader的include和exclude

使用CommonsChunkPlugin提取公用模块

使用DllPlugin和DllReferencePlugin预编译

换用happypack多进程构建

css-loader换成0.14.5版本

换用webpack-uglify-parallel并行压缩代码