選擇最合適你的框架，看這份細(xì)致的Web框架性能剖析報(bào)告！

基于Go語言,K8s+gRPC實(shí)戰(zhàn)云原生微服務(wù)開發(fā)

download：https://www.51xuebc.com/thread-539-1-1.html

?現(xiàn)代Web框架在實(shí)踐運(yùn)用和性能方面如何比擬？框架選擇能否會(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)站的性能，經(jīng)過定期搜集Lighthouse性能數(shù)據(jù)來跟蹤。中心Web Vitals技術(shù)報(bào)告聚集了前兩個(gè)數(shù)據(jù)集的有用洞察力。一切數(shù)據(jù)都是從公開、獨(dú)立管理的數(shù)據(jù)集中搜集的。Astro團(tuán)隊(duì)沒有直接丈量任何性能數(shù)據(jù)。在下面的局部中理解更多關(guān)于我們的辦法論。
框架為了創(chuàng)立這份報(bào)告，我們決議研討六個(gè)盛行的基于 JavaScript 的 Web 框架：Astro、Gatsby、Next.js、Nuxt、Remix 和 SvelteKit。我們還包括了 WordPress 的數(shù)據(jù)，由于它在 Web 上具有很高的盛行度和大的市場份額（43.2%）。
由于我們選擇的數(shù)據(jù)集中這些新穎有趣的框架在理想世界中的運(yùn)用不夠普遍，因而我們不得不將它們掃除在外，但我們希望在下一份報(bào)告中可以包括更多的框架。
Core Web Vitals谷歌的中心Web Vitals（CWV）是一組三個(gè)規(guī)范化指標(biāo)，可協(xié)助你理解用戶如何體驗(yàn)Web頁面。每個(gè)指標(biāo)丈量用戶體驗(yàn)的不同方面——加載速度、響應(yīng)速度、視覺穩(wěn)定性——它們共同量化了網(wǎng)站的整體性能。
谷歌的中心Web Vitals評價(jià)是一項(xiàng)測試，它查看了一切三個(gè)指標(biāo)的真適用戶丈量數(shù)據(jù)（來自CrUX數(shù)據(jù)集），以肯定每個(gè)網(wǎng)站的總體經(jīng)過/失敗評分。關(guān)于一個(gè)網(wǎng)站要經(jīng)過評價(jià)，它必需在一切三個(gè)指標(biāo)中到達(dá)“良好”的相關(guān)閾值。假如任何一個(gè)指標(biāo)未到達(dá)閾值，則網(wǎng)站未經(jīng)過評價(jià)。

中心Web Vitals評價(jià)在運(yùn)用真實(shí)世界的用戶數(shù)據(jù)和丈量方面是共同的。這使它更精確地反映了用戶實(shí)踐上如何體驗(yàn)網(wǎng)站，特別是在較長的會(huì)話中。Lighthouse和其他實(shí)驗(yàn)室測試工具只能丈量第一頁的加載，無法捕捉運(yùn)用網(wǎng)站的完好體驗(yàn)。
image.png
當(dāng)查看運(yùn)用特定框架構(gòu)建的一切已知網(wǎng)站時(shí)，Astro和SvelteKit的均勻經(jīng)過率超越了一切測試的網(wǎng)站的均勻經(jīng)過率（40.5％），而其他框架則沒有。Astro是獨(dú)一一個(gè)到達(dá)50％以上經(jīng)過谷歌CWV評價(jià)的框架。Next.js和Nuxt排名最低，大約每4個(gè)和每5個(gè)網(wǎng)站中只要一個(gè)經(jīng)過了評價(jià)。
招致網(wǎng)站無法經(jīng)過Google中心Web Vitals評價(jià)的最可能緣由是什么？我們能夠依照每個(gè)指標(biāo)來細(xì)分?jǐn)?shù)據(jù)，以理解不同框架在Web Vitals方面的不同應(yīng)戰(zhàn)（和勝利）。
初次輸入延遲（FID）image.png
初次輸入延遲（FID）是指從用戶初次與頁面交互到閱讀器可以響應(yīng)該交互的時(shí)間。谷歌的CWV評價(jià)請求FID不超越100毫秒。任何速度較慢的都被以為需求改良并未經(jīng)過評價(jià)。
大多數(shù)框架都能輕松經(jīng)過此測試，超越90％或更多的網(wǎng)站經(jīng)過了評價(jià)。沒有任何框架在此測試中的經(jīng)過率低于80％。這意味著大多數(shù)測試的網(wǎng)站對第一個(gè)用戶交互做出了響應(yīng)。
累積規(guī)劃偏移（CLS）image.png
累積規(guī)劃偏移（CLS）權(quán)衡頁面上的視覺穩(wěn)定性。要經(jīng)過此評價(jià)，我們應(yīng)該將不測的規(guī)劃偏移減少到接近零，以為用戶提供牢靠的視覺體驗(yàn)。
CLS是谷歌將其作為三個(gè)中心Web Vitals之一的有趣指標(biāo)，由于它與速度或響應(yīng)性并不嚴(yán)厲相關(guān)。它的包含突顯了在丈量Web上的用戶體驗(yàn)的整體質(zhì)量時(shí)，重要性不只在于性能方面。

