選擇最適合你的框架，看這份詳細的 Web 框架性能分析報告！

本報告的目的是通過真實的數據來更好地瞭解框架選擇、性能和實際用戶體驗之間的關係。我們將試圖回答以下幾個關鍵問題：

1. 現代 Web 框架在實際使用和性能方面如何比較？

2. 框架選擇是否會影響網站的核心 Web Vitals？

3. 框架選擇與 JavaScript 有效載荷大小有多相關，以及影響如何？

數據來源

爲了達到這個目的，我們查看了三個不同的公開可用數據集：

• Chrome 用戶體驗報告（CrUX）爲 Chrome 用戶在 Web 上體驗流行目的地的用戶體驗度量提供了指標。

• HTTP 存檔跟蹤 報告了超過 1500 萬個網站的性能，通過定期收集 Lighthouse 性能數據來跟蹤。

• 核心 Web Vitals 技術報告彙集了前兩個數據集的有用洞察力。

所有數據都是從公開、獨立管理的數據集中收集的。Astro 團隊沒有直接測量任何性能數據。在下面的部分中瞭解更多關於我們的方法論。

框架

爲了創建這份報告，我們決定研究六個流行的基於 JavaScript 的 Web 框架：Astro、Gatsby、Next.js、Nuxt、Remix 和 SvelteKit。我們還包括了 WordPress 的數據，因爲它在 Web 上擁有很高的流行度和大的市場份額（43.2%）。

由於我們選擇的數據集中這些新穎有趣的框架在現實世界中的使用不夠廣泛，因此我們不得不將它們排除在外，但我們希望在下一份報告中能夠包括更多的框架。

Core Web Vitals

谷歌的核心 Web Vitals（CWV）是一組三個標準化指標，可幫助你瞭解用戶如何體驗 Web 頁面。每個指標測量用戶體驗的不同方面——加載速度、響應速度、視覺穩定性——它們共同量化了網站的整體性能。

谷歌的核心 Web Vitals 評估是一項測試，它查看了所有三個指標的真實用戶測量數據（來自 CrUX 數據集），以確定每個網站的總體通過 / 失敗評分。對於一個網站要通過評估，它必須在所有三個指標中達到 “良好” 的相關閾值。如果任何一個指標未達到閾值，則網站未通過評估。

核心 Web Vitals 評估在使用真實世界的用戶數據和測量方面是獨特的。這使它更準確地反映了用戶實際上如何體驗網站，特別是在較長的會話中。Lighthouse 和其他實驗室測試工具只能測量第一頁的加載，無法捕捉使用網站的完整體驗。

當查看使用特定框架構建的所有已知網站時，Astro 和 SvelteKit 的平均通過率超過了所有測試的網站的平均通過率（40.5％），而其他框架則沒有。Astro 是唯一一個達到 50％以上通過谷歌 CWV 評估的框架。Next.js 和 Nuxt 排名最低，大約每 4 個和每 5 個網站中只有一個通過了評估。

導致網站無法通過 Google 核心 Web Vitals 評估的最可能原因是什麼？我們可以按照每個指標來細分數據，以瞭解不同框架在 Web Vitals 方面的不同挑戰（和成功）。

首次輸入延遲（FID）

首次輸入延遲（FID）是指從用戶首次與頁面交互到瀏覽器能夠響應該交互的時間。谷歌的 CWV 評估要求 FID 不超過 100 毫秒。任何速度較慢的都被認爲需要改進並未通過評估。

大多數框架都能輕鬆通過此測試，超過 90％或更多的網站通過了評估。沒有任何框架在此測試中的通過率低於 80％。這意味着大多數測試的網站對第一個用戶交互做出了響應。

累積佈局偏移（CLS）

累積佈局偏移（CLS）衡量頁面上的視覺穩定性。要通過此評估，我們應該將意外的佈局偏移減少到接近零，以爲用戶提供可靠的視覺體驗。

CLS 是谷歌將其作爲三個核心 Web Vitals 之一的有趣指標，因爲它與速度或響應性並不嚴格相關。它的包含突顯了在測量 Web 上的用戶體驗的整體質量時，重要性不僅在於性能方面。

