「 不懂就問 」為什么 Webpack 這么慢 ？
背景
上一篇文章我們分析了：為什么 esbuild 這么快
還有數(shù)據(jù)對比：
可以明顯看到：esbuild 一騎絕塵, 以絕對優(yōu)勢領(lǐng)先。
看看最下面, 赫然是我們最熟悉的 webpack。
那么, webpack 的構(gòu)建為什么慢呢?到底慢在哪呢 ?
下面是我的一些思考，分享給大家，希望對大家有所幫助。
正文
首先我們先看一下 webpack 構(gòu)建的大致流程:
webpack build flow
流程走的比較長。
那么，整個流程的性能瓶頸在哪里呢?
我認為主要是在以下兩個階段：
- 代碼構(gòu)建
- 代碼壓縮
圖片
https://www.quora.com/What-is-Webpack-and-babel-loader
我們分別來看。
1. 代碼構(gòu)建
代碼構(gòu)建階段， 需要做的一個很重要的事情是模塊依賴分析, 生成Module Graph。
這部分有十分復(fù)雜的流程。
webpack build graph
https://medium.com/webpack/the-chunk-graph-algorithm-week-26-29-7c88aa5e4b4e
這部分非常復(fù)雜，也比較耗時。
為此 webpack 也設(shè)計了對應(yīng)的的算法去優(yōu)化這部分，感興趣的可以去研究一下。
這部分的詳細解析，有個視頻講的不錯，感興趣的可以去看一下：
https://youtu.be/Lzh8A0p3z8g
說回構(gòu)建。
現(xiàn)代瀏覽器對 esm 支持的越來越好，模塊依賴分析的工作，瀏覽器就能完成。
而且, 瀏覽器的很多包分析工具是用C/C++寫的, 顯然是要比 webpack 使用 js 去分析整個依賴圖譜更具優(yōu)勢，速度上也是要快很多的。
2. 代碼壓縮
目前最成熟的 js 壓縮工具是 UglifyJS。
它會分析 js 的代碼語法樹， 理解代碼含義，從而能做到諸如: 去掉無效代碼，去掉日志輸出代碼，縮短變量名等優(yōu)化。
webpack 使用壓縮插件來完成這部分工作。
其中: webpack 使用的 terser, 是用 js 寫的， 源自于最早的 uglyfy.js , 功能很豐富， 但是速度非常非常慢。
這點， 也是 webpack 速度慢的原因之一。
不過在代碼壓縮方面， vite 選擇的也是Terser。
對此，文檔中有相關(guān)描述：
- build.minify:
- 類型：boolean | 'terser' | 'esbuild'
- 默認：'terser'
設(shè)置為 false 可以禁用最小化混淆，或是用來指定使用哪種混淆器。
默認為 Terser。
雖然 Terser 相對較慢，但大多數(shù)情況下構(gòu)建后的文件體積更小。
ESbuild 最小化混淆更快, 但構(gòu)建后的文件相對更大。
更多信息可以參考：https://cn.vitejs.dev/config/#build-minify
另外，如果你有留意， 就會發(fā)現(xiàn)一個現(xiàn)象:
- Esbuild, 使用 GO 寫的。
- SWC， 是用 Rust 寫的。
都不是用js寫的。
未來前端的編譯工具，大概也會往這個方向走, 要么用 Go 寫, 要么用 Rust 寫，而不是把這種能形成性能瓶頸的東西用 js 來實現(xiàn)。
還有一點需要提一下。
在文章開頭的圖中， 看起來 webpack5 的速度比 webpack4 要慢:
但這不代表 webpack 5 不好，大家不要誤會啊。
webpack 5 里面 做了大量的優(yōu)化， 甩掉了不少歷史包袱。
有一些新特性還有非常有用的, 比如：
- Module Federation
- Real Content Hash
不難想到，webpack 團隊還是做出了很多努力的， ?? 。
總結(jié)
這篇文章， 是半夜突然有了思路， 花了兩個小時寫出來。
本文轉(zhuǎn)載自微信公眾號「前端皮小蛋」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系前端皮小蛋公眾號。
