大家好，我是 CUGGZ，祝大家端午節(jié)快樂(lè)~

JavaScript 框架數(shù)量眾多，那究竟哪個(gè)框架速度更快呢？今天就來(lái)分享一個(gè)開(kāi)源的 JavaScript 框架性能基準(zhǔn)工具：js-framework-benchmark，它通過(guò)測(cè)量各種常見(jiàn)操作的執(zhí)行時(shí)間、內(nèi)存占用等來(lái)對(duì)比不同框架的性能。下面就來(lái)看看這個(gè)工具是怎么使用的吧！

瀏覽器版本

進(jìn)入官方測(cè)試結(jié)果的首頁(yè)，可以看到不同瀏覽器版本的測(cè)試結(jié)果鏈接，從 Chrome 55 版本到最新的 114 版本，該頁(yè)面會(huì)隨著瀏覽器版本的更新而更新（更新有延遲）。

這里我們選擇最新的版本進(jìn)行查看：

這個(gè)頁(yè)面最上方會(huì)有一些篩選項(xiàng)，包括框架種類、基準(zhǔn)種類、展示模式。

框架種類

這里將 JavaScript 框架分為兩類：

• 基于 key 的實(shí)現(xiàn)：通過(guò)分配 key 來(lái)創(chuàng)建數(shù)據(jù)和 DOM 元素之間的關(guān)聯(lián)。如果數(shù)據(jù)發(fā)生變化，具有該 key 的 DOM 元素將更新。因此，在數(shù)據(jù)數(shù)組中插入或刪除元素會(huì)導(dǎo)致相應(yīng)地更改 DOM。
• 非基于 key 的實(shí)現(xiàn)：允許重用現(xiàn)有的 DOM 元素。因此，在數(shù)據(jù)數(shù)組中插入或刪除元素可能會(huì)在最后一個(gè)表行后追加，或者刪除該行，并更新插入或刪除索引后的所有元素的內(nèi)容。這樣做可能性能更好，但是如果 DOM 狀態(tài)在外部被修改可能會(huì)導(dǎo)致問(wèn)題。

下面是 js-framework-benchmark 支持的 JavaScript 框架：

這里提供了全選和全不選按鈕，并支持選擇任意框架，選擇完之后就可以查看結(jié)果了：

基準(zhǔn)種類

性能測(cè)試基準(zhǔn)分為三類：

• 持續(xù)時(shí)間
• 啟動(dòng)指標(biāo)
• 內(nèi)存分配

當(dāng)選擇完框架之后，就會(huì)展示三個(gè)表格，分別對(duì)應(yīng)這三類指標(biāo)。

可以看到，在所有的指標(biāo)中， solid.js 的平均值都是最低的，性能最好。在最常用的三大前端框架（Vue、React、Angular）中，Vue 的性能最好，React 的性能最差。

（1）持續(xù)時(shí)間

