這份報(bào)告的目的是查看真實(shí)世界的數(shù)據(jù)，以更好地理解框架選擇、性能和 web 上的實(shí)際用戶體驗(yàn)之間的關(guān)系。本文將嘗試闡明幾個(gè)關(guān)鍵問題：

• 現(xiàn)代 Web 框架在現(xiàn)實(shí)世界的使用和性能方面如何比較？
• 框架選擇會(huì)影響網(wǎng)站的 Core Web Vitals 嗎？
• 框架選擇與 JavaScript 大小有多大關(guān)系，有什么影響？

前言

數(shù)據(jù)

為此，查看了三個(gè)不同的公開數(shù)據(jù)集

• Chrome 用戶體驗(yàn)報(bào)告 (CrUX) [1]：提供了有關(guān)真實(shí) Chrome 用戶如何體驗(yàn) web 上熱門應(yīng)用的用戶體驗(yàn)指標(biāo)。
• HTTP Archive[2] ：通過定期收集 Lighthouse 性能數(shù)據(jù)來跟蹤和報(bào)告超過 1500 萬個(gè)網(wǎng)站的性能。
• Core Web Vitals 技術(shù)報(bào)告[3]：從前兩個(gè)數(shù)據(jù)集中收集了有用的見解。

所有數(shù)據(jù)均來自公共的、獨(dú)立管理的數(shù)據(jù)集。在下面的部分中詳細(xì)了解使用的方法。

框架

為了創(chuàng)建這份報(bào)告，決定研究六種流行的基于 JavaScript 的 Web 框架：Astro、Gatsby、Next.js、Nuxt、Remix 和 SvelteKit。由于 WordPress 在網(wǎng)絡(luò)上的流行和巨大的市場份額 (43.2%)，還盡可能包含了來自 WordPress 的數(shù)據(jù)。

Core Web Vitals

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

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

CWV 評(píng)估在使用真實(shí)世界的用戶數(shù)據(jù)和測量方面是獨(dú)一無二的。這使得它可以更準(zhǔn)確地反映用戶實(shí)際體驗(yàn)網(wǎng)站的方式，尤其是在較長的會(huì)話期間。Lighthouse 和其他測試工具只能測量首頁加載，無法捕捉使用網(wǎng)站的完整體驗(yàn)。

通過 CWV 的站點(diǎn)百分比

當(dāng)查看使用特定框架構(gòu)建的所有已知網(wǎng)站時(shí)，Astro 和 SvelteKit 超過了所有測試網(wǎng)站的平均通過率 (40.5%)。Astro 是唯一一個(gè)達(dá)到 50% 以上的網(wǎng)站通過谷歌 CWV 評(píng)估的框架。Next.js 和 Nuxt 墊底，分別有大約四分之一和五分之一的網(wǎng)站通過了評(píng)估。

網(wǎng)站未能通過 Google 的核心網(wǎng)絡(luò)生命力評(píng)估的最可能原因是什么？我們可以按單個(gè)指標(biāo)分解數(shù)據(jù)，以深入了解不同框架在 Web Vitals 方面的失敗（或成功）之處。

First Input Delay (FID)

通過 FID 的站點(diǎn)百分比

First Input Delay (FID) 即首次輸入延遲，其測量從用戶首次與頁面交互到瀏覽器能夠響應(yīng)該交互的時(shí)間。Google 的 CWV 評(píng)估尋找 100 毫秒或更短的 FID。任何較慢的網(wǎng)站都被認(rèn)為需要改進(jìn)并且未通過評(píng)估。

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

Cumulative Layout Shift (CLS)

通過 CLS 的站點(diǎn)百分比

Cumulative Layout Shift (CLS) 意為累計(jì)布局偏移，其主要衡量頁面的視覺穩(wěn)定性。要通過此評(píng)估，應(yīng)該將意外的布局偏移減少到接近零，從而為用戶提供可靠的視覺體驗(yàn)。

