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

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

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

(資料圖片)

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

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

框架

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

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

Core Web Vitals

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

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

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

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

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

首次輸入延遲（FID）

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

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

累積布局偏移（CLS）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Lighthouse性能

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

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

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

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

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

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

JavaScript的成本

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

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

方法和限制

本報(bào)告是從幾個(gè)公開可用的數(shù)據(jù)集中編制而成的?？梢栽诖颂幜私膺@些數(shù)據(jù)集及其方法：HTTP Archive methodology、CrUX methodology和CWV Technology Report methodology。

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

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

總結(jié)

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

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

關(guān)鍵詞：