為什么有人說 vite 快,有人卻說 vite 慢?

前言

談到 Vite，給人的第一印象就是 dev server 啟動速度快。同樣規(guī)模的項目，相比 Webpack 動輒十幾秒甚至幾十秒的的啟動速度，Vite 簡直是快到沒朋友，往往數(shù)秒之內即可完成啟動(PS: 都沒有時間去喝一杯 ?? 啦)。

正好小編最近在做一些關于開發(fā)體驗的性能優(yōu)化，就想著把手上一些項目的開發(fā)模式更新為 Vite。經過一番操作，終于改造成功，而效果也不負眾望，項目啟動速度由原來的 25 s 如坐 ??一般躍升為 2 s，簡直夸張。雖然也出現(xiàn)了一些諸如首屏、懶加載性能下降等負面效果，但整體來說依然利大于弊，開發(fā)幸福感提升非常明顯。

接下來小編就通過本文給大家分析一下，具體聊一聊 Vite 的快和慢。

本文的目錄結構如下:

• Vite 的快 [1]

  • 快速的冷啟動 [2]

  • 快速的熱更新 [3]

• Vite 的慢 [4]

  • 首屏性能 [5]

  • 懶加載性能 [6]

• 結束語 [7]

Vite 的快

Vite 的快，主要體現(xiàn)在兩個方面: 快速的冷啟動和快速的熱更新。而 Vite 之所以能有如此優(yōu)秀的表現(xiàn)，完全歸功于 Vite 借助了瀏覽器對 ESM 規(guī)范的支持，采取了與 Webpack 完全不同的 unbundle 機制。

在本章節(jié)，小編將通過一個實際的項目，分別使用 Webpack 和 Vite 啟動 dev server, 給大家展示一下 Vite 的威力。

快速的冷啟動

由于是公司的內部項目，不方便將源代碼上傳到 github，所以小編只能通過 gif 動圖的方式給大家展示 Webpack 和 Vite 啟動 dev server 的過程。

• Webpack

  首先是通過 Webpack 啟動 dev server，過程如下:

  Aug-04-2022 16-59-34.gif

  一個規(guī)模不是很大的項目，dev server 啟動完成，居然花了 25 s 左右時間。如果項目持續(xù)迭代變得再大一點，那每次啟動 dev server 就是一種折磨了。

  這個問題，主要是由 Webpack 內部的核心機制 - bundle 模式引發(fā)的。

  Webpack 能大行其道，歸功于它劃時代的采用了 bundle 機制。通過這種 bundle 機制，Webpack 可以將項目中各種類型的源文件轉化供瀏覽器識別的 js、css、img 等文件，建立源文件之間的依賴關系，并將數(shù)量龐大的源文件合并為少量的幾個輸出文件。

  bundle 工作機制的核心部分分為兩塊：構建模塊依賴圖 - module graph 和將 module graph 分解為最終供瀏覽器使用的幾個輸出文件。

  構建 module graph 的過程可以簡單歸納為:

  分解 module graph 的過程也可以簡單歸納為:

  Webpack 的這種 bundle 機制，奠定了現(xiàn)代靜態(tài)打包器(如 Rollup、Parcel、Esbuild)的標準工作模式。

  然而成也蕭何敗蕭何，強大的 bundle 機制，也引發(fā)了構建速度緩慢的問題，而且項目規(guī)模越大，構建速度越是緩慢。其主要原因是構建 module graph 的過程中，涉及到大量的文件 IO、文件 transfrom、文件 parse 操作；以及分解 module graph 的過程中，需要遍歷 module graph、文件 transform、文件 IO 等。這些操作，往往需要消耗大量的時間，導致構建速度變得緩慢。

  開發(fā)模式下，dev server 需要 Webpack 完成整個工作鏈路才可以啟動成功，這就導致構建過程耗時越久，dev server 啟動越久。

  為了加快構建速度，Webpack 也做了大量的優(yōu)化，如 loader 的緩存功能、webpack5 的持久化緩存等，但這些都治標不治本，只要 Webpack 的核心工作機制不變，那 dev server 啟動優(yōu)化，依舊是一個任重道遠的過程(基本上永遠都達不到 Vite 那樣的效果)。

