分包优化（Code Splitting）

1. 什么是分包

默认情况下，Webpack 会将所有代码构建成一个单独的包，这在小型项目通常不会有明显的性能问题，但伴随着项目的推进，包体积逐步增长可能会导致应用的首屏加载时间越来越长。归根结底这种将所有资源打包成一个文件的方式存在两个弊端：

• 「资源冗余」：客户端必须等待整个应用的代码包都加载完毕才能启动运行，但可能用户当下访问的内容只需要使用其中一部分代码
• 「缓存失效」：将所有资源打成一个包后，所有改动 —— 即使只是修改了一个字符，客户端都需要重新下载整个代码包，缓存命中率极低

tip

这些问题都可以通过对产物做适当的分解拆包（Code Splitting）解决。

• 对于资源冗余，常用的方法是配置 懒加载（也叫做按需加载），使用 import()（dynamic import 语法）加载模块，Webpack 会将该模块单独生成一个 Async Chunk，并且将 import() 语法解析为 __webpack_require__.e 函数，最终使用 JSONP 的方式加载 Async Chunk。通常用于 路由懒加载，即服务器只返回当前路由对应页面所需的资源，这样既可以减小通过网络传输的文件体积，同时浏览器也无需一次加载整个应用全部代码，提升了资源加载、解析速度，缩短首屏时间。

  启用路由懒加载有一个弊端，浏览器只有执行了 main chunk 之后，才知道要加载哪些 async chunk，这就导致资源文件加载延迟，出现瀑布流现象。这里需要 预加载异步 Chunk，思路是生成和路由对应的 assets 表，然后在 HTML 最前面加入「匹配路由生成 link preload 标签」的脚本，在浏览器空闲的时候把 async chunk 给下载下来。Webpack 4.6+ 可以使用魔法注释动态向 head 里插入 link 标签。

  参考：https://webpack.js.org/guides/code-splitting/#prefetchingpreloading-modules

• 对于缓存失效，由于 node_modules 中的资源通常变动较少，因此可以抽成一个单独的 Chunk，在客户端设置强缓存，那么业务代码的频繁变动不会导致这部分第三方资源被无意义地重复加载。为此，Webpack 专门提供了 SplitChunksPlugin 插件，用于实现产物分包。

SplitChunksPlugin 是 Webpack 4 之后引入的分包方案（此前为 CommonsChunkPlugin），它能够基于一些启发式的规则将 Module 编排进不同的 Chunk 序列，并最终将应用代码分门别类打包出多份产物，从而实现分包功能。

使用上，SplitChunksPlugin 的配置规则比较抽象，仔细拆解后关键逻辑在于：

• SplitChunksPlugin 通过 module 被引用频率、chunk 大小、包请求数 三个维度决定是否执行分包操作，这些决策都可以通过 optimization.splitChunks 配置项调整定制，基于这些维度我们可以实现：
  • 单独打包某些特定路径的内容，例如 node_modules 打包为 vendors
  • 单独打包使用频率较高的文件
• SplitChunksPlugin 还提供 配置组 概念 optimization.splitChunks.cacheGroup，用于为不同类型的资源设置更有针对性的配置信息
• SplitChunksPlugin 还内置了 default 与 defaultVendors 两个配置组，提供一些开箱即用的特性：
  • node_modules 资源会命中 defaultVendors 规则，并被单独打包
  • 只有包体超过 20kb 的 Chunk 才会被单独打包
  • 加载 Async Chunk 所需请求数不得超过 30
  • 加载 Initial Chunk 所需请求数不得超过 30

tip

这里所说的请求数不能等价对标到 http 资源请求数，下文会细讲

2. 什么是 Chunk

在 Webpack 中，Chunk 是打包产物基本组织单位，可以等价认为有多少 Chunk 就会对应生成多少产物(Bundle)。Webpack 内部包含三种类型的 Chunk：

• Initial Chunk：基于 Entry 配置项生成的 Chunk，在多入口打包的情况下，配置几个 Entry 就生成几个 Chunk
• Async Chunk：异步模块引用，如 import(xxx) 语句对应的异步 Chunk
• Runtime Chunk：只包含运行时代码的 Chunk

