构建性能 | Build Performance

本指南包含一些有助于提高构建/编译性能的有用提示。

常规

无论你正在 development 或构建 production，以下做法应该帮助到你达到最佳。

保持最新版本

使用最新的 webpack 版本。我们会经常进行性能优化。 webpack 的最新稳定版本是：

保持最新的 Node.js 也能够保证性能。除此之外，保证你的包管理工具 (例如 npm 或者 yarn ) 为最新也能保证性能。较新的版本能够建立更高效的模块树以及提高解析速度。

Loaders

将 loaders 应用于最少数的必要模块中。而不是：

{
  test: /\.js$/,
  loader: "babel-loader"
}

使用 include 字段仅将 loader 模块应用在实际需要用其转换的位置中：

{
  test: /\.js$/,
  include: path.resolve(__dirname, "src"),
  loader: "babel-loader"
}

Bootstrap

每个额外的加载器/插件都有启动时间。尽量使用尽可能少的不同工具。

解决

以下步骤可以提高解析速度：

• 尽量减少在项目数resolve.modules，resolve.extensions，resolve.mainFiles，resolve.descriptionFiles因为它们增加文件系统调用的次数。

• 如果你不使用 symlinks ，可以设置 resolve.symlinks: false (例如 npm link 或者 yarn link).

• 如果你使用自定义解析 plugins ，并且没有指定 context 信息，可以设置 resolve.cacheWithContext: false 。

Dlls

使用将DllPlugin较少更改的代码移动到单独的编译中。这会提高应用程序的编译速度，尽管它增加了构建过程的复杂性。

更小=更快

减少编译的整体大小，以提高构建性能。尽量保持 chunks 小巧。

• 使用更少/更小的库。

• 在多页面应用程序中使用 CommonsChunksPlugin。

• 在多页面应用程序中以 async 模式使用 CommonsChunksPlugin

• 删除未使用的代码。

• 只编译你现在正在开发的代码的一部分。

工作池

thread-loader 可以将非常消耗资源的 loaders 转存到 worker pool 中。

不要使用太多的 workers ，因为 Node.js 的 runtime 和 loader 有一定的启动开销。最小化 workers 和主进程间的模块传输。进程间通讯(IPC)是非常消耗资源的。

持久缓存

使用 cache-loader 启用持久化缓存。使用 package.json 中的 "postinstall" 清除缓存目录。

自定义插件/装载机

这里不对它们配置的性能问题作过多赘述。

发展

以下步骤在development中特别有用。

增量编译

使用 webpack 的监听模式。不要使用其他工具来监听你的文件和调用 webpack 。在监听模式下构建会记录时间戳并将信息传递给编译让缓存失效。

在某些设置中，监听会回退到轮询模式。有许多监听文件会导致 CPU 大量负载。在这些情况下，你可以使用 watchOptions.poll 来增加轮询的间隔。

在内存中编译

以下几个实用工具通过在内存中进行代码的编译和资源的提供，但并不写入磁盘来提高性能:

• webpack-dev-server

• webpack-hot-middleware

• webpack-dev-middleware

Devtool

注意不同devtool设置的性能差异。

• "eval" 具有最好的性能，但并不能帮助你转译代码。

• 如果你能接受稍差一些的 mapping 质量，可以使用 cheap-source-map 选项来提高性能

• 使用 eval-source-map 配置进行增量编译。

=>在大多数情况下cheap-module-eval-source-map是最好的选择。

避免在生产环境下才会用到的工具

某些实用工具， plugins 和 loaders 都只能在构建生产环境时才有用。例如，在开发时使用 UglifyJsPlugin 来压缩和修改代码是没有意义的。以下这些工具在开发中通常被排除在外:

• UglifyJsPlugin

• ExtractTextPlugin

• [hash]/[chunkhash]

• AggressiveSplittingPlugin

• AggressiveMergingPlugin

• ModuleConcatenationPlugin

最小化入口 chunk

webpack 只会在文件系统中生成已经更新的 chunk 。对于某些配置选项(HMR, [name]/[chunkhash] in output.chunkFilename, [hash])来说，除了更新的 chunks 无效之外，入口 chunk 也不会生效。

应当在生成入口 chunk 时，尽量减少入口 chunk 的体积，以提高性能。下述代码块将只提取包含 runtime 的 chunk ，其他 chunk 都作为子模块：

new CommonsChunkPlugin({
  name: "manifest",
  minChunks: Infinity
})

生产

以下步骤在 production 中特别有用。

不要为了非常小的性能增益，牺牲你应用程序的质量！ 请注意，优化代码质量在大多数情况下比构建性能更重要。

多个编译时

使用多个编译时，以下工具可以提供帮助：

• parallel-webpack：它允许在工作池中编译。

• cache-loader：缓存可以在多个编译之间共享。

源图

Source maps 真的很消耗资源。你真的需要他们？

具体的工具问题

以下工具具有某些可能会降低构建性能的问题。

Babel

• 项目中的 preset/plugins 数量最小化。

• fork-ts-checker-webpack-plugin在单独的过程中使用for进行类型检查。

• 配置加载程序以跳过类型检查。

• 使用ts-loader在 happyPackMode: true/ transpileOnly: true。

Sass

• node-sass 中有个来自 Node.js 线程池的阻塞线程的 bug。 当使用 thread-loader 时，需要设置 workerParallelJobs: 2。