「 不懂就問 」爲何 webpack 這麼慢 ？

背景

上一篇文章咱們分析了：爲何 esbuild 這麼快。

還有數據對比：

能夠看到： esbuild 一騎絕塵, 以絕對優點領先。

可是看看最下面, 赫然是咱們最熟悉的 webpack。

那麼, webpack 的構建爲何慢呢？ 到底慢在哪呢 ？

下面是個人一些思考，分享給你們，但願對你們有所幫助。

正文

首先咱們先看一下 webpack 構建的大體流程:

流程走的比較長。

那麼，整個流程的性能瓶頸在哪裏呢？

我認爲主要是在如下兩個階段：

1. 代碼構建
2. 代碼壓縮

咱們分別來看。

1. 代碼構建

代碼構建階段， 須要作的一個很重要的事情是模塊依賴分析, 生成Module Graph。

這部分有十分複雜的流程。

這部分很是複雜，也比較耗時。

爲此 webpack 也設計了對應的的算法去優化這部分，感興趣的能夠去研究一下。

這部分的詳細解析，有個視頻講的不錯，感興趣的能夠去看一下：

說回構建。

現代瀏覽器對 esm 支持的愈來愈好，模塊依賴分析的工做，瀏覽器就能完成。

並且, 瀏覽器的不少包分析工具是用C/C++寫的, 顯然是要比 webpack 使用 js 去分析整個依賴圖譜更具優點，速度上也是要快不少的。

2. 代碼壓縮

目前最成熟的 js 壓縮工具是 UglifyJS。

它會分析 js 的代碼語法樹， 理解代碼含義，從而能作到諸如: 去掉無效代碼，去掉日誌輸出代碼，縮短變量名等優化。

webpack 使用壓縮插件來完成這部分工做。

其中: webpack 使用的 terser, 是用 js 寫的， 源自於最先的 uglyfy.js , 功能很豐富， 可是速度很是很是慢。

這點， 也是 webpack 速度慢的緣由之一。

不過在代碼壓縮方面， vite 選擇的也是Terser。

對此，文檔中有相關描述：

• build.minify:

  • 類型： boolean | 'terser' | 'esbuild'
  • 默認： 'terser'

設置爲 false 能夠禁用最小化混淆，或是用來指定使用哪一種混淆器。

默認爲 Terser。

雖然 Terser 相對較慢，但大多數狀況下構建後的文件體積更小。

ESbuild 最小化混淆更快, 但構建後的文件相對更大。

更多信息能夠參考：
https://cn.vitejs.dev/config/...

另外，若是你有留意， 就會發現一個現象:

1. Esbuild, 使用 GO 寫的。
2. SWC， 是用 Rust 寫的。

都不是用js寫的。

將來前端的編譯工具，大概也會往這個方向走, 要麼用 Go 寫, 要麼用 Rust 寫，而不是把這種能造成性能瓶頸的東西用 js 來實現。

還有一點須要提一下。

在文章開頭的圖中， 看起來 webpack5 的速度比 webpack4 要慢:

但這不表明 webpack 5 很差，你們不要誤會啊。

webpack 5 裏面 作了大量的優化， 甩掉了很多歷史包袱。

有一些新特性還有很是有用的, 好比：

• Module Federation
• Real Content Hash

不難想到，webpack 團隊仍是作出了不少努力的， ❤️ 。

總結

這篇文章， 是半夜忽然有了思路， 花了兩個小時寫出來。

但願對你們有所啓發， 謝謝。