tip

参考：

有点难的知识点：Webpack Chunk 分包规则详解

而 SplitChunksPlugin 默认只对 Async Chunk 生效，开发者也可以通过 optimization.splitChunks.chunks 调整作用范围，该配置项支持如下值：

• 字符串 'all' ：对 Initial Chunk 与 Async Chunk 都生效，建议优先使用该值
• 字符串 'initial' ：只对 Initial Chunk 生效
• 字符串 'async' ：只对 Async Chunk 生效
• 函数 (chunk) => boolean ：该函数返回 true 时生效

例如：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      chunks: 'all',
    },
  },
}

3. 分包策略详解

3.1 根据 Module 使用频率分包

SplitChunksPlugin 支持按 Module 被 Chunk 引用的次数决定是否进行分包，开发者可通过 optimization.splitChunks.minChunks 设定最小引用次数，例如：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      // 设定引用次数超过 4 的模块才进行分包
      minChunks: 3
    },
  },
}

需要注意，这里“被 Chunk 引用次数”并不直接等价于被 import 的次数，而是取决于上游调用者是否被视作 Initial Chunk 或 Async Chunk 处理，例如：

// common.js
export default "common chunk";

// async-module.js
import common from './common'

// entry-a.js
import common from './common'
import('./async-module')

// entry-b.js
import common from './common'

// webpack.config.js
module.exports = {
  entry: {
    entry1: './src/entry-a.js',
    entry2: './src/entry-b.js'
  },
  // ...
  optimization: {
    splitChunks: {
      minChunks: 2
    }
  }
};

上例包含四个模块，形成如下模块关系图：

示例中，entry-a、entry-b 分别被视作 Initial Chunk 处理；async-module 被 entry-a 以异步方式引入，因此被视作 Async Chunk 处理。那么对于 common 模块来说，分别被三个不同的 Chunk 引入，此时引用次数为 3，命中 optimization.splitChunks.minChunks = 2 规则，因此该模块 「可能」 会被单独分包，最终产物：

• entry-a.js
• entry-b.js
• async-module.js
• commont.js

tip

这里说 可能 是因为分包还受到 分包数量 和 分包体积 的影响，下面会介绍

3.2 限制分包数量

在满足 minChunks 基础上，还可以通过 maxInitialRequest/maxAsyncRequests 配置项限定分包数量，配置项语义：

• maxInitialRequest：用于设置 Initial Chunk 最大并行请求数
• maxAsyncRequests：用于设置 Async Chunk 最大并行请求数

这里所说的“请求数”，是指加载一个 Chunk 时所需同步加载的分包数。例如对于一个 Chunk A，如果根据分包规则(如模块引用次数、第三方包)分离出了若干子 Chunk A¡，那么请求 A 时，浏览器需要同时请求所有的 A¡，此时并行请求数等于 ¡ 个分包加 A 主包，即 ¡+1。

举个例子，对于上例所说的模块关系：

若 minChunks = 2 ，则 common 模块命中 minChunks 规则被独立分包，浏览器请求 entry-a 时，则需要同时请求 common 包，并行请求数为 1 + 1 = 2。

而对于下述模块关系：

若 minChunks = 2 ，则 common-1 、common-2 同时命中 minChunks 规则被分别打包，浏览器请求 entry-b 时需要同时请求 common-1 、common-2 两个分包，并行数为 2 + 1 = 3，此时若 maxInitialRequest = 2，则分包数超过阈值，SplitChunksPlugin 会放弃 common-1 、common-2 中体积较小的分包。maxAsyncRequest 逻辑与此类似，不在赘述。

并行请求数关键逻辑总结如下：

• Initial Chunk 本身算一个请求
• Async Chunk 不算并行请求
• 通过 runtimeChunk 拆分出的 runtime 不算并行请求
• 如果同时有两个 Chunk 满足拆分规则，但是 maxInitialRequests (或 maxAsyncRequest) 的值只能允许再拆分一个模块，那么体积更大的模块会被优先拆解

3.3 限制分包体积

在满足 minChunks 与 maxInitialRequests 的基础上，SplitChunksPlugin 还会进一步判断 Chunk 包大小决定是否分包，这一规则相关的配置项非常多：

