webpack4 之 cacheGroups 分包【究极奥义】

掘金安东尼 2021-01-20 webpack

本文首发于：掘金 (opens new window)，欢迎三连~

# 序

近来遇项目打包之事，撰文记之。以期分享，皆有所获。

# 前提

前提有两点，需要得到你的认同：

【后台管理系统】框架和 UI 组件库最强组合为 vue-element-admin + Element UI！(●'◡'●)
webpack4 最核心的特性是【splitChunks】，splitChunks 最核心的配置是 cacheGroups！

基于这个两个前提，我们再进行下一步。

# 分析工具

webpack 打包分析有它就够了：webpack-bundle-analyzer (opens new window)

安装

npm install --save-dev webpack-bundle-analyzer

配置：因为 vue-element-admin 基于 vueCli4，所以在 vue.config.js chainWebpack 中设置

 config.plugin('BundleAnalyzerPlugin').use(BundleAnalyzerPlugin).tap(() => [
      {
        rel: 'BundleAnalyzerPlugin',
        analyzerMode: 'server', // 'server': 启动端口服务；'static': 生成 report.html；'disabled': 配合 generateStatsFile 使用；
        generateStatsFile: false, // 是否生成stats.json文件
        analyzerHost: '127.0.0.1',
        analyzerPort: '8877',
        reportFilename: 'report.html',
        defaultSizes: 'parsed',
        openAnalyzer: false,
        statsFilename: 'stats.json',
        statsOptions: null,
        excludeAssets: null
      }

1
2
3
4
5
6
7
8
9
10
11
12
13
14

其中 analyzerMode 的设置比较重要。

运行：

npm run dev 或 npm run build

访问：

http://127.0.0.1:8877

# 现状问题

看一下咱们的打包分析图：

得出如上图的分包并不难，vue-element-admin 自带这些配置。

config.optimization.splitChunks({
        chunks: 'all',
        cacheGroups: {
          libs: {
            name: 'chunk-libs',
            test: /[\\/]node_modules[\\/]/,
            priority: 10,
            chunks: 'initial' // only package third parties that are initially dependent
          },
          elementUI: {
            name: 'chunk-elementUI', // split elementUI into a single package
            priority: 20, // the weight needs to be larger than libs and app or it will be packaged into libs or app
            test: /[\\/]node_modules[\\/]_?element-ui(.*)/ // in order to adapt to cnpm
          },
          commons: {
            name: 'chunk-commons',
            test: resolve('src/components'), // can customize your rules
            minChunks: 3, //  minimum common number
            priority: 5,
            reuseExistingChunk: true
          }
        }
      })

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

如果你暂时还看不懂这些配置项，先别急，后面会一一陈述。

你只用先知道：它拆了初始化加载的第三方包、拆了 Element UI 库、拆了 src/components。

一切似乎好像还不错，但是我们并不满足。

实际上，咱们跑一下 npm run build:test 也会报警告。

那么还有哪些点可以继续优化？结合以上分析图和 test warning，很明显，我们需要思考：

Echarts 的体积大小不能忽视，如何处理它？是首页加载还是异步加载？要按需引入吗？
vue.js 等库还能不能再拆？
首页 Entrypoints 所依赖的包还能不能再优化？
包的体积应控制在什么范围？包太大，加载会太慢！包太小，会消耗 HTTP 请求连接！更多：合并 HTTP 请求是否真的有意义？ (opens new window)
更多......

淦！打包什么的，多打几遍就完事了。十遍不行就一百遍，一百遍不行就一千遍，一千遍不行就......

# 优化的结果

淦完后得出如下打包分析图：

本瓜成功的将打包大小从 3.1MB 变成了 2.36MB，文件数从 68个 打包到了 43个 ！！！，既实现了拆包（拆公共库），也实现了并包（合并极小的包）。

虽然这不会是最终的结果，但本瓜可以先下一个结论：

配置 cacheGroups，权衡拆包与并包二者，便是 webpack 分包的究极奥义！

以下是 cacheGroups 配置：

 config.optimization.splitChunks({
        chunks: 'all',
         cacheGroups: {
            vue: {
              name: 'chunk-vuejs',
              test: /[\\/]node_modules[\\/]_?vue(.*)/,
              priority: 20
            },
            elementUI: {
              name: 'chunk-elementUI', // split elementUI into a single package
              priority: 30, // the weight needs to be larger than libs and app or it will be packaged into libs or app
              test: /[\\/]node_modules[\\/]_?element-ui(.*)/ // in order to adapt to cnpm
            },
            commons: { // split async commons chunk
              name: 'chunk-async-commons',
              minChunks: 2,
              priority: 40,
              chunks: 'async'
            },
            echarts: { // split echarts libs
              name: 'chunk-echarts',
              test: /[\\/]node_modules[\\/]_?echarts(.*)/,
              priority: 50,
              chunks: 'async'
            },
            zrender: { // split zrender libs
              name: 'chunk-zrender',
              test: /[\\/]node_modules[\\/]_?zrender(.*)/,
              priority: 55,
              chunks: 'async'
            },
            'manage-sendMsg': { // resolve src
              name: 'chunk-manage-sendMsg',
              test: resolve('src/views/manage/sendMsg'),
              priority: 80,
              chunks: 'async'
            },
            'manage-packageLink': { // resolve src
              name: 'chunk-manage-packageLink',
              test: resolve('src/views/manage/packageLink'),
              priority: 80,
              chunks: 'async'
            }，
            ......
      })

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

其实咱单独从配置上去做优化，可操作的空间并不大。我们还应该从打包分析结果去回看我们的代码细节，调整业务代码来优化打包结果，或许是最直接有效的优化思路之一。包括：如何整合或解耦业务？如何做组件化？组件怎么引？插件怎么引？引多少？......每个点都能再操作操作！

尤其注意

CommonJs(require)	ES6(import)
输出的是一个值的拷贝	输出的是值的引用
运行时加载	编译时输出接口

# cacheGroups

下面我们再具体看看 cacheGroups 最关键的配置：

【重要】

name chunk 的文件名
test 过滤 modules，默认为所有的 modules，可匹配模块路径或 chunk 名字，当匹配到某个 chunk 的名字时，这个 chunk 里面引入的所有 module 都会选中；
priority 权重，数字越大表示优先级越高。一个 module 可能会满足多个 cacheGroups 的正则匹配，到底将哪个缓存组应用于这个 module，取决于优先级；
chunks（非常非常非常重要）有三个值：all、async、initial。

这里是一段示例代码，来看看设置不同的 chunks，它们有什么样的打包区别：

//app.js
import "my-statis-module";

if(some_condition_is_true){
  import ("my-dynamic-module")
}
console.log("My app is running")

1
2
3
4
5
6
7

asyn : (default)

会生成两个打包文件：

bundle.js (包含 app.js + my-statis-module)
chunk.js (只包含 my-dynamic-module)

initial :

会生成三个打包文件：

app.js (只包含 app.js)
bundle.js (只包含 my-static-module)
chunk.js (只包含 my-dynamic-module)

all :

会生成两个打包文件：

app.js (只包含 app.js)
bundle.js (包含 my-static-module + my-dynamic-module)

设置 "all" 大小将最小，区别使用这三者，是核心中的核心。

【了解】

minSize 表示被拆分出的 bundle 在拆分之前的体积的最小数值，只有 >= minSize 的 bundle 会被拆分出来；
maxSize

表示被拆分出的 bundle 在拆分之前的体积的最大数值，默认值为 0，表示 bundle 在拆分前的体积没有上限；maxSize 如果为非 0 值时，不能小于 minSize；

minChunks 表示在分割前，可被多少个chunk分享的最小值
reuseExistingChunk 表示是否使用已有的 chunk，true 则表示如果当前的 chunk 包含的模块已经被抽取出去了，那么将不会重新生成新的，即几个 chunk 复用被拆分出去的一个 module；

# 意外收获

代码层面：这样写，user.png 会被单独打成一个包。打包出来 148B ，属实没必要！

<img v-show="imageUrl" :src="imageUrl" class="sort-img">
<img v-show="!imageUrl" src="~@/assets/user.png" class="sort-img">

1
2

如果改成这样，则不会再被单独打包了。

 <img :src="imageUrl?imageUrl:'~@/assets/user.png'" class="sort-img">

回看其它代码，本瓜发现所有在条件判断里面引入的文件都会被单独打包。然而它们其中有些是可以调整写法的，真没必要将几 KB 的文件单独打包成一个几 B 的包文件。

从打包的结果去检验代码，也是一种不错的优化手段！

# 策略小结

基于本次分包，本瓜简单梳理一下策略：

公共的库是一定要尽量拆的。
公共的库尽量做到按需加载，这也是优化首屏加载需要注意的。
分包不能太细，0KB 至 10 KB 的包是极小的包，应当考虑合并。10 KB 至 100 KB 的包是小包，比较合适；100 KB 至 200 KB 的包只能是比较核心重要的包，需要重点关注，大于 200KB 的包就需要考虑拆包了。当然，也不排除一些特殊情况。

包大小	策略
0 KB 至 10 KB	合并包
10 KB 至 100 KB	大小合适
100 KB 至 200 KB	核心包，重点关注
大于 200 KB	考虑拆包
特殊情况	特殊处理

本次就先到这，打包无止境，愿这个世上没有打包攻城狮。

关注公众号【掘金安东尼】，你的三连，我的动力！！！

Last Updated: 1/21/2021, 9:39:20 AM