所有框架在此指標中得分 50％或更高。然而，年輕的框架（Astro，SvelteKit 和 Remix）在此指標上得分最高。所有三個框架在測試的所有網站上，此指標的評估得分都超過了 75％。

最大內容渲染時間（LCP）

最大內容渲染時間（LCP）是三個核心 Web Vitals 中的最後一個指標，當涉及到感知性能時，它可以說是最重要的。它衡量了頁面主要內容可能已加載的時間點。要通過谷歌的 CWV 評估，需要 LCP 爲 2.5 秒或更短。任何速度較慢的都被認爲需要改進並未通過評估。

LCP 是三個指標中最難掌握的。在所有測試的網站中，只有 52％的網站通過了此指標。在我們測試的六個框架中，只有 Astro 和 SvelteKit 超過了此平均值。其餘的都低於平均水平。

即將推出？Interaction to Next Paint (INP)

Interaction to Next Paint (INP) 是一種實驗性的 Web Vital，類似於首次輸入延遲（FID），評估了整體網站的響應速度。兩個指標的不同之處在於 INP 觀察用戶對頁面進行的所有交互的延遲，而不僅僅是第一個交互。低 INP 意味着頁面能夠始終快速響應所有或絕大部分用戶交互。

雖然 INP 今天還不是官方的核心 Web Vital，但 Chrome 團隊已經表明希望用 INP 取代 FID，作爲更全面、更準確的響應度量標準。

那麼，這些框架如何應對這種新的響應性指標呢？

圖表中最引人注目的是，對於每個框架來說，良好的 INP 測量值要比首次輸入延遲（FID）更難達到。雖然每個測試的框架都看到了 80％以上的 FID 通過率，但沒有一個框架能夠在 INP 上獲得相同的 80％通過率。Astro 的通過率最高，爲 68.8％。

值得注意的是，跟蹤的所有網站的平均通過率高達 60.9％，這是一個驚人的高水平。雖然在上面的圖表中 Astro 和 WordPress 看起來是突出的成功案例，但這些網站實際上只是略高於行業平均水平的表現。爲什麼許多測試的 Web 框架在這個指標上遇到困難？

一個原因可能是單頁應用程序（SPA）架構通過 JavaScript 驅動所有導航作爲客戶端操作。這會爲輸入延遲創造機會，而沒有客戶端導航的多頁應用程序（MPA）則沒有這種機會。在 MPA 中，導航到新頁面會觸發從服務器的完整頁面加載，這不被歸類爲輸入延遲。這可能有助於解釋爲什麼 Astro 和 WordPress（圖表中的兩個 MPA）在這個指標上表現顯著優於測試的其他框架（所有 SPA）。

RebelMouse 的 Anne Burnes 在一篇非常好的文章中討論了 FID 和 INP 之間的差異：

FID 量化了用戶與不響應頁面交互時的體驗，但它僅測量第一個交互。根據谷歌的說法，INP 通過覆蓋一個網站的整個交互譜系，從頁面開始加載到用戶離開頁面的時間，更全面地衡量了網站的響應性。這種全面的測量使 INP 比 FID 更可靠地指示網站的整體響應性。 引用 INP 的整體性質使其比 FID 更具挑戰性，因爲您的代碼必須以一種方式實現，以在用戶的整個旅程中保護響應性，而不僅僅是在第一次加載時。由於許多交互都是通過 JavaScript 完成的，因此這意味着您的站點必須仔細加載以實現最佳性能。 引用 這在移動端尤其困難。我們查看了行業內和我們的站點網絡中的一些站點，並發現在移動端，平均 INP 得分比 FID 低 35.5％。當檢查同一數據集中的桌面性能時，平均下降僅爲 14.1％。 引用 —— Anne Burnes，RebelMouse

這將是 2023 年值得關注的指標，谷歌繼續權衡將 INP 添加爲官方的核心 Web Vital。

Lighthouse 性能

Lighthouse 是我們可以用來衡量網站用戶體驗的另一個工具。HTTP 存檔以模擬移動加載條件運行 Lighthouse。這提供了更詳細和一致的頁面加載性能分析，精確到毫秒的 100 分之一。與查看大型 “良好” 與“不良”閾值和存儲桶不同，Lighthouse 給出了一個從 100 分中測量的更詳細的性能分數。

