Webpack 構建慢的原因是什么

這篇文章主要講解了“ Webpack 構建慢的原因是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“ Webpack 構建慢的原因是什么”吧！

背景

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

還有數據對比：

可以明顯看到：esbuild 一騎絕塵, 以絕對優勢領先。

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

那么, webpack 的構建為什么慢呢?到底慢在哪呢 ?

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

正文

首先我們先看一下 webpack 構建的大致流程:

webpack build flow

流程走的比較長。

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

我認為主要是在以下兩個階段：

1. 代碼構建

2. 代碼壓縮

圖片

https://www.quora.com/What-is-Webpack-and-babel-loader

我們分別來看。

1. 代碼構建

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

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

webpack build graph

https://medium.com/webpack/the-chunk-graph-algorithm-week-26-29-7c88aa5e4b4e

這部分非常復雜，也比較耗時。

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

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

https://youtu.be/Lzh8A0p3z8g

說回構建。

現代瀏覽器對 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/#build-minify

另外，如果你有留意， 就會發現一個現象:

1. Esbuild, 使用 GO 寫的。

2. SWC， 是用 Rust 寫的。

都不是用js寫的。

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

還有一點需要提一下。

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

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

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

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

• Module Federation

• Real Content Hash

感謝各位的閱讀，以上就是“ Webpack 構建慢的原因是什么”的內容了，經過本文的學習后，相信大家對 Webpack 構建慢的原因是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！