背景

上一篇文章我們分析了：為什么 esbuild 這么快

還有數(shù)據(jù)對比：

可以明顯看到：esbuild 一騎絕塵, 以絕對優(yōu)勢領(lǐng)先。

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

那么, webpack 的構(gòu)建為什么慢呢？到底慢在哪呢 ？

下面是我的一些思考，分享給大家，希望對大家有所幫助。

正文

首先我們先看一下 webpack 構(gòu)建的大致流程:

流程走的比較長。

那么，整個流程的性能瓶頸在哪里呢？

我認(rèn)為主要是在以下兩個階段：

1. 代碼構(gòu)建
2. 代碼壓縮

我們分別來看。

1. 代碼構(gòu)建

代碼構(gòu)建階段， 需要做的一個很重要的事情是模塊依賴分析, 生成Module Graph。

這部分有十分復(fù)雜的流程。

這部分非常復(fù)雜，也比較耗時。

為此 webpack 也設(shè)計了對應(yīng)的的算法去優(yōu)化這部分，感興趣的可以去研究一下。

這部分的詳細(xì)解析，有個視頻講的不錯，感興趣的可以去看一下：

說回構(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'
• 默認(rèn)：'terser'

設(shè)置為 false 可以禁用最小化混淆，或是用來指定使用哪種混淆器。

默認(rèn)為 Terser。

雖然 Terser 相對較慢，但大多數(shù)情況下構(gòu)建后的文件體積更小。

ESbuild 最小化混淆更快, 但構(gòu)建后的文件相對更大。

更多信息可以參考：https://cn.vitejs.dev/config/#build-minify

另外，如果你有留意， 就會發(fā)現(xiàn)一個現(xiàn)象:

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

都不是用js寫的。

未來前端的編譯工具，大概也會往這個方向走, 要么用 Go 寫, 要么用 Rust 寫，而不是把這種能形成性能瓶頸的東西用 js 來實現(xiàn)。

還有一點需要提一下。

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

但這不代表 webpack 5 不好，大家不要誤會啊。

webpack 5 里面 做了大量的優(yōu)化， 甩掉了不少歷史包袱。

有一些新特性還有非常有用的, 比如：

• Module Federation
• Real Content Hash

不難想到，webpack 團(tuán)隊還是做出了很多努力的， ?? 。

總結(jié)

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

分享給大家，希望對大家有所啟發(fā)， 謝謝。