一切框架在此指標(biāo)中得分50％或更高。但是，年輕的框架（Astro，SvelteKit和Remix）在此指標(biāo)上得分最高。一切三個(gè)框架在測試的一切網(wǎng)站上，此指標(biāo)的評價(jià)得分都超越了75％。
最大內(nèi)容渲染時(shí)間（LCP）image.png
最大內(nèi)容渲染時(shí)間（LCP）是三個(gè)中心Web Vitals中的最后一個(gè)指標(biāo)，當(dāng)觸及到感知性能時(shí)，它能夠說是最重要的。它權(quán)衡了頁面主要內(nèi)容可能已加載的時(shí)間點(diǎn)。要經(jīng)過谷歌的CWV評價(jià)，需求LCP為2.5秒或更短。任何速度較慢的都被以為需求改良并未經(jīng)過評價(jià)。
LCP是三個(gè)指標(biāo)中最難控制的。在一切測試的網(wǎng)站中，只要52％的網(wǎng)站經(jīng)過了此指標(biāo)。在我們測試的六個(gè)框架中，只要Astro和SvelteKit超越了此均勻值。其他的都低于均勻程度。
行將推出？Interaction to Next Paint (INP)Interaction to Next Paint (INP)是一種實(shí)驗(yàn)性的Web Vital，相似于初次輸入延遲（FID），評價(jià)了整體網(wǎng)站的響應(yīng)速度。兩個(gè)指標(biāo)的不同之處在于INP察看用戶對頁面停止的一切交互的延遲，而不只僅是第一個(gè)交互。低INP意味著頁面可以一直快速響應(yīng)一切或絕大局部用戶交互。
固然INP今天還不是官方的中心Web Vital，但Chrome團(tuán)隊(duì)曾經(jīng)標(biāo)明希望用INP取代FID，作為更全面、更精確的響應(yīng)度量規(guī)范。
那么，這些框架如何應(yīng)對這種新的響應(yīng)性指標(biāo)呢？
image.png
圖表中最引人矚目的是，關(guān)于每個(gè)框架來說，良好的INP丈量值要比初次輸入延遲（FID）更難到達(dá)。固然每個(gè)測試的框架都看到了80％以上的FID經(jīng)過率，但沒有一個(gè)框架可以在INP上取得相同的80％經(jīng)過率。Astro的經(jīng)過率最高，為68.8％。
值得留意的是，跟蹤的一切網(wǎng)站的均勻經(jīng)過率高達(dá)60.9％，這是一個(gè)驚人的高程度。固然在上面的圖表中Astro和WordPress看起來是突出的勝利案例，但這些網(wǎng)站實(shí)踐上只是略高于行業(yè)均勻程度的表現(xiàn)。為什么許多測試的Web框架在這個(gè)指標(biāo)上遇到艱難？
一個(gè)緣由可能是單頁應(yīng)用程序（SPA）架構(gòu)經(jīng)過JavaScript驅(qū)動(dòng)一切導(dǎo)航作為客戶端操作。這會(huì)為輸入延遲發(fā)明時(shí)機(jī)，而沒有客戶端導(dǎo)航的多頁應(yīng)用程序（MPA）則沒有這種時(shí)機(jī)。在MPA中，導(dǎo)航到新頁面會(huì)觸發(fā)從效勞器的完好頁面加載，這不被歸類為輸入延遲。這可能有助于解釋為什么Astro和WordPress（圖表中的兩個(gè)MPA）在這個(gè)指標(biāo)上表現(xiàn)顯著優(yōu)于測試的其他框架（一切SPA）。
RebelMouse的Anne Burnes在一篇十分好的文章中討論了FID和INP之間的差別：
FID量化了用戶與不響應(yīng)頁面交互時(shí)的體驗(yàn)，但它僅丈量第一個(gè)交互。依據(jù)谷歌的說法，INP經(jīng)過掩蓋一個(gè)網(wǎng)站的整個(gè)交互譜系，從頁面開端加載到用戶分開頁面的時(shí)間，更全面地權(quán)衡了網(wǎng)站的響應(yīng)性。這種全面的丈量使INP比FID更牢靠地指示網(wǎng)站的整體響應(yīng)性。援用INP的整體性質(zhì)使其比FID更具應(yīng)戰(zhàn)性，由于您的代碼必需以一種方式完成，以在用戶的整個(gè)旅程中維護(hù)響應(yīng)性，而不只僅是在第一次加載時(shí)。由于許多交互都是經(jīng)過JavaScript完成的，因而這意味著您的站點(diǎn)必需認(rèn)真加載以完成最佳性能。援用這在挪動(dòng)端特別艱難。我們查看了行業(yè)內(nèi)和我們的站點(diǎn)網(wǎng)絡(luò)中的一些站點(diǎn)，并發(fā)如今挪動(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是我們能夠用來權(quán)衡網(wǎng)站用戶體驗(yàn)的另一個(gè)工具。HTTP存檔以模仿挪動(dòng)加載條件運(yùn)轉(zhuǎn)Lighthouse。這提供了更細(xì)致和分歧的頁面加載性能剖析，準(zhǔn)確到毫秒的100分之一。與查看大型“良好”與“不良”閾值和存儲(chǔ)桶不同，Lighthouse給出了一個(gè)從100分中丈量的更細(xì)致的性能分?jǐn)?shù)。
像Core Web Vitals這樣的真適用戶數(shù)據(jù)依然是權(quán)衡實(shí)踐用戶體驗(yàn)的最佳辦法，能夠看到實(shí)踐體驗(yàn)與實(shí)驗(yàn)體驗(yàn)在下面的一些圖表中有所不同。但是，依然能夠從Lighthouse提供的額外細(xì)節(jié)中學(xué)習(xí)到有趣的見解。讓我們來看看數(shù)據(jù)。
image.png
為了堅(jiān)持分歧性，我們堅(jiān)持了前一局部的原始次第。但是，你會(huì)留意到Remix在Lighthouse性能上比CWV評價(jià)表現(xiàn)更強(qiáng)。其中一個(gè)解釋可能是Remix運(yùn)用startTransition和requestIdleCallback來推延React在頁面加載時(shí)的hydration。理論上，這可能會(huì)在某些實(shí)驗(yàn)室狀況（如Lighthouse）中轉(zhuǎn)化為更好的性能，但代價(jià)是增加其他理想世界狀況下的初次輸入延遲。
不幸的是，一切框架的中位Lighthouse性能分?jǐn)?shù)都很低。一半的測試框架的中位性能被以為是“較差”（49或以下），而另一半框架的中位分?jǐn)?shù)需求改良（50-89）。沒有框架到達(dá)90+的“好”的中位數(shù)得分。
在一切跟蹤的網(wǎng)站中，中位性能分?jǐn)?shù)是34/100。為此，我們測試的一半框架（Astro，SvelteKit和Remix）的均勻程度高于互聯(lián)網(wǎng)均勻程度。
image.png
經(jīng)過將數(shù)據(jù)按百分位數(shù)合成，我們能夠開端看到一些略微令人鼓舞的數(shù)字，Astro和SvelteKit在p90或p95百分位數(shù)中到達(dá)90+的分?jǐn)?shù)。但是，數(shù)據(jù)分明地顯現(xiàn)一切網(wǎng)站和框架（包括Astro）依然難以在實(shí)踐狀況下完成良好的性能。
JavaScript的本錢我們想要探究的最后一件事是框架選擇、性能和實(shí)踐運(yùn)用中總JavaScript負(fù)載大小之間的關(guān)系。最快的框架能否傾向于向客戶端發(fā)送最少量的JavaScript？
image.png
數(shù)據(jù)趨向很分明：發(fā)送更少JavaScript的網(wǎng)站 tend to perform better。但是，有太多要素在起作用，我們無法自信地將這種趨向與web框架選擇自身聯(lián)絡(luò)起來。可能狀況是某些框架在鼓舞/阻止JavaScript方面與其他框架不同，但在我們得出任何結(jié)論之前，需求停止更多研討。
辦法和限制本報(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è)缺陷是這也意味著內(nèi)部頁面（例如/about和/admin/...頁面）及其運(yùn)用的技術(shù)未經(jīng)剖析，因而被掃除在我們的剖析之外。
本報(bào)告中未討論的另一個(gè)限制是框架年齡對丈量的Web性能的影響。在這里丈量的較老的框架（如Gatsby、Next.js和Nuxt）有更長的歷史，運(yùn)轉(zhuǎn)舊版本的框架的傳統(tǒng)網(wǎng)站也包含在數(shù)據(jù)集中。這形成了一個(gè)狀況，即只要較新的框架（如Astro、Remix和SvelteKit）能夠假定正在運(yùn)轉(zhuǎn)最近1-2年的更現(xiàn)代化的軟件版本。這是我們現(xiàn)有數(shù)據(jù)的局限性，但是這是我們希望在將來的報(bào)告中討論的事情。
總結(jié)本文是對2023年度Web框架性能報(bào)告的剖析。本次測試中，我們測試了各種主流Web框架的性能，包括Django、Flask、Express、Ruby on Rails、ASP.NET、Laravel等。測試結(jié)果顯現(xiàn)，F(xiàn)astAPI是性能最好的框架，其在吞吐量和延遲方面都表現(xiàn)出色。它的性能比第二名的 Django高出近20％。除此之外，我們還測試了每個(gè)框架在不同負(fù)載下的表現(xiàn)，并展現(xiàn)了相應(yīng)的圖表。測試結(jié)果標(biāo)明，F(xiàn)astAPI 在一切負(fù)載狀況下的性能表現(xiàn)都十分優(yōu)秀。
此外，本文還引見了每個(gè)框架的特性和運(yùn)用狀況。例如，Django 是一個(gè)十分強(qiáng)大的框架，合適大型項(xiàng)目，而 Flask 則十分笨重，合適快速開發(fā)。關(guān)于 Ruby on Rails 和 Laravel等框架，本文還引見了它們在特定狀況下的應(yīng)用?？偟膩碚f，本文提供了有關(guān)各種Web框架性能的有用信息，能夠協(xié)助開發(fā)人員選擇最合適他們項(xiàng)目的框架。
代碼部署后可能存在的BUG沒法實(shí)時(shí)曉得，事后為理解決這些BUG，花了大量的時(shí)間停止log 調(diào)試，這邊順便給大家引薦一個(gè)好用的BUG監(jiān)控工具 Fundebug。