尤雨溪：Turbopack真的比Vite快10倍嗎？
大家好，我是 CUGGZ。
10 月 25 日，Vercel 推出了下一代打包工具：Turbopack，它是基于 Rust 的 Webpack 繼任者，其文檔中提到，Turbopack 比 Vite 快 10 倍。11 月 1 日，Vue、Vite 作者尤雨溪發表文章 《Is Turbopack really 10x Faster than Vite?》，對 Turbopack 和 Vite 進行了測試對比，下面就來看看詳細內容吧！
在 Turbopack 官方文檔的基準圖中，最初顯示帶有 Turbopack 的 Next 13 能夠在 0.01 秒內執行 React Hot-Module Replacement (HMR，即熱更新)，而對于 Vite，則需要 0.09 秒。上面也有冷啟動性能基準，但由于沒有一個冷啟動基準顯示出 10 倍的優勢，我們只能假設“快 10 倍”的說法是基于 HMR 性能。
Vercel 并沒有在文檔中包含指向他們用來生成這些結果的基準的任何鏈接。所以，尤大決定使用新發布的 Next 13 和 Vite 3.2 來驗證這些聲明。測試的要點是通過測量以下兩個時間戳之間的增量來比較 HMR 性能：
- 修改源文件的時間，通過單獨的 Node.js 進程記錄文件更改；
- 更新的 React 組件重新渲染的時間，通過Date.now() 調用直接記錄在組件的渲染輸出中。注意，此調用發生在組件的虛擬 DOM 渲染階段，因此它不受 React 協調或實際 DOM 更新的影響。
該基準還測量了兩種不同情況下的結果：
- root：根組件，組件導入 1000 個不同的子組件并將它們一起渲染。
- leaf：葉子組件，組件由根組件導入，但自己沒有導入組件（沒有子組件）。
細微差別
在測試這些之前，還有一些額外的細微差別值得一提：
- Next 是否使用 React 服務端組件（RSC）。
- Vite 是否使用 SWC 而不是 Babel 進行 React 轉換。
React 服務端組件
Next 13 引入了一個重大的架構轉變，現在的組件默認為服務端組件，除非用戶使用“use client”指令明確選擇客戶端模式。它不僅是默認設置，Next 文檔還建議用戶盡可能保持服務端模式，以提高最終用戶的性能。
第一輪測試（Next w/ RSC 和 Vite w/ Babel)）
最初的基準測試是在服務端模式下使用根組件和葉子組件測量 Next 13 的 HMR 性能。結果表明，Next 13 在兩種情況下實際上都較慢，并且對于葉子組件而言差異顯著，測試方法和測試結果如下。
1、 測試方法
- 這兩個項目都是通過以下命令新創建的：
- 在每個項目中運行genFiles.(m)js 生成 1000 個組件，所有組件都被導入到應用的根組件中并一起渲染。
- 對于每個項目，在單獨的 Node 進程中運行watch.(m)js 以獲取文件更改的確切時間戳，這用于標記 HMR 的開始。
- 啟動項目，然后編輯以下文件以測試 HMR：
- Next: app/page.js (根組件) 和 app/comp0.jsx (葉子組件)。
- Vite: src/App.jsx (根組件) 和 src/components/comp0.jsx (葉子組件)。
已編輯的組件都在其輸出中包含 Date.now()。DOM 中最終渲染的時間戳用于標記 HMR 的完成。
2、測試結果
- 記錄超過 5 次運行
- 時間以毫秒為單位
- 在 M1 Macbook Pro 上測試
第二輪測試（Next w/o RSC 和 Vite w/ Babel)）
有人指出，應該在沒有 RSC（React 服務端組件）的情況下對 Next 組件進行基準測試以使其相等。因此，在 Next 根組件中添加了“use client”指令以選擇客戶端模式。事實上，在客戶端模式下，Next HMR 顯著改進，比 Vite 快 2 倍，測試方法和測試結果如下。
1、測試方法
- 這兩個項目都是通過以下命令新創建的：
- 在每個項目中運行genFiles.(m)js 以生成 1000 個組件。所有組件都被導入到應用的根組件中并一起渲染。
- 給 app/page.js 添加 use client 指令，使它以客戶端模式渲染。這是確保正確的比較所必需的，因為服務端組件會產生不小的 HMR 開銷（慢 4 倍）。
- 對于每個項目，在單獨的 Node 進程中運行watch.(m)js 以獲取文件更改的確切時間戳。這用于標記 HMR 的開始。
- 啟動項目，然后編輯以下文件以測試 HMR：
- Next: app/page.js (根組件) 和 app/comp0.jsx (葉子組件)。
- Vite: src/App.jsx (根組件) 和 src/components/comp0.jsx (葉子組件)。
2、測試結果
- 記錄超過 5 次運行
- 時間以毫秒為單位
- 在 M1 Macbook Pro 上測試
SWC 與 Babel 轉換
我們的目標是讓基準只關注 HMR 性能差異，所以需要消除另一個變量：Vite 的默認 React 預設使用 Babel 來轉換 React HMR 和 JSX。
React HMR 和 JSX 轉換不是與構建工具耦合的特性，它可以通過 Babel（基于 JavaScript）或 SWC（基于 Rust）來完成。Esbuild 也可以轉換 JSX，但缺乏對 HMR 的支持。SWC 比 Babel 快得多（單線程時快 20 倍，多核時快 70 倍）。Vite 目前默認使用 Babel 的原因是安裝大小和實用性之間的權衡。SWC 的安裝量相當大（node_modules 中有 58 MB，而 Vite 只有 19 MB），并且許多用戶仍然依賴 Babel 進行其他轉換，因此 Babel 對他們來說是不可避免的。但是，這種情況在未來可能會發生改變。
Vite core 并不依賴 Babel，因此使用 SWC 而不是 Babel 來處理 React 轉換不需要在 Vite 中進行任何更改，只需將默認的 React 插件替換為 vite-plugin-swc-react-refresh。切換后可以看到，Vite 在根組件中有顯著提升，趕上了 Next：
有趣的是，這里的增長曲線顯示 Next/turbo 在根組件比葉子組件中慢 4 倍，而 Vite 只慢 2.4 倍。這意味著 Vite HMR 在更大的組件中可伸縮性更好。此外，切換到 SWC 還可以改善 Vite 在 Vercel 基準測試中的冷啟動指標。
不同硬件上的性能
由于這是一個涉及 Node.js 和原生 Rust 部分的復合基準測試，因此在不同的硬件上會有很大差異。以上結果是在 M1 MacBook Pro 上收集的。其他用戶在不同的硬件上運行相同的基準測試并報告了不同的結果。在某些情況下，Vite 在根組件情況下更快，而在其他情況下，Vite 在兩種情況下都明顯更快。
Vercel 的澄清
在尤大發布了自己的基準后，Vercel 發布了一篇博客文章，闡明了他們的基準方法，并將他們的基準提供給公眾驗證。閱讀文章和基準代碼后，以下是一些關鍵點：
- Vite 實現仍然使用默認的基于 Babel 的 React 插件。
- 1000 個組件案例的原始數字存在舍入問題——Turbopack 的 15ms 被舍入到 0.01s，而 Vite 的 87ms 被舍入到 0.09s。當原始數字接近 6 倍時，這進一步被宣傳為 10 倍的優勢。
- Vercel 的基準測試使用更新模塊的“瀏覽器評估時間”作為結束時間戳，而不是 React 組件重新渲染時間。
- 文章中的圖表顯示，當總模塊數超過 30k 時，Turbopack 可以比 Vite 快 10 倍。
總而言之，如果以下所有條件都成立，“比 Vite 快 10 倍”的說法是成立的：
- Vite 沒有使用相同的 SWC 轉換。
- 應用包含超過 30k 個模塊。
- 基準測試只測量熱更新模塊的評估時間，而不是實際應用更改的時間。
什么是“公平”比較？
如果我們要比較的是“開箱即用的默認設置”，那么我們應該與 Next 中啟用的 RSC 進行比較，因為這是默認設置，也是 Next 積極鼓勵用戶使用的。由于 Vercel 的基準測試沒有使用 RSC，并且正在測量“模塊評估時間”，以排除 React 的 HMR 運行時引起的差異，因此可以公平地假設基準測試的目標是對 Vite 和 Turbopack 固有的 HMR 機制進行比較。
不幸的是，在這個前提下，Vite 仍然在基準測試中使用 Babel 使這個對比是不平等的。在 Vite 中使用 SWC 進行轉換更新對比結果之前，Turbopack 比 Vite 快 10 倍的結論是不準確的。
此外，我相信大多數人都會同意：
- 對于絕大多數用戶來說，30k 模塊是極不可能的情況。使用 SWC 的 Vite，達到 10 倍要求所需的模塊數量可能會變得更加不切實際。雖然理論上是可行的，但用它來營銷 Turbopack 是不誠實的。
- 與理論上的“模塊評估”時間相比，用戶更關心端到端 HMR 性能，即從保存到看到更改的時間。當看到“更新速度快 10 倍”時，普通用戶會想到前者而不是后者，Vercel 在其營銷中忽略了這一警告。實際上，Next 中服務端組件（默認）的端到端 HMR 比 Vite 中的慢。
作為 Vite 的作者，很高興看到像 Vercel 這樣資金雄厚的公司在改進前端工具方面進行了大量投資。在適用的情況下，甚至未來可能在 Vite 中利用 Turbopack。然而，開源工具的競爭應該建立在公開溝通、公平比較和相互尊重的基礎上，令人失望和擔憂的是，看到激進的營銷使用了精心挑選的、未經同行評審的、邊緣誤導性的數字，這些數字通常只在商業競爭中出現，相信 Vercel 可以做得更好。
相關鏈接
- 原文：https://github.com/yyx990803/vite-vs-next-turbo-hmr/discussions/8。
- 代碼：https://github.com/yyx990803/vite-vs-next-turbo-hmr。
