webpack提升构建速度

构建消耗的时间变长了，如果是使用 CI 服务来做构建，大部分情况下我们无需等待，其实影响不大。但是本地的 webpack 开发环境服务启动时的速度和我们日常开发工作息息相关，在一些性能不是特别突出的设备上（例如便携式笔记本等等），启动时的长时间等待可能会让你越来越受不了。

博主亲身经历的一个项目，使用 webpack 构建的时长可以达到 6 分钟左右，这种场景下，就算用 CI 服务，在遇见需要紧急发布修复问题时，也会让人很抓狂。

也许某一天你负责的项目也会到了需要优化 webpack 构建性能的时候，所以这一章节我们来聊聊如何提升 webpack 的构建速度。

提升 webpack 构建速度本质上就是想办法让 webpack 少干点活，活少了速度自然快了，尽量避免 webpack 去做一些不必要的事情，记得这个主要方向，后续的针对构建速度的优化都是围绕着这一方向展开。

配置优化

减少 `resolve` 的解析

在前边第三小节我们详细介绍了 webpack 的 resolve 配置，如果我们可以精简 resolve 配置，让 webpack 在查询模块路径时尽可能快速地定位到需要的模块，不做额外的查询工作，那么 webpack 的构建速度也会快一些，下面举个例子，介绍如何在 resolve 这一块做优化：

resolve: {
  modules: [
    path.resolve(__dirname, 'node_modules'), // 使用绝对路径指定 node_modules，不做过多查询
  ],

  // 删除不必要的后缀自动补全，少了文件后缀的自动匹配，即减少了文件路径查询的工作
  // 其他文件可以在编码时指定后缀，如 import('./index.scss')
  extensions: [".js"], 

  // 避免新增默认文件，编码时使用详细的文件路径，代码会更容易解读，也有益于提高构建速度
  mainFiles: ['index'],
},

上述是可以从配置 resolve 下手提升 webpack 构建速度的配置例子。

我们在编码时，如果是使用我们自己本地的代码模块，尽可能编写完整的路径，避免使用目录名，如：import './lib/slider/index.js'，这样的代码既清晰易懂，webpack 也不用去多次查询来确定使用哪个文件，一步到位。

把 loader 应用的文件范围缩小

我们在使用 loader 的时候，尽可能把 loader 应用的文件范围缩小，只在最少数必须的代码模块中去使用必要的 loader，例如 node_modules 目录下的其他依赖类库文件，基本就是直接编译好可用的代码，无须再经过 loader 处理了：

rules: [ 
  {
    test: /\.jsx?/,
    include: [ 
      path.resolve(__dirname, 'src'), 
      // 限定只在 src 目录下的 js/jsx 文件需要经 babel-loader 处理
      // 通常我们需要 loader 处理的文件都是存放在 src 目录
    ],
    use: 'babel-loader',
  },
  // ...
],

如上边这个例子，如果没有配置 include，所有的外部依赖模块都经过 Babel 处理的话，构建速度也是会收很大影响的。

减少 plugin 的消耗

webpack 的 plugin 会在构建的过程中加入其它的工作步骤，如果可以的话，适当地移除掉一些没有必要的 plugin。

区分 mode 会让 webpack 的构建更加有针对性，更加高效。例如当 mode 为 development 时，webpack 会避免使用一些提高应用代码加载性能的配置项，如 UglifyJsPlugin，ExtractTextPlugin 等，这样可以更快地启动开发环境的服务，而当 mode 为 production 时，webpack 会避免使用一些便于 debug 的配置，来提升构建时的速度，例如极其消耗性能的 Source Maps 支持。

选择合适的 devtool

前边的内容我们提过，devtool 可以用于配置 webpack 构建出来的 sourcemap 相关的内容，输出详细的 sourcemap 是相当影响 webpack 的构建速度的，所以这里需要做一个取舍，在构建生产环境代码时不输出 sourcemap，而开发环境时一般选用 eval-cheap-source-map 来确保 sourcemap 基本可用的情况下还有着不错的构建速度。

使用工具

thread-loader

thread-loader 是官方提供的一个可以利用多进程加速 loader 执行的 loader，如果项目中 loader 的运行处理占用比较多的时间，例如 babel 或者 typescript 解析和编译的代码量很大，或者 image—webpack-loader 处理图片耗时比较久，那么可以尝试使用 thread-loader 来提速。下边是基础使用的例子：

