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

1. 現(xiàn)代Web框架在實際使用和性能方面如何比較？
2. 框架選擇是否會影響網(wǎng)站的核心Web Vitals？
3. 框架選擇與JavaScript有效載荷大小有多相關(guān)，以及影響如何？

數(shù)據(jù)來源

為了達到這個目的，我們查看了三個不同的公開可用數(shù)據(jù)集：

• Chrome用戶體驗報告（CrUX）為Chrome用戶在Web上體驗流行目的地的用戶體驗度量提供了指標。
• HTTP存檔跟蹤 報告了超過1500萬個網(wǎng)站的性能，通過定期收集Lighthouse性能數(shù)據(jù)來跟蹤。
• 核心Web Vitals技術(shù)報告匯集了前兩個數(shù)據(jù)集的有用洞察力。

所有數(shù)據(jù)都是從公開、獨立管理的數(shù)據(jù)集中收集的。Astro團隊沒有直接測量任何性能數(shù)據(jù)。在下面的部分中了解更多關(guān)于我們的方法論。

框架

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

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

Core Web Vitals

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

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

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

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

導致網(wǎng)站無法通過Google核心Web Vitals評估的最可能原因是什么？我們可以按照每個指標來細分數(shù)據(jù)，以了解不同框架在Web Vitals方面的不同挑戰(zhàn)（和成功）。

首次輸入延遲（FID）

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

大多數(shù)框架都能輕松通過此測試，超過90％或更多的網(wǎng)站通過了評估。沒有任何框架在此測試中的通過率低于80％。這意味著大多數(shù)測試的網(wǎng)站對第一個用戶交互做出了響應(yīng)。

累積布局偏移（CLS）

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

CLS是谷歌將其作為三個核心Web Vitals之一的有趣指標，因為它與速度或響應(yīng)性并不嚴格相關(guān)。它的包含突顯了在測量Web上的用戶體驗的整體質(zhì)量時，重要性不僅在于性能方面。

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

最大內(nèi)容渲染時間（LCP）

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

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

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

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

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

那么，這些框架如何應(yīng)對這種新的響應(yīng)性指標呢？

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

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

一個原因可能是單頁應(yīng)用程序（SPA）架構(gòu)通過JavaScript驅(qū)動所有導航作為客戶端操作。這會為輸入延遲創(chuàng)造機會，而沒有客戶端導航的多頁應(yīng)用程序（MPA）則沒有這種機會。在MPA中，導航到新頁面會觸發(fā)從服務(wù)器的完整頁面加載，這不被歸類為輸入延遲。這可能有助于解釋為什么Astro和WordPress（圖表中的兩個MPA）在這個指標上表現(xiàn)顯著優(yōu)于測試的其他框架（所有SPA）。

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

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

這將是2023年值得關(guān)注的指標，谷歌繼續(xù)權(quán)衡將INP添加為官方的核心Web Vital。

Lighthouse性能

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

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

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

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

在所有跟蹤的網(wǎng)站中，中位性能分數(shù)是34/100。為此，我們測試的一半框架（Astro，SvelteKit和Remix）的平均水平高于互聯(lián)網(wǎng)平均水平。

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

JavaScript的成本

我們想要探索的最后一件事是框架選擇、性能和實際使用中總JavaScript負載大小之間的關(guān)系。最快的框架是否傾向于向客戶端發(fā)送最少量的JavaScript？

數(shù)據(jù)趨勢很清楚：發(fā)送更少JavaScript的網(wǎng)站 tend to perform better。然而，有太多因素在起作用，我們無法自信地將這種趨勢與web框架選擇本身聯(lián)系起來?？赡芮闆r是某些框架在鼓勵/阻止JavaScript方面與其他框架不同，但在我們得出任何結(jié)論之前，需要進行更多研究。

方法和限制

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

由于容量限制，我們的分析僅關(guān)注每個跟蹤網(wǎng)站的主頁。這種限制的好處是每個分析網(wǎng)站的目的和用例變化較小。然而，一個缺點是這也意味著內(nèi)部頁面（例如/about和/admin/...頁面）及其使用的技術(shù)未經(jīng)分析，因此被排除在我們的分析之外。

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

總結(jié)

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

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