• create rows：創(chuàng)建行，頁(yè)面加載后創(chuàng)建 1000 行的持續(xù)時(shí)間（無(wú)預(yù)熱）
• replace all rows：替換所有行，替換表中所有 1000 行所需的時(shí)間（5 次預(yù)熱循環(huán)）。該指標(biāo)最大的價(jià)值就是了解當(dāng)頁(yè)面上的大部分內(nèi)容發(fā)生變化時(shí)庫(kù)的執(zhí)行方式。
• partial update：部分更新，對(duì)于具有 10000 行的表，每 10 行更新一次文本（進(jìn)行 5 次預(yù)熱循環(huán)）。該指標(biāo)是動(dòng)畫(huà)性能和深層嵌套數(shù)據(jù)結(jié)構(gòu)開(kāi)銷等方面的最佳指標(biāo)。
• select row：選擇行，在單擊行時(shí)高亮顯示該行所需的時(shí)間（進(jìn)行 5 次預(yù)熱循環(huán)）。
• swap rows：交換行，在包含 1000 行的表中交換 2 行的時(shí)間（進(jìn)行 5 次預(yù)熱迭代）。
• remove row：刪除行，在包含 1,000 行的表格上移除一行所需的時(shí)間（有 5 次預(yù)熱迭代），該指標(biāo)可能變化最少，因?yàn)樗葞?kù)的任何開(kāi)銷更多地測(cè)試瀏覽器布局變化（因?yàn)樗行邢蛏弦苿?dòng)）。
• create many rows：創(chuàng)建多行，創(chuàng)建 10000 行所需的時(shí)間（沒(méi)有預(yù)熱），該指標(biāo)更容易受到內(nèi)存開(kāi)銷的影響，并且對(duì)于效率較低的庫(kù)來(lái)說(shuō)，擴(kuò)展性會(huì)更差。
• append rows to large table：追加行到大型表格，在包含 10000 行的表格上添加 1000 行所需的時(shí)間（沒(méi)有預(yù)熱）。
• clear rows：清空行，清空包含 10000 行的表格所需的時(shí)間（沒(méi)有預(yù)熱），該指標(biāo)說(shuō)明了庫(kù)清理代碼的成本，內(nèi)存使用對(duì)這個(gè)指標(biāo)的影響很大，因?yàn)闉g覽器需要更多的 GC。

（2）內(nèi)存分配

• ready memory：頁(yè)面加載后的內(nèi)存使用量。頁(yè)面上只有幾個(gè)按鈕，因此這個(gè)內(nèi)存數(shù)字較低，大多數(shù)庫(kù)在這里表現(xiàn)相似。
• run memory：添加1000行后的內(nèi)存使用情況。
• Update every 10th row：與性能測(cè)試 3 相同，但這次我們看到了執(zhí)行部分更新的內(nèi)存開(kāi)銷。大多數(shù)情況下，這是新字符串值的分配，但第一次看到庫(kù)動(dòng)態(tài)比較機(jī)制的內(nèi)存開(kāi)銷。
• Replace Rows：這將 1000 行替換 5 次。這是檢測(cè)內(nèi)存泄漏的一個(gè)很好的測(cè)試。
• Create/Clear Rows：創(chuàng)建然后清除 1000 行。

（3）啟動(dòng)指標(biāo)

• Consistently Interactive：持續(xù)交互，一個(gè)悲觀的TTI，等待CPU空閑50ms。除非庫(kù)很大，否則這里的分?jǐn)?shù)分布不會(huì)那么大，而且主要隨著包大小而擴(kuò)展，但似乎沒(méi)有受到影響的 WASM 庫(kù)除外（Blazor 除外）。
• Total Kilobyte Weight：總 KB 大小，這衡量了所有資源的總大小，包括用戶代碼、HTML 和 CSS。這很有用，因?yàn)樗@示了實(shí)際構(gòu)建大小與包大小之間的差別。

其他框架

該工具除了支持對(duì) JavaScript 框架進(jìn)行性能基準(zhǔn)測(cè)試之外，還支持對(duì) Rust 實(shí)現(xiàn)的 WebAssembly 庫(kù)和框架進(jìn)行測(cè)試，如 wasm-bindgen、stdweb、yew、seed 等。

小結(jié)

js-framework-benchmark 的測(cè)試結(jié)果是相對(duì)準(zhǔn)確的，因?yàn)樗轻槍?duì)同樣的測(cè)試樣本和基準(zhǔn)測(cè)試情境進(jìn)行比較，可以提供框架之間的相對(duì)性能比較。然而，需要注意的是，這個(gè)測(cè)試結(jié)果也只是反映了測(cè)試條件下的性能表現(xiàn)?？蚣軐?shí)際的性能可能還會(huì)受到很多方面的影響。

此外，js-framework-benchmark 測(cè)試結(jié)果也不應(yīng)該成為選擇框架的唯一指標(biāo)。在選擇框架時(shí)，還需要考慮框架的生態(tài)、開(kāi)發(fā)效率、易用性等多方面因素，而不僅僅是性能表現(xiàn)。

Github：https://github.com/krausest/js-framework-benchmark