构建性能

# 常规

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

# 保持版本最新

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

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

# Loaders

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

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

1
2
3
4

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

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

1
2
3
4
5

# Bootstrap

每个额外的 loader/plugin 都有启动时间。尽量少使用不同的工具。

# 解析

以下几步可以提供解析速度:

尽量减少 resolve.modules, resolve.extensions, resolve.mainFiles, resolve.descriptionFiles 中类目的数量，因为他们会增加文件系统调用的次数。
如果你不使用 symlinks ，可以设置 resolve.symlinks: false (例如 npm link 或者 yarn link).
如果你使用自定义解析 plugins ，并且没有指定 context 信息，可以设置 resolve.cacheWithContext: false 。

# Dlls

使用 DllPlugin 将更改不频繁的代码进行单独编译。这将改善引用程序的编译速度，即使它增加了构建过程的复杂性。

# Smaller = Faster

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

使用更少/更小的库。
在多页面应用程序中使用 CommonsChunksPlugin。
在多页面应用程序中以 async 模式使用 CommonsChunksPlugin 。
移除不使用的代码。
只编译你当前正在开发部分的代码。

# Worker Pool

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

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

# 持久化缓存

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

# 自定义 plugins/loaders

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

# Development

下面步骤对于 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
})

1
2
3
4

# Production

以下步骤在 production 中非常有用。

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

# 多个编译时

当进行多个编译时，以下工具可以帮助到你:

parallel-webpack (opens new window): 它允许编译工作在 worker 池中进行。
cache-loader: 缓存可以在多个编译时之间共享。

# Source Maps

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

# 工具相关问题

下列工具存在某些可能会降低构建性能的问题。

# Babel

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

# TypeScript

在单独的进程中使用 fork-ts-checker-webpack-plugin 进行类型检查。
配置 loaders 跳过类型检查。
使用 ts-loader 时，设置 happyPackMode: true / transpileOnly: true。

# Sass

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

编辑

#Webpack

上次更新: 2021/08/22, 01:09:59

← 使用环境变量内容安全策略→