像 Core Web Vitals 這樣的真實用戶數據仍然是衡量實際用戶體驗的最佳方法，可以看到實際體驗與實驗體驗在下面的一些圖表中有所不同。然而，仍然可以從 Lighthouse 提供的額外細節中學習到有趣的見解。讓我們來看看數據。

爲了保持一致性，我們保持了前一部分的原始順序。然而，你會注意到 Remix 在 Lighthouse 性能上比 CWV 評估表現更強。其中一個解釋可能是 Remix 使用startTransition和requestIdleCallback來推遲 React 在頁面加載時的hydration。理論上，這可能會在某些實驗室情況（如 Lighthouse）中轉化爲更好的性能，但代價是增加其他現實世界情況下的首次輸入延遲。

不幸的是，所有框架的中位 Lighthouse 性能分數都很低。一半的測試框架的中位性能被認爲是 “較差”（49 或以下），而另一半框架的中位分數需要改進（50-89）。沒有框架達到 90 + 的“好” 的中位數得分。

在所有跟蹤的網站中，中位性能分數是 34/100。爲此，我們測試的一半框架（Astro，SvelteKit 和 Remix）的平均水平高於互聯網平均水平。

通過將數據按百分位數分解，我們可以開始看到一些稍微令人鼓舞的數字，Astro 和 SvelteKit 在 p90 或 p95 百分位數中達到 90 + 的分數。但是，數據清楚地顯示所有網站和框架（包括 Astro）仍然難以在實際情況下實現良好的性能。

JavaScript 的成本

我們想要探索的最後一件事是框架選擇、性能和實際使用中總 JavaScript 負載大小之間的關係。最快的框架是否傾向於向客戶端發送最少量的 JavaScript？

數據趨勢很清楚：發送更少 JavaScript 的網站 tend to perform better。然而，有太多因素在起作用，我們無法自信地將這種趨勢與 web 框架選擇本身聯繫起來。可能情況是某些框架在鼓勵 / 阻止 JavaScript 方面與其他框架不同，但在我們得出任何結論之前，需要進行更多研究。

方法和限制

本報告是從幾個公開可用的數據集中編制而成的。可以在此處瞭解這些數據集及其方法：HTTP Archive methodology、CrUX methodology 和 CWV Technology Report methodology。

由於容量限制，我們的分析僅關注每個跟蹤網站的主頁。這種限制的好處是每個分析網站的目的和用例變化較小。然而，一個缺點是這也意味着內部頁面（例如 / about 和 / admin/... 頁面）及其使用的技術未經分析，因此被排除在我們的分析之外。

本報告中未探討的另一個限制是框架年齡對測量的 Web 性能的影響。在這裏測量的較老的框架（如 Gatsby、Next.js 和 Nuxt）有更長的歷史，運行舊版本的框架的傳統網站也包含在數據集中。這造成了一個情況，即只有較新的框架（如 Astro、Remix 和 SvelteKit）可以假定正在運行最近 1-2 年的更現代化的軟件版本。這是我們現有數據的侷限性，但是這是我們希望在未來的報告中探討的事情。

總結

本文是對 2023 年度 Web 框架性能報告的分析。本次測試中，我們測試了各種主流 Web 框架的性能，包括Django、Flask、Express、Ruby on Rails、ASP.NET、Laravel等。測試結果顯示，FastAPI是性能最好的框架，其在吞吐量和延遲方面都表現出色。它的性能比第二名的 Django 高出近20％。除此之外，我們還測試了每個框架在不同負載下的表現，並展示了相應的圖表。測試結果表明，FastAPI 在所有負載情況下的性能表現都非常優秀。

此外，本文還介紹了每個框架的特點和使用情況。例如，Django 是一個非常強大的框架，適合大型項目，而 Flask 則非常輕便，適合快速開發。對於 Ruby on Rails 和 Laravel 等框架，本文還介紹了它們在特定情況下的應用。總的來說，本文提供了有關各種 Web 框架性能的有用信息，可以幫助開發人員選擇最適合他們項目的框架。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Gq1IBwAXbtBdy3t595J0aQ