快捷導(dǎo)航

Vite性能優(yōu)化之分包策略的實(shí)現(xiàn)

更新時(shí)間：2023年05月08日 14:29:33 作者：拾荒草

本文主要介紹了Vite性能優(yōu)化之分包策略的實(shí)現(xiàn)，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

為什么需要分包策略？

還是舉個(gè)例子，來回憶一下吧，什么呢？
比如說，我使用了 loadsh.js 的東西，那么我們?cè)诖虬臅r(shí)候，就會(huì)把 loadsh 相關(guān)資源也會(huì)打包進(jìn)來，這個(gè)是沒有問題的，此時(shí)是將 loadsh 的東西與我們自己寫的相關(guān)代碼合成一個(gè)文件，記住是一個(gè)文件。
瀏覽器是有緩存機(jī)制的，當(dāng)每一次去請(qǐng)求的文件資源時(shí) ( 文件名是沒有發(fā)生改變的時(shí)候，就會(huì)讀取內(nèi)存中的數(shù)據(jù)，而不會(huì)重新去服務(wù)器獲取 )。
分包，我的理解，就是將第三方資源文件單獨(dú)打成一個(gè)文件，自己寫的代碼打成另一個(gè)文件

如果我們不進(jìn)行分包
我們每一次修改代碼之后，進(jìn)行打包，結(jié)果這個(gè)文件的內(nèi)容有：第三方資源包代碼 + 我們自己寫的業(yè)務(wù)代碼。
而且，這個(gè)文件的名字，每一次都會(huì)發(fā)生變化的(源代碼發(fā)生變化)，所以當(dāng)用戶去訪問我們的頁面時(shí)，請(qǐng)求的資源文件內(nèi)容有 : 第三方資源包代碼 + 自己的業(yè)務(wù)代碼，而真正需要跟新的只有自己的業(yè)務(wù)代碼，導(dǎo)致每一次，請(qǐng)求的js文件體積都很大，所以響應(yīng)時(shí)間會(huì)長(zhǎng)一些

瀏覽器的緩存策略

瀏覽器在請(qǐng)求靜態(tài)資源時(shí)，只要靜態(tài)資源的名稱不變，它就不會(huì)重新請(qǐng)求 xxx.js資源。

使用Vite打包后的js文件是帶有哈希值的，只要我們的代碼內(nèi)容有一點(diǎn)點(diǎn)變化，那么文件的hash值都會(huì)變化。

我們初始化一個(gè)項(xiàng)目，安裝vite進(jìn)行演示

npm init -y
npm i vite -D

// main.js中寫一點(diǎn)邏輯
const mainArr = []

打包

更改main.js中的邏輯然后重新打包

// 更改main.js中的邏輯
let mainArr = []

可見，項(xiàng)目中任何業(yè)務(wù)代碼更改后，文件的hash值都會(huì)改變，重新部署代碼后，瀏覽器都會(huì)重新請(qǐng)求資源文件。

基于這種策略，服務(wù)器往往存在不必要的性能浪費(fèi)。

瀏覽器緩存策略的不足

假設(shè)我們的項(xiàng)目修改了一點(diǎn)點(diǎn)業(yè)務(wù)邏輯，每次打包發(fā)布后，由于打包的文件名發(fā)生了改變，瀏覽器都會(huì)重新請(qǐng)求這個(gè)js文件。

看個(gè)示例：

我們引入lodash，然后main.js中寫入一點(diǎn)邏輯。

import { forEach } from "lodash"
const mainArr = []
forEach(mainArr,(ele) => {
  console.log('ele: ', ele);
})

打包

main.js中修改了一點(diǎn)點(diǎn)內(nèi)容，重新打包

注：為了展示源碼，這里關(guān)閉了打包時(shí)的代碼壓縮。vite.config.js中配置build:{minify:false}

通過這個(gè)示例我們可以發(fā)現(xiàn)個(gè)問題，我們引入了lodash，雖然它的內(nèi)容始終沒有變（大概有5481行的代碼），但是隨著業(yè)務(wù)代碼的一點(diǎn)點(diǎn)修改，它都會(huì)和業(yè)務(wù)代碼打包在一起，被瀏覽器重新請(qǐng)求。

這是浪費(fèi)性能的，lodash完全沒有必要被重新請(qǐng)求。如果我們將lodash和業(yè)務(wù)代碼打包成兩個(gè)獨(dú)立的js文件，就可以完美解決這個(gè)問題。這就是分包策略。

分包策略就是把一些不會(huì)經(jīng)常更新的文件，進(jìn)行單獨(dú)打包處理。

分包策略的實(shí)現(xiàn)

vite中實(shí)現(xiàn)分包策略，實(shí)際是靠配置rollup的打包配置完成的。

// vite.config.js
import { defineConfig } from "vite";
export default defineConfig({
  build:{
    // 在這里配置打包時(shí)的rollup配置
    rollupOptions:{
    }
  }
});

rollup的output.manualChunks這一配置可以實(shí)現(xiàn)分包策略，具體內(nèi)容可以查看官網(wǎng):

https://www.rollupjs.com/guide/big-list-of-options

output.manualChunks

官方注解：

當(dāng)該選項(xiàng)值為函數(shù)形式時(shí)，每個(gè)被解析的模塊都會(huì)經(jīng)過該函數(shù)處理。如果函數(shù)返回字符串，那么該模塊及其所有依賴將被添加到以返回字符串命名的自定義 chunk 中。例如，以下例子會(huì)創(chuàng)建一個(gè)命名為 vendor 的 chunk，它包含所有在 node_modules 中的依賴。

manualChunks(id) {
  if (id.includes('node_modules')) {
    return 'vendor';
  }
}

我們打印一下manualChunks函數(shù)的參數(shù)

import { defineConfig } from "vite";
export default defineConfig({
  build:{
    minify:false,
    // 在這里配置打包時(shí)的rollup配置
    rollupOptions:{
      manualChunks:(id) => {
        console.log("id-------------",id);
      }
    }
  }
});

可以看出，id對(duì)應(yīng)的就是所有需要打包整合的文件，如果id包含node_modules，一定不是我們的業(yè)務(wù)代碼，根據(jù)官方釋義，我們可以將包含node_modules的文件打包在一起

import { defineConfig } from "vite";
export default defineConfig({
  build:{
    minify:false,
    // 在這里配置打包時(shí)的rollup配置
    rollupOptions:{
      manualChunks:(id) => {
        if (id.includes('node_modules')) {
          return 'vendor';
        }
      }
    }
  }
});

重新打包后，可以發(fā)現(xiàn)分包策略已經(jīng)實(shí)現(xiàn)了。