• minSize：超过这个尺寸的 Chunk 才会正式被分包
• maxSize：超过这个尺寸的 Chunk 会尝试继续做分包
• maxAsyncSize：与 maxSize 功能类似，但只对异步引入的模块生效
• maxInitialSize：与 maxSize 类似，但只对 entry 配置的入口模块生效
• enforceSizeThreshold：超过这个尺寸的 Chunk 会被强制分包，忽略上述其它 size 限制

那么，结合前面介绍的两种规则，SplitChunksPlugin 的主体流程如下：

1. SplitChunksPlugin 尝试将命中 minChunks 规则的 Module 统一抽到一个额外的 Chunk 对象；

2. 判断该 Chunk 是否满足 maxInitialRequests 阈值，若满足则进行下一步；

3. 判断该 Chunk 资源的体积是否大于上述配置项 minSize 声明的下限阈值；

   a. 如果体积 「小于」 minSize 则取消这次分包，对应的 Module 依然会被合并入原来的 Chunk

   b. 如果 Chunk 体积 「大于」 minSize 则判断是否超过 maxSize、maxAsyncSize、maxInitialSize 声明的上限阈值，如果超过则尝试将该 Chunk 继续分割成更小的部分

tip

虽然 maxSize 等上限阈值逻辑会产生更多的包体，但缓存粒度会更小，命中率相对也会更高，配合持久缓存与 HTTP 2 的多路复用能力，网络性能反而会有正向收益。

以上述模块关系为例：

若此时 Webpack 配置的 minChunks 大于 2，且 maxInitialRequests 也同样大于 2，如果 common 模块的体积大于上述说明的 minSize 配置项则分包成功，common 会被分离为单独的 Chunk，否则会被合并入原来的 3 个 Chunk。

tip

注意，这些属性的优先级顺序为：

maxInitialRequest/maxAsyncRequests < maxSize < minSize

而命中 enforceSizeThreshold 阈值的 Chunk 会直接跳过这些属性判断，强制进行分包。

4. 使用 cacheGroups

4.1 理解缓存组

除上述 minChunks、maxInitialRequest、minSize 等基础规则外，SplitChunksPlugin 还提供了 cacheGroups 配置项用于为不同文件组设置不同的规则，例如：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      cacheGroups: {
        vendors: {
            test: /[\\/]node_modules[\\/]/,
            minChunks: 1,
            minSize: 0
        }
      },
    },
  },
};

示例通过 cacheGroups 属性设置 vendors 缓存组，所有命中 vendors.test 规则的模块都会被视作 vendors 分组，优先应用该组下的 minChunks、minSize 等分包配置。

除了 minChunks 等分包基础配置项之外，cacheGroups 还支持一些与分组逻辑强相关的属性，包括：

• test：接受正则表达式、函数及字符串，所有符合 test 判断的 Module 或 Chunk 都会被分到该组
• type：接受正则表达式、函数及字符串，与 test 类似均用于筛选分组命中的模块，区别是它判断的依据是文件类型而不是文件名，例如 type = 'json' 会命中所有 JSON 文件
• idHint：字符串型，用于设置 Chunk ID，它还会被追加到最终产物文件名中，例如 idHint = 'vendors' 时，输出产物文件名形如 vendors-xxx-xxx.js
• priority：数字型，用于设置该分组的优先级，若模块命中多个缓存组，则优先被分到 priority 更大的组

缓存组的作用在于能为不同类型的资源设置更具适用性的分包规则，一个典型场景是将所有 node_modules 下的模块统一打包到 vendors 产物，从而实现第三方库与业务代码的分离。

4.2 默认分组

Webpack 提供了两个开箱即用的 cacheGroups，分别命名为 default 与 defaultVendors，默认配置：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      cacheGroups: {
        default: {
          idHint: "",
          reuseExistingChunk: true,
          minChunks: 2,
          priority: -20
        },
        defaultVendors: {
          idHint: "vendors",
          reuseExistingChunk: true,
          test: /[\\/]node_modules[\\/]/i,
          priority: -10
        }
      },
    },
  },
};

这两个配置组能帮助我们：