const threadLoader = require('thread-loader');

const threadLoaderOptions = {
  // 这里填写对应 thread-loader 的配置
  // 预热时的配置和使用 thread-loader 时的配置要一致，所以这里统一使用一个变量来管理
  // 配置参考官方文档：https://github.com/webpack-contrib/thread-loader
}

// thread-loader 的预热，可以加速启动
threadLoader.warmup(threadLoader, [
  'babel-loader',
  // 更多其他需要使用 thread-loader 的 loader
]);

module.exports = {
  // ...
  module: {
    rules: [
      {
        test: /\.jsx?/, // 匹配文件路径的正则表达式，通常我们都是匹配文件类型后缀
        use: [
          // 在你需要的 loader 前加上 thread-loader
          {
            loader: 'thread-loader',
            options: threadLoaderOptions
          },
          {
            loader: 'babel-loader', // 指定使用的 loader
            options: {
              presets: ['@babel/preset-env'],
            },
          },
        ]
      },
      // ...
    ],
}

值得注意的是，由于 thread-loader 新启动进程也需要耗时，所以如果不是运算特别多的 loader 使用 thread-loader 的话可能速度会更慢。

DLLPlugin

DLLPlugin 是 webpack 官方提供的一个插件，也是用来分离代码的，和 optimization.splitChunks有异曲同工之妙，之所以把 DLLPlugin 放到 webpack 构建性能优化这一部分，是因为它的配置相对繁琐，如果项目不涉及性能优化这一块，基本上使用 optimization.splitChunks 即可。

我们来看一下 DLLPlugin 如何使用，使用这个插件时需要额外的一个构建配置，用来打包公共的那一部分代码，举个例子，假设这个额外配置是 webpack.dll.config.js：

module.exports = {
  name: 'vendor',
  entry: ['react', 'react-dom'], // 这个例子我们打包 react & react-dom 作为公共类库

  output: {
    path: path.resolve(__dirname, "dist"),
    filename: "vendor.js",
    library: "vendor_[hash]" // 打包后对外暴露的类库名称
  },

  plugins: [
    new webpack.DllPlugin({
      name: 'vendor_[hash]',
      path: path.resolve(__dirname, "dist/manifest.json"), // 使用 DLLPlugin 在打包的时候生成一个 manifest 文件
    })
  ],
}

然后就是我们正常的应用构建配置，在那个的基础上添加两个一个新的 webpack.DllReferencePlugin 配置：

module.exports = {
  plugins: [
    new webpack.DllReferencePlugin({
      manifest: path.resolve(__dirname, 'dist/manifest.json'), 
      // 指定需要用到的 manifest 文件，
      // webpack 会根据这个 manifest 文件的信息，分析出哪些模块无需打包，直接从另外的文件暴露出来的内容中获取
    }),
  ],
}

在构建的时候，我们需要优先使用 webpack.dll.config.js 来打包，如 webpack --config webpack.dll.config.js --mode production，构建后生成公共代码模块的文件 vendor.js 和 manifest.json，然后再进行应用代码的构建。

你会发现构建结果的应用代码中不包含 react 和 react-dom 的代码内容，这一部分代码内容会放在 vendor.js 这个文件中，而你的应用要正常使用的话，需要在 HTML 文件中按顺序引用这两个代码文件，如：

<script src="vendor.js"></script>
<script src="main.js"></script>

作用是不是和 optimization.splitChunks 很相似，但是有个区别，DLLPlugin 构建出来的内容无需每次都重新构建，后续应用代码部分变更时，你不用再执行配置为 webpack.dll.config.js 这一部分的构建，沿用原本的构建结果即可，所以相比 optimization.splitChunks，使用 DLLPlugin 时，构建速度是会有显著提高的。

但是很显然，DLLPlugin 的配置要麻烦得多，并且需要关心你公共部分代码的变化，当你升级 lodash（即你的公共部分代码的内容变更）时，要重新去执行 webpack.dll.config.js 这一部分的构建，不然沿用的依旧是旧的构建结果，使用上并不如 optimization.splitChunks 来得方便。这是一种取舍，根据项目的实际情况采用合适的做法。

还有一点需要注意的是，html-webpack-plugin 并不会自动处理 DLLPlugin 分离出来的那个公共代码文件，我们需要自己处理这一部分的内容，可以考虑使用 add-asset-html-webpack-plugin，关于这一个的使用就不讲解了，详细参考官方的说明文档：使用 add-asset-html-webpack-plugin。

流程优化

拆分构建步骤

这里拿图片的压缩作为一个例子讲解，我们在前边的小节提到图片可以使用 webpack 的 image-webpack-loader 来压缩图片，在对 webpack 构建性能要求不高的时候，这样是一种很简便的处理方式，但是要考虑提高 webpack 构建速度时，这一块的处理就得重新考虑一下了，思考一下是否有必要在 webpack 每次构建时都处理一次图片压缩。

我们可以直接使用 imagemin 来做图片压缩，编写简单的命令即可。然后使用 pre-commit 这个类库来配置对应的命令，使其在 git commit 的时候触发，并且将要提交的文件替换为压缩后的文件。

这样提交到代码仓库的图片就已经是压缩好的了，以后在项目中再次使用到的这些图片就无需再进行压缩处理了，image-webpack-loader 也就没有必要了。

使用同样的思路去考虑其他构建步骤，是否有必要在每次构建时处理，可以考虑用 git hooks 或者工作流的一些机制来触发一些构建工作，来减少 webpack 的构建压力。

拆分项目代码

webpack 的构建性能优化是比较琐碎的工作，当我们需要去考虑 webpack 的构建性能问题时，往往面对的是项目过大，涉及的代码模块过多的情况。在这种场景下你单独做某一个点的优化其实很难看出效果，你可能需要从我们上述提到的多个方面入手，逐一处理，验证，有些时候你甚至会觉得吃力不讨好，投入产出比太低了，这个时候我们可以考虑换一个角度来思考我们遇到的问题。

例如，拆分项目的代码，根据一定的粒度，把不同的业务代码拆分到不同的代码库去维护和管理，这样子单一业务下的代码变更就无须整个项目跟着去做构建，这样也是解决因项目过大导致的构建速度慢的一种思路，并且如果处理妥当，从工程角度上可能会给你带来其他的一些好处，例如发布异常时的局部代码回滚相对方便等等。

版本更新

官方发布的 webpack 4.0 更新日志来看，webpack 4.0 版本做了很多关于提升构建性能的工作，我觉得比较重要的改进有这么几个：

AST 可以直接从 loader 直接传递给 webpack，避免额外的解析，对这一个优化细节有兴趣的可以查看这个 PR。
使用速度更快的 md4 作为默认的 hash 方法，对于大型项目来说，文件一多，需要 hash 处理的内容就多，webpack 的 hash 处理优化对整体的构建速度提升应该还是有一定的效果的。
Node 语言层面的优化，如用 for of 替换 forEach，用 Map 和 Set 替换普通的对象字面量等等，这一部分就不展开讲了，有兴趣的同学可以去 webpack 的 PRs 寻找更多的内容。
后续更新的版本把 uglifyjs-webpack-plugin 换成了 terser-webpack-plugin，可以更好地针对 ES6 的代码进行处理。

更多关于性能优化的 webpack 迭代可以查看官方的 release 文档：webpack release，搜索 performance 关键字就好。

webpack 5 的大版本，针对性能优化还有更棒的持久化缓存方案推出，让每一次的构建打包可以向我们的 webpack-dev-server 一样，只针对变化部分做增量构建，可以极大地提高构建性能，这个值得期待一下，有兴趣的同学可以使用 webpack 5 beta 版本来测试一下。

总结

本文我们首先介绍了如何从多个配置优化的方式来提高 webpack 的构建速度：

减少 resolve 的解析
把 loader 应用的文件范围缩小
减少 plugin 的消耗
选择合适的 devtool

在必要的时候，我们可以使用 thread-loader 和 DLLPlugin 来帮助我们进一步优化 webpack 的构建性能，但是从另外的角度考虑，在不过分依赖 webpack 构建的情况下，我们可以从流程优化上着手，如提交代码前就压缩图片，拆分构建的代码库等，以此来减少 webpack 构建的工作量。

同时，更新 Node 版本和 webpack 版本都有助于让我们的构建变得更快，勤劳的程序员们一直在优化代码库的性能，别辜负了他们的努力，尽可能让构建跑在最新的运行环境上吧。