1. 預處理 module graph，對 module graph 做 tree shaking；
2. 遍歷 module graph，根據(jù)靜態(tài)、動態(tài)依賴關系，將 module graph 分解為 initial chunk、async chunks；
3. 優(yōu)化 initial chunk、 async chunks 中重復的 module；
4. 根據(jù) optimization.splitChunks 進行優(yōu)化，分離第三方依賴、被多個 chunk 共享的 module 到 common chunks 中；
5. 根據(jù) chunk 類型，獲取對應的 template；
6. 遍歷每個 chunk 中收集的 module，結合 template，為每個 chunk 構建最后的輸出內容；
7. 將最后的構建內容輸出到 output 指定位置；
8. 獲取配置文件中 entry 對應的 url (這個 url 一般為相對路徑);
9. resolve - 將 url 解析為絕對路徑，找到源文件在本地磁盤的位置，并構建一個 module 對象；
10. load - 讀取源文件的內容;
11. transform - 使用對應的 loader 將源文件內容轉化為瀏覽器可識別的類型；
12. parse - 將轉化后的源文件內容解析為 AST 對象，分析 AST 對象，找到源文件中的靜態(tài)依賴(import xxx from 'xxx') 和動態(tài)依賴(import('xx'))對應的 url, 并收集到 module 對象中；
13. 遍歷第 5 步收集到的靜態(tài)依賴、動態(tài)依賴對應的 url，重復 2 - 6 步驟，直到項目中所有的源文件都遍歷完成。

Vite

同樣的項目，這次換 Vite 啟動。

Aug-04-2022 17-01-37.gif

通過 gif 動圖，我們可以看到 dev server 的啟動速度僅僅需要 2s 左右，相比 Webpack 如 ?? 爬行一樣的速度，就如同坐 ??一般，開發(fā)幸福感頓時拉滿。

Vite 之所以在 dev server 啟動方面，如此給力，是因為它采取了與 Webpack 截然不同的 unbundle 機制。

unbundle 機制，顧名思義，不需要做 bundle 操作，即不需要構建、分解 module graph，源文件之間的依賴關系完全通過瀏覽器對 ESM 規(guī)范的支持來解析。這就使得 dev server 在啟動過程中只需做一些初始化的工作，剩下的完全由瀏覽器支持。這和 Webpack 的 bundle 機制一比，簡直就是降維打擊，都有點欺負人了 ??。

那有的同學就會問，源文件的 resolve、load、transform、parse 什么時候做呢 ？

答案是瀏覽器發(fā)起請求以后，dev server 端會通過 middlewares 對請求做攔截，然后對源文件做 resolve、load、transform、parse 操作，然后再將轉換以后的內容發(fā)送給瀏覽器。

這樣，通過 unbundle 機制， Vite 便可以在 dev server 啟動方面獲取遠超于 Webpack 的優(yōu)秀體驗。

最后再總結一下， unbundle 機制的核心:

• 模塊之間的依賴關系的解析由瀏覽器實現(xiàn)；
• 文件的轉換由 dev server 的 middlewares 實現(xiàn)并做緩存；
• 不對源文件做合并捆綁操作；

快速的熱更新

除了 dev server 啟動外， Vite 在熱更新方面也有非常優(yōu)秀的表現(xiàn)。

我們還是通過同一個項目，對 Webpack 和 Vite 的熱更新做一下比較。

Webpack

首先是 Webpack 在熱更新方面的表現(xiàn)。

觀察 gif 動圖，修改源文件以后，Webpack 發(fā)生耗時大概 5 s 的重新編譯打包過程。