CLS 是 Google 將其作為三個(gè) Core Web Vitals 之一的有趣指標(biāo)，因?yàn)樗c速度或響應(yīng)能力并不嚴(yán)格相關(guān)。它的包含強(qiáng)調(diào)了在衡量網(wǎng)絡(luò)用戶體驗(yàn)的整體質(zhì)量時(shí)，不僅僅關(guān)注性能的重要性。

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

Largest Contentful Paint (LCP)

通過 LCP 的站點(diǎn)百分比

Largest Contentful Paint (LCP) 意為最大內(nèi)容繪制，其是三個(gè) Core Web Vitals 中的最后一個(gè)，在感知性能方面可以說是最重要的。它衡量頁面主要內(nèi)容可能加載的時(shí)間點(diǎn)。通過 Google 的 CWV 評(píng)估需要 2.5 秒或更短的 LCP，任何較慢的網(wǎng)站都被認(rèn)為需要改進(jìn)并且未通過評(píng)估。

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

Interaction to Next Paint (INP)

Interaction to Next Paint (INP) 意為與與下一次繪制的交互，其是一個(gè)實(shí)驗(yàn)性的 web vital，用于評(píng)估整體網(wǎng)站響應(yīng)能力，類似于 First Input Delay (FID)。這兩個(gè)指標(biāo)的不同之處在于 INP 觀察用戶與頁面進(jìn)行的所有交互的延遲，而不僅僅是第一次交互。低 INP 意味著頁面始終能夠快速響應(yīng)所有（或絕大多數(shù)）用戶交互。

雖然 INP 不是當(dāng)今重要的官方 web vital，但 Chrome 團(tuán)隊(duì)已表示希望用 INP 取代 FID，作為更全面、更準(zhǔn)確的響應(yīng)能力衡量標(biāo)準(zhǔn)。

那么，這些框架在這個(gè)新的響應(yīng)指標(biāo)中表現(xiàn)又如何呢？

通過 INP 的站點(diǎn)百分比

圖表中最值得注意的是，對于每個(gè)框架而言，總體而言，良好的 INP 測量比首次輸入延遲 (FID) 更難實(shí)現(xiàn)。雖然每個(gè)測試框架的 FID 通過率都超過 80%，但沒有一個(gè)框架能夠在 INP 上看到相同的 80% 通過率。Astro 最接近，通過率為 68.8%。

值得注意的是，所有跟蹤網(wǎng)站的平均通過率高達(dá)驚人的 60.9%。雖然 Astro 和 WordPress 在上表中看起來取得了突出的成功，但這些網(wǎng)站實(shí)際上僅略高于行業(yè)平均水平。為什么許多經(jīng)過測試的 Web 框架都難以滿足這個(gè)指標(biāo)？

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

FID 和 INP 之間區(qū)別如下：

FID 量化用戶在嘗試與無響應(yīng)頁面交互時(shí)的體驗(yàn)，但它僅衡量第一次交互。根據(jù)谷歌的說法，INP 通過涵蓋網(wǎng)站的整個(gè)交互范圍，從頁面首次開始加載到用戶離開頁面，對網(wǎng)站的響應(yīng)能力進(jìn)行了更全面的衡量。這種綜合測量使 INP 成為比 FID 更可靠的站點(diǎn)整體響應(yīng)能力指標(biāo)。

INP 的整體性使其比 FID 更難解決，因?yàn)榇a必須以一種在整個(gè)過程中保護(hù)用戶響應(yīng)的方式實(shí)施，而不僅僅是在第一次加載時(shí)。由于許多交互是通過 JavaScript 完成的，這意味著網(wǎng)站必須小心加載以優(yōu)化性能。

這在移動(dòng)設(shè)備上尤其困難。我們查看了整個(gè)行業(yè)和我們站點(diǎn)網(wǎng)絡(luò)內(nèi)的一些站點(diǎn)，發(fā)現(xiàn)移動(dòng) INP 分?jǐn)?shù)平均比 FID 低 35.5%。在查看同一數(shù)據(jù)集的桌面性能時(shí)，平均僅下降了 14.1%。

