webpack中splitChunks分包策略的實現(xiàn)

更新時間：2024年06月28日 09:05:20 作者：Lsx_codeShare

splitChunks是 webpack 中用于分包的配置選項之一,本文主要介紹了webpack中splitChunks分包策略的實現(xiàn),具有一定的參考價值,感興趣的可以了解一下

一、為什么需要拆包

隨著應用程序規(guī)模的增長，JavaScript 文件的大小也越來越大。一個大的 JavaScript 文件會導致頁面加載時間過長，影響用戶體驗。良好的拆包策略可以將一個大的 JavaScript 文件分割成多個較小的代碼塊，將公用的代碼抽離成單獨的 chunk，在需要的時候按需加載，并充分利用瀏覽器的緩存機制，如果使用合理，會極大影響加載時間。

二、拆包方式

入口起點（entry ）
通過使用入口起點的方式，可以將代碼分離成多個單獨的文件，這些文件可以通過 webpack 配置一個數(shù)組結(jié)構的 entry 選項指定。并且在其中傳入不同類型的文件，可以實現(xiàn)將 CSS 和 JavaScript（和其他）文件分離在不同的 bundle。但是，這種方式有一些缺點，如無法動態(tài)加載，無法共享模塊等。

代碼分離（Code Splitting）
代碼分離指將代碼分成不同的包/塊，然后可以按需加載，而不是加載包含所有內(nèi)容的單個包。用戶只需要下載當前他正在瀏覽站點的這部分代碼，代碼分離可以使用ES6模塊中的 import() 函數(shù)動態(tài)的加載模塊。使用動態(tài)導入的模塊會被分割到一個單獨的 chunk 中。

打包分離（Bundle Splitting）
webpack 為單個應用程序生成多個 bundle 文件。如果你有一個體積巨大的文件，并且只改了一行代碼，用戶仍然需要重新下載整個文件。但是如果你把它分為了兩個文件，那么用戶只需要下載那個被修改的文件，而另一個文件瀏覽器可以從緩存中加載，從而減少重新發(fā)布并由此被客戶端重新下載的代碼量。

綜上所述，合理的拆包策略可以顯著提升應用程序的性能。代碼分離通過將代碼按需加載，減小初始下載量；而打包分離將應用程序拆分成多個塊，實現(xiàn)增量更新，減少不必要的下載。根據(jù)具體場景和需求，選擇合適的拆包方式可以最大程度地優(yōu)化應用程序的加載性能。

三、splitChunks介紹

splitChunks 將滿足拆分規(guī)則的構建內(nèi)容抽出來單獨打包，從而達到抽離公共模塊，減少重復打包的目的。splitChunks 中的配置項用來確定具體的拆分規(guī)則，其中的 cacheGroups 配置項必須同時滿足其下的所有條件才能生效。

webpack5 中 splictChunks 的默認配置為：

module.exports = {
  optimization: {
    splitChunks: {
      chunks: 'async',
      // 生成的 chunk 的最小體積，單位為字節(jié)（bytes）。內(nèi)容超過了minSize的值，才會進行打包
      minSize: 20000,
      minRemainingSize: 0,
      // 在拆分之前，必須共享的模塊的最小 chunk 數(shù)。
      minChunks: 1,
      // 在按需加載時，允許的最大并行請求數(shù)。
      maxAsyncRequests: 30,
      // 入口點允許的最大并行請求數(shù)。
      maxInitialRequests: 30,
      // 超過這個值就會進行強制分包處理，無視minRemainingSize,maxAsyncRequests，maxInitialRequests
      enforceSizeThreshold: 50000,
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          priority: -10,
          // 如果當前 chunk 包含已從主 bundle 中拆分出的模塊，則它將被重用，而不是生成新的模塊
          reuseExistingChunk: true,
        },
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
      },
    },
  },
};

其中chunks屬性可配置值有 all、 async 、 initial ，默認值是 async

async : 異步加載進來的包才會校驗分包規(guī)則，進行分包抽離。如果動態(tài)加載的包也同時引用了其它包且命中分包規(guī)則也會被抽離出來。
initial : 表示只從入口模塊進行拆分。
all : 表示入口模塊和異步加載的模塊都要進行拆分。

四、splitChunks 拆包策略