dev server 啟動以后，會 watch 源文件的變化。當源文件發(fā)生變化后，Webpack 會重新編譯打包。這個時候，由于我們只修改了一個文件，因此只需要對這個源文件做 resolve、 load、 transfrom、parse 操作，依賴的文件直接使用緩存，因此 dev server 的響應速度比冷啟動要好很多。

dev server 重新編譯打包以后，會通過 ws 連接通知瀏覽器去獲取新的打包文件，然后對頁面做局部更新。

Vite

再來看看 Vite 在熱更新方面的表現(xiàn)。

觀察 gif 動圖，可以發(fā)現(xiàn) Vite 在熱更新方面也是碾壓 Webpack。

由于 Vite 采用 unbundle 機制，所以 dev server 在監(jiān)聽到文件發(fā)生變化以后，只需要通過 ws 連接通知瀏覽器去重新加載變化的文件，剩下的工作就交給瀏覽器去做了。(忍不住要給 Vite 點個 ???? 了。)

綜上， Vite 在 dev server 冷啟動和熱更新方面，對 Webpack 的優(yōu)勢實在是太明顯了，難怪會受到大家的青睞。

Vite 的慢

和 bundle 機制有利有弊一樣，unbundle 機制給 Vite 在 dev server 方面獲得巨大性能提升的同時，也帶來一些負面影響，那就是首屏和懶加載性能的下降。

在本章節(jié)，小編還是通過相同的項目為大家一一展示。

首屏性能

我們先來對比一下 Webpack 和 Vite 在首屏方面的表現(xiàn)。

• Webpack

  Webpack 的首屏 gif 動圖如下:

  Aug-05-2022 16-13-03.gif

  瀏覽器向 dev server 發(fā)起請求， dev server 接受到請求，然后將已經打包構建好的首屏內容發(fā)送給瀏覽器。整個過程非常普遍，沒有什么可說的，不存在什么性能問題。

• Vite

  相比 Webpack， Vite 在首屏方面的表現(xiàn)就有些差了。

  Aug-05-2022 16-17-28.gif

  通過 gif 動圖，我們可以很明顯的看到首屏需要較長的時間才能完全顯示。

  由于 unbundle 機制，首屏期間需要額外做以下工作:

  和 Webpack 對比，Vite 把需要在 dev server 啟動過程中完成的工作，轉移到了 dev server 響應瀏覽器請求的過程中，不可避免的導致首屏性能下降。

  不過首屏性能差只發(fā)生在 dev server 啟動以后第一次加載頁面時發(fā)生。之后再 reload 頁面時，首屏性能會好很多。原因是 dev server 會將之前已經完成轉換的內容緩存起來。

  • 不對源文件做合并捆綁操作，導致大量的 http 請求；
  • dev server 運行期間對源文件做 resolve、load、transform、parse 操作；
  • 預構建、二次預構建操作也會阻塞首屏請求，直到預構建完成為止；

懶加載性能

Webpack

在懶加載方面， Webpack 的表現(xiàn)也正常，沒什么好說的。

Aug-05-2022 16-13-51.gif

Vite

同樣的， Vite 在懶加載方面的性能也比 Webpack 差。

和首屏一樣，由于 unbundle 機制，動態(tài)加載的文件，需要做 resolve、load、transform、parse 操作，并且還有大量的 http 請求，導致懶加載性能也受到影響。

此外，如果懶加載過程中，發(fā)生了二次預構建，頁面會 reload，對開發(fā)體驗也有一定程度的影響。

結束語

盡管在首屏、懶加載性能方面存在一些不足，但瑕不掩瑜，作為目前最 ?? 的構建工具，Vite 可以說是實至名歸。而且這些問題并非不可解決，比如我們可以通過 prefetch、持久化緩存等手段做優(yōu)化，相信 Vite 未來也會做出對應的改進。

總的來說， Vite 還是未來可期的，還沒有開始使用的小伙伴，可以去嘗試一下噢，??。

作者：0o華仔o0

https://juejin.cn/post/7129041114174062628

祝 您:2022 年暴富！萬事如意！

點贊和在看就是最大的支持,比心??