這將是 2023 年值得關(guān)注的一個(gè)有趣指標(biāo)，谷歌繼續(xù)考慮將 INP 添加為官方 Core Web Vital。

Lighthouse 性能

Lighthouse 是另一個(gè)可以用來衡量網(wǎng)站用戶體驗(yàn)的工具。HTTP Archive 在模擬的移動(dòng)加載條件下運(yùn)行 Lighthouse。這提供了更詳細(xì)和一致的頁面加載性能分析，低至 100 毫秒的幾分之一秒，Lighthouse 提供更詳細(xì)的性能評(píng)分（滿分 100）。

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

Lighthouse 性能得分，中位數(shù)

為了保持一致性，保留了上一節(jié)中的原始順序。但是，可以看到，Remix 在 Lighthouse 上的表現(xiàn)似乎比在 CWV 評(píng)估中的表現(xiàn)要強(qiáng)得多。對此的一種解釋可能是 Remix 使用 startTransition? 和 requestIdleCallback 來延遲頁面加載時(shí)的 React 水合作用。從理論上講，這可以在某些實(shí)驗(yàn)室情況下（如 Lighthouse）轉(zhuǎn)化為更好的性能，但代價(jià)是在其他真實(shí)情況下會(huì)增加首次輸入延遲。

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

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

Lighthouse 性能得分

通過按百分位數(shù)分解數(shù)據(jù)，可以看到一些稍微更令人鼓舞的數(shù)字，其中 Astro 和 SvelteKit 在 p90 或 p95 百分位數(shù)中達(dá)到 90+ 的分?jǐn)?shù)。然而，數(shù)據(jù)清楚地表明，所有網(wǎng)站和框架（包括 Astro）仍然難以在現(xiàn)實(shí)世界中取得良好的性能。

JavaScript 大小影響

本文最后要探索的一件事是在實(shí)際使用中框架選擇、性能和總 JavaScript 大小之間的關(guān)系。最快的框架往往是那些向客戶端發(fā)送最少 JavaScript 的框架嗎？

JavaScript 的中位數(shù) KB 與通過 CWV 的站點(diǎn)百分比

數(shù)據(jù)的趨勢很明顯：具有較少 JavaScript 的網(wǎng)站往往表現(xiàn)更好。然而，有太多因素在起作用，無法將這種趨勢與 Web 框架本身的選擇聯(lián)系起來。某些框架可能會(huì)以不同于其他框架的方式鼓勵(lì)/阻止 JavaScript，在得出任何結(jié)論之前還需要進(jìn)行更多的研究。

方法論和局限性

該報(bào)告是根據(jù)幾個(gè)公開可用的數(shù)據(jù)集編制的。由于容量限制，分析只查看每個(gè)跟蹤網(wǎng)站的主頁。此限制的一個(gè)好處是每個(gè)分析網(wǎng)站的目的和用例差異較小。然而，一個(gè)缺點(diǎn)是這也意味著內(nèi)部頁面（如 /about 和 /admin/... pages）和它們使用的技術(shù)未被分析，因此被排除在分析之外。

本報(bào)告中未探討的另一個(gè)限制是框架的年齡對測量的網(wǎng)絡(luò)性能的影響。本文測量的舊框架（Gatsby、Next.js、Nuxt）有更長的遺留網(wǎng)站運(yùn)行舊版本的框架，這些舊版本包含在數(shù)據(jù)集中。這造成了一種情況，即只有較新的框架（Astro、Remix、SvelteKit）可以假設(shè)在過去 1-2 年內(nèi)運(yùn)行其軟件的更現(xiàn)代版本，這是現(xiàn)有數(shù)據(jù)的局限性。

參考資料

[1]Chrome 用戶體驗(yàn)報(bào)告 (CrUX) : https://developer.chrome.com/docs/crux/

[2]HTTP Archive: https://httparchive.org/

[3]Core Web Vitals 技術(shù)報(bào)告: https://discuss.httparchive.org/t/new-dashboard-the-core-web-vitals-technology-report/2178

[4]https://astro.build/blog/2023-web-framework-performance-report/