• 将所有 node_modules 中的资源单独打包到 vendors-xxx-xx.js 命名的产物
• 对引用次数大于等于 2 的模块，也就是被多个 Chunk 引用的模块，单独打包

开发者也可以将默认分组设置为 false，关闭分组配置，例如：

module.exports = {
  //...
  optimization: {
    splitChunks: {
      cacheGroups: {
        default: false
      },
    },
  },
};

5. 配置项回顾

最后，我们再回顾一下 SplitChunksPlugin 支持的配置项：

• minChunks：用于设置引用阈值，被引用次数超过该阈值的 Module 才会进行分包处理
• maxInitialRequest/maxAsyncRequests：用于限制 Initial Chunk(或 Async Chunk) 最大并行请求数，本质上是在限制最终产生的分包数量
• minSize：超过这个尺寸的 Chunk 才会正式被分包
• maxSize：超过这个尺寸的 Chunk 会尝试继续做分包
• maxAsyncSize：与 maxSize 功能类似，但只对异步引入的模块生效
• maxInitialSize：与 maxSize 类似，但只对 entry 配置的入口模块生效
• enforceSizeThreshold：超过这个尺寸的 Chunk 会被强制分包，忽略上述其它 size 限制
• cacheGroups：用于设置缓存组规则，为不同类型的资源设置更有针对性的分包策略

6. 拆分运行时包

除了 entry、异步模块外，webpack 5之后还支持基于 runtime 的分包规则。除业务代码外，Webpack 编译产物中还需要包含一些用于支持 webpack 模块化、异步加载等特性的支撑性代码，这类代码在 webpack 中被统称为 runtime。

tip

参考：

Webpack 原理系列六： 彻底理解 Webpack 运行时

运行时代码的内容由业务代码所使用到的特性决定，例如当 Webpack 检测到业务代码中使用了异步加载能力，就会将异步加载相关的运行时注入到产物中，因此业务代码用到的特性越多，运行时就会越大，有时甚至可以超过 1M 之多。

此时，可以将 optimization.runtimeChunk 设置为 true，以此将运行时代码拆分到一个独立的 Chunk，实现分包。

Webpack 运行时代码单独打包（Webpack5 新特性，详见 Webpack Chunk 分包规则），单独打包不是目的，主要是为了设置缓存。这块代码基本上不会修改，如果还跟业务代码一起打包进去，那么每次业务代码修改，浏览器还得加载一遍 webapck runtime 的代码，浪费带宽：

module.exports = {
  entry: {
    index: { import: "./src/index", runtime: "solid-runtime" },
  }
};

7. 最佳实践

那么，如何设置最适合项目情况的分包规则呢？这个问题并没有放诸四海皆准的通用答案，因为软件系统与现实世界的复杂性，决定了很多计算机问题并没有银弹，不过我个人还是总结了几条可供参考的最佳实践：

1. 「尽量将第三方库拆为独立分包」

   例如在一个 React + Redux 项目中，可想而知应用中的大多数页面都会依赖于这两个库，那么就应该将它们从具体页面剥离，避免重复加载。

   但对于使用频率并不高的第三方库，就需要按实际情况灵活判断，例如项目中只有某个页面 A 接入了 Three.js，如果将这个库跟其它依赖打包在一起，那用户在访问其它页面的时候都需要加载 Three.js，最终效果可能反而得不偿失，这个时候可以尝试使用异步加载功能将 Three.js 独立分包

2. 「保持按路由分包，减少首屏资源负载」

   设想一个超过 10 个页面的应用，假如将这些页面代码全部打包在一起，那么用户访问其中任意一个页面都需要等待其余 9 个页面的代码全部加载完毕后才能开始运行应用，这对 TTI 等性能指标明显是不友好的，所以应该尽量保持按路由维度做异步模块加载，所幸很多知名框架如 React、Vue 对此都有很成熟的技术支持

3. 「尽量保持」 **chunks = 'all'**

   optimization.splitChunks.chunks 配置项用于设置 SplitChunksPlugin 的工作范围，我们应该尽量保持 chunks = 'all' 从而最大程度优化分包逻辑

tip

参考：

Webpack 性能系列四：分包优化