split-by-experience: 根據(jù)經(jīng)驗制定的拆分策略，自動將一些常用的 npm 包拆分為體積適中的 chunk。適用于大多數(shù)項目。
如下示例，react、antd 會被包拆分到了單獨的chunk，其余三方包會在vendorjs。其余的包也可以配置緩存組。如果拆分力度比較細的話還是需要寫上一些緩存組的。

splitChunks: {
          // chunks、minSize、minChunks 將對所有緩存組生效
          chunks: 'all', // 對所有的chunk進行拆分 
          minSize: 20000, // 拆分 chunk 的最小體積 20000 bytes
          minChunks: 2, // 需在兩個模塊中共享才進行拆分
          cacheGroups: {
            vendor: {
              name: 'vendor', // chunk 的名稱 vendor
              test: /[\\/]node_modules[\\/]/i,    // 匹配node_modules下所有的chunk
              priority: 10,    // 優(yōu)先級10 優(yōu)先將node_modules下的chunk拆分到vendor組
              reuseExistingChunk: true, // 重用模塊，而不是重新生成
              enforce: true, // 強制拆分
            },
            default: {    // 默認組 非node_modules下的文件塊 將執(zhí)行default緩存組規(guī)則
              reuseExistingChunk: true,
              priority: -10, // 優(yōu)先級 -10 
              enforce: true, // 強制拆分
            },
            react: { // react組
              name: 'react',
              test: /[\\/]node_modules[\\/]react[\\/]/,    // 匹配node_modules下的react庫
              priority: 20,    // 優(yōu)先級20 優(yōu)先將node_modules下的react拆分出去
              minChunks: 2,
              reuseExistingChunk: true,
            },
            antd: {    // antd組
              name: 'antd',
              test: /[\\/]node_modules[\\/]antd[\\/]/,    // 匹配node_modules下的antd庫
              priority: 20,    // 優(yōu)先級20 優(yōu)先將node_modules下的antd拆分出去
              minChunks: 2,
              reuseExistingChunk: true, // 重用模塊，而不是重新生成
            },
          }
        }

split-by-module: 按 NPM 包的粒度拆分，每個 NPM 包對應一個 chunk。

假如應用程序添加或升級了某個 npm 包，那么 vendor.js 的哈希值將會發(fā)生改變，這意味著用戶在訪問頁面時需要重新下載 vendor.js文件。這個時候如果對antd進行了升級或新增/刪除了一個antd組件，那么用戶不需要重新下載vendor.js文件，而只需要下載antd模塊對應的chunk。因為每個chunk都有一個獨立的哈希值，當我們對單獨的chunk進行修改時，只會影響到對應的chunk文件，而不會影響其他chunk文件。這樣就實現(xiàn)了對npm包的增量更新。

這種情況下如果npm包比較多的情況下，會產(chǎn)生高并發(fā)請求。對于支持http2的瀏覽器是沒有問題的。但是瀏覽器并不支持http2的話，也就是http1.1會存在對頭阻塞的問題。不過http2兼容性挺好的

splitChunks: {
          chunks: 'all',
          enforceSizeThreshold: 50000,
          cacheGroups: {
            vendors: {
              priority: -10,
              test: /[\\/]node_modules[\\/]/,
              name(module2) {
                return module2.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)?.[1];
              },
            },
          },
          minSize: 0,
          maxInitialRequests: Infinity,
        },

single-vendor: 將所有 NPM 包的代碼打包到一個單獨的 chunk 中。

這種情況的話，只要三方包有改動，文件hash就會改變。如果頻繁改動npm包的話，瀏覽器緩存效率相對較低

vendor: {
              name: 'vendor', // chunk 的名稱 vendor
              test: /[\\/]node_modules[\\/]/i,    // 匹配node_modules下所有的chunk
              priority: 10,    // 優(yōu)先級10 優(yōu)先將node_modules下的chunk拆分到vendor組
              reuseExistingChunk: true, // 重用模塊，而不是重新生成
              enforce: true, // 強制拆分
    },

split-by-size：根據(jù)模塊大小自動進行拆分。

符合大小范圍內(nèi)的包就會被拆出來

splitChunks: {
      chunks: 'all',
      minSize: 20000, // 20 KB
      maxSize: 50000, // 50 KB
      cacheGroups: {
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true,
        },
      },
    },