這份報告的目的是查看真實世界的數據,以更好地理解框架選擇、性能和 web 上的實際用戶體驗之間的關系。本文將嘗試闡明幾個關鍵問題:
- 現代 Web 框架在現實世界的使用和性能方面如何比較?
- 框架選擇會影響網站的 Core Web Vitals 嗎?
- 框架選擇與 JAVAScript 大小有多大關系,有什么影響?
前言
數據
為此,查看了三個不同的公開數據集
- Chrome 用戶體驗報告 (CrUX) [1]:提供了有關真實 Chrome 用戶如何體驗 web 上熱門應用的用戶體驗指標。
- HTTP Archive[2] :通過定期收集 Lighthouse 性能數據來跟蹤和報告超過 1500 萬個網站的性能。
- Core Web Vitals 技術報告[3]:從前兩個數據集中收集了有用的見解。
所有數據均來自公共的、獨立管理的數據集。在下面的部分中詳細了解使用的方法。
框架
為了創建這份報告,決定研究六種流行的基于 JavaScript 的 Web 框架:Astro、Gatsby、Next.js、Nuxt、Remix 和 SvelteKit。由于 wordPress/ target=_blank class=infotextkey>WordPress 在網絡上的流行和巨大的市場份額 (43.2%),還盡可能包含了來自 WordPress 的數據。
Core Web Vitals
google 的 Core Web Vitals (CWV) 是一組三個標準化指標,可幫助了解用戶如何體驗網頁。每個指標衡量用戶體驗的不同方面——加載速度、響應能力、視覺穩定性,它們共同量化了網站的整體性能。
谷歌的 Core Web Vitals Assessment 是一項測試,它查看所有三個指標的真實用戶測量數據(來自 CrUX 數據集),以確定每個網站的總體通過/未通過等級。一個網站要想通過,它必須在所有三個指標中都達到相關的“好”門檻。如果任何指標未達到閾值,則該網站未通過評估。
CWV 評估在使用真實世界的用戶數據和測量方面是獨一無二的。這使得它可以更準確地反映用戶實際體驗網站的方式,尤其是在較長的會話期間。Lighthouse 和其他測試工具只能測量首頁加載,無法捕捉使用網站的完整體驗。
通過 CWV 的站點百分比
當查看使用特定框架構建的所有已知網站時,Astro 和 SvelteKit 超過了所有測試網站的平均通過率 (40.5%)。Astro 是唯一一個達到 50% 以上的網站通過谷歌 CWV 評估的框架。Next.js 和 Nuxt 墊底,分別有大約四分之一和五分之一的網站通過了評估。
網站未能通過 Google 的核心網絡生命力評估的最可能原因是什么?我們可以按單個指標分解數據,以深入了解不同框架在 Web Vitals 方面的失?。ɑ虺晒Γ┲?。
First Input Delay (FID)
通過 FID 的站點百分比
First Input Delay (FID) 即首次輸入延遲,其測量從用戶首次與頁面交互到瀏覽器能夠響應該交互的時間。Google 的 CWV 評估尋找 100 毫秒或更短的 FID。任何較慢的網站都被認為需要改進并且未通過評估。
大多數框架都輕松通過這個測試,超過 90% 或更多的網站通過了評估。沒有框架在此測試中的通過率低于 80%。這意味著大多數被測試的網站都會對第一次用戶交互做出響應。
Cumulative Layout Shift (CLS)
通過 CLS 的站點百分比
Cumulative Layout Shift (CLS) 意為累計布局偏移,其主要衡量頁面的視覺穩定性。要通過此評估,應該將意外的布局偏移減少到接近零,從而為用戶提供可靠的視覺體驗。
CLS 是 Google 將其作為三個 Core Web Vitals 之一的有趣指標,因為它與速度或響應能力并不嚴格相關。它的包含強調了在衡量網絡用戶體驗的整體質量時,不僅僅關注性能的重要性。
所有框架在此指標中的得分都在 50% 或更高。然而,在這個指標上得分最高的是最年輕的框架(Astro、SvelteKit 和 Remix)。在所有測試的網站上,這三者在對該指標的評估中得分超過 75%。
Largest Contentful Paint (LCP)
通過 LCP 的站點百分比
Largest Contentful Paint (LCP) 意為最大內容繪制,其是三個 Core Web Vitals 中的最后一個,在感知性能方面可以說是最重要的。它衡量頁面主要內容可能加載的時間點。通過 Google 的 CWV 評估需要 2.5 秒或更短的 LCP,任何較慢的網站都被認為需要改進并且未通過評估。
LCP 是三個指標中最難通過的。在所有測試的網站中,只有 52% 通過了該指標。在測試的六個框架中,只有 Astro 和 SvelteKit 超過了這個平均水平,其余的低于平均水平。
Interaction to Next Paint (INP)
Interaction to Next Paint (INP) 意為與與下一次繪制的交互,其是一個實驗性的 web vital,用于評估整體網站響應能力,類似于 First Input Delay (FID)。這兩個指標的不同之處在于 INP 觀察用戶與頁面進行的所有交互的延遲,而不僅僅是第一次交互。低 INP 意味著頁面始終能夠快速響應所有(或絕大多數)用戶交互。
雖然 INP 不是當今重要的官方 web vital,但 Chrome 團隊已表示希望用 INP 取代 FID,作為更全面、更準確的響應能力衡量標準。
那么,這些框架在這個新的響應指標中表現又如何呢?
通過 INP 的站點百分比
圖表中最值得注意的是,對于每個框架而言,總體而言,良好的 INP 測量比首次輸入延遲 (FID) 更難實現。雖然每個測試框架的 FID 通過率都超過 80%,但沒有一個框架能夠在 INP 上看到相同的 80% 通過率。Astro 最接近,通過率為 68.8%。
值得注意的是,所有跟蹤網站的平均通過率高達驚人的 60.9%。雖然 Astro 和 WordPress 在上表中看起來取得了突出的成功,但這些網站實際上僅略高于行業平均水平。為什么許多經過測試的 Web 框架都難以滿足這個指標?
一個原因可能是單頁應用程序 (SPA) 架構通過 JavaScript 驅動所有導航作為客戶端操作。這為沒有客戶端導航的多頁面應用程序 (MPA) 所沒有的輸入延遲創造了機會。在 MPA 中,導航到新頁面會觸發來自服務器的完整頁面加載,這不屬于輸入延遲。這有助于解釋為什么 Astro 和 WordPress(圖表中的兩個 MPA)在此指標上的表現明顯優于其他測試框架(所有 SPA)。
FID 和 INP 之間區別如下:
FID 量化用戶在嘗試與無響應頁面交互時的體驗,但它僅衡量第一次交互。根據谷歌的說法,INP 通過涵蓋網站的整個交互范圍,從頁面首次開始加載到用戶離開頁面,對網站的響應能力進行了更全面的衡量。這種綜合測量使 INP 成為比 FID 更可靠的站點整體響應能力指標。
INP 的整體性使其比 FID 更難解決,因為代碼必須以一種在整個過程中保護用戶響應的方式實施,而不僅僅是在第一次加載時。由于許多交互是通過 JavaScript 完成的,這意味著網站必須小心加載以優化性能。
這在移動設備上尤其困難。我們查看了整個行業和我們站點網絡內的一些站點,發現移動 INP 分數平均比 FID 低 35.5%。在查看同一數據集的桌面性能時,平均僅下降了 14.1%。
這將是 2023 年值得關注的一個有趣指標,谷歌繼續考慮將 INP 添加為官方 Core Web Vital。
Lighthouse 性能
Lighthouse 是另一個可以用來衡量網站用戶體驗的工具。HTTP Archive 在模擬的移動加載條件下運行 Lighthouse。這提供了更詳細和一致的頁面加載性能分析,低至 100 毫秒的幾分之一秒,Lighthouse 提供更詳細的性能評分(滿分 100)。
像 Core Web Vitals 這樣的真實用戶數據仍然是真實用戶體驗的最佳衡量標準,可以在下面的一些圖表中看到真實體驗與實驗體驗的不同之處。然而,仍然可以從 Lighthouse 提供的額外細節中學到有趣的見解。讓我們來看看數據。
Lighthouse 性能得分,中位數
為了保持一致性,保留了上一節中的原始順序。但是,可以看到,Remix 在 Lighthouse 上的表現似乎比在 CWV 評估中的表現要強得多。對此的一種解釋可能是 Remix 使用 startTransition? 和 requestIdleCallback 來延遲頁面加載時的 React 水合作用。從理論上講,這可以在某些實驗室情況下(如 Lighthouse)轉化為更好的性能,但代價是在其他真實情況下會增加首次輸入延遲。
不幸的是,Lighthouse 性能得分的中值全面偏低。一半的測試框架的中值性能被認為是“差”(49 或以下),而另一半的中值分數“需要改進”(50-89)。沒有框架達到 90+ 的“良好”中值分數。
在所有跟蹤的網站中,性能得分的中位數為 34/100。為此,測試的框架中有一半(Astro、SvelteKit 和 Remix)確實高于互聯網平均水平。
Lighthouse 性能得分
通過按百分位數分解數據,可以看到一些稍微更令人鼓舞的數字,其中 Astro 和 SvelteKit 在 p90 或 p95 百分位數中達到 90+ 的分數。然而,數據清楚地表明,所有網站和框架(包括 Astro)仍然難以在現實世界中取得良好的性能。
JavaScript 大小影響
本文最后要探索的一件事是在實際使用中框架選擇、性能和總 JavaScript 大小之間的關系。最快的框架往往是那些向客戶端發送最少 JavaScript 的框架嗎?
JavaScript 的中位數 KB 與通過 CWV 的站點百分比
數據的趨勢很明顯:具有較少 JavaScript 的網站往往表現更好。然而,有太多因素在起作用,無法將這種趨勢與 Web 框架本身的選擇聯系起來。某些框架可能會以不同于其他框架的方式鼓勵/阻止 JavaScript,在得出任何結論之前還需要進行更多的研究。
方法論和局限性
該報告是根據幾個公開可用的數據集編制的。由于容量限制,分析只查看每個跟蹤網站的主頁。此限制的一個好處是每個分析網站的目的和用例差異較小。然而,一個缺點是這也意味著內部頁面(如 /about 和 /admin/... pages)和它們使用的技術未被分析,因此被排除在分析之外。
本報告中未探討的另一個限制是框架的年齡對測量的網絡性能的影響。本文測量的舊框架(Gatsby、Next.js、Nuxt)有更長的遺留網站運行舊版本的框架,這些舊版本包含在數據集中。這造成了一種情況,即只有較新的框架(Astro、Remix、SvelteKit)可以假設在過去 1-2 年內運行其軟件的更現代版本,這是現有數據的局限性。
參考資料
[1]Chrome 用戶體驗報告 (CrUX) : https://developer.chrome.com/docs/crux/
[2]HTTP Archive: https://httparchive.org/
[3]Core Web Vitals 技術報告: https://discuss.httparchive.org/t/new-dashboard-the-core-web-vitals-technology-report/2178
[4]https://astro.build/blog/2023-web-framework-performance-report/