大家好，我是Echa。
好消息，Astro 官網Blog 中 Fred Schott 大佬發文公布了 Web 框架性能報告清單，如何讓前端開發者們更好的選擇前端框架，以及相關性能和在Web 上整體運作流程和用戶交互體驗的關系。主要是從三個方面問題去分析：
- 現代流行的Web 框架在使用中和性能方面如何比較？
- Web 框架的選擇會直接影響到底層加載速度嗎？
- Web 框架和JAVAScript大小有直接關系嗎？有什么影響？
- 數據來源
- 對比Web框架
- 前端性能分析
- JavaScript 大小影響
- 報告總結
web 框架性能報告主要從三個不同的公開數據收集而來的：
- Chrome 用戶體驗報告 (CrUX) ：提供了有關證實 Chrome 用戶如何體驗 web 上熱門應用的用戶體驗指標。
- HTTP Archive：通過定期收集 Lighthouse 性能數據來跟蹤和報告超過 1500 萬個網站的性能。
- Core Web Vitals 技術報告：從前兩個數據集中收集了有用的見解。
所有數據均來自公共的、獨立管理的數據集。在下面的部分中詳細了解使用的方法。
對比Web框架
Fred Schott 大佬為了制作這份最新的 web 框架性能報告，就研究了六種現代流行的基于 JavaScript 的 Web 框架：Astro、Gatsby、Next.js、Nuxt、Remix和SvelteKit，進行多項指標的評測，另外，wordPress/ target=_blank class=infotextkey>WordPress 在網絡上占據市場份額 (43.2%)，還盡可能包含了來自 WordPress 的數據，這樣數據會更精準點。其中在研究所有使用特定框架構建的網站時，僅有 Astro 和 SvelteKit 超過了所有測試網站的平均通過率（40.5%）
Astro
官網地址：https://astro.build/
Github：https://github.com/withastro/astro
Astro 更詳細的介紹，請見：Astro 2.0正式發布
Gatsby
官網地址：https://www.gatsbyjs.com/
Github：https://github.com/gatsbyjs/gatsby
Next.js
官網網址：https://nextjs.org/
Github：https://github.com/vercel/next.js
Next.js 更詳細的介紹，請見：Next.js 13.2 正式發布
Nuxt
官網地址：https://nuxt.com/
Github：https://github.com/nuxt/nuxt
Nuxt更詳細的介紹，請見：Nuxt 3.2.0 正式發布
Remix
官網地址：http://remix.run/
Github： https://github.com/remix-run
SvelteKit
官網地址： https://svelte.dev/
Github： https://github.com/sveltejs/svelte
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 方面的失敗（或成功）之處。
通過 FID 的站點百分比
首次輸入延遲（FID）是用來衡量用戶首次與頁面互動到瀏覽器能夠作出反應的時間。谷歌的 CWV 評估力求的是 100 毫秒或更少的 FID。任何較慢的速度在其眼中都是需要改進且無法通過評估的。
大多數框架和網站都順利通過了這一評估。在此次測試中，沒有通過率低于 80% 的框架。這也說明大多數測試的網站都對第一次用戶交互做出了響應。
Cumulative Layout Shift (CLS) 意為累計布局偏移，其主要衡量頁面的視覺穩定性。要通過此評估，應該將意外的布局偏移減少到接近零，從而為用戶提供可靠的視覺體驗。
CLS 是 Google 將其作為三個 Core Web Vitals 之一的有趣指標，因為它與速度或響應能力并不嚴格相關。它的包含強調了在衡量網絡用戶體驗的整體質量時，不僅僅關注性能的重要性。
所有框架在此指標中的得分都在 50% 或更高。然而，在這個指標上得分最高的是最年輕的框架（Astro、SvelteKit 和 Remix）。在所有測試的網站上，這三者在對該指標的評估中得分超過 75%。
最大內容繪制（LCP）是最后一個核心網絡指標，在感知性能方面可以說是最重要的。它用來衡量頁面主要內容可能已加載的時間點。想要通過谷歌 CWV 評估，2.5 秒或更少的 LCP 是必要條件。
LCP 是三個指標中最難掌握的一個。在所有測試的網站中，只有 52% 的網站通過了這一指標。在我們測試的六個框架中，只有 Astro 和 SvelteKit 超過了這個平均水平，其余的都低于平均水平。
即將推出與下一個繪制的交互（INP）
Interaction to Next Paint (INP) 意為與與下一次繪制的交互，其是一個實驗性的 web vital，用于評估整體網站響應能力，類似于 First Input Delay (FID)。這兩個指標的不同之處在于 INP 觀察用戶與頁面進行的所有交互的延遲，而不僅僅是第一次交互。低 INP 意味著頁面始終能夠快速響應所有（或絕大多數）用戶交互。
雖然 INP 不是當今重要的官方 web vital，但 Chrome 團隊已表示希望用 INP 取代 FID，作為更全面、更準確的響應能力衡量標準。
那么，這些框架在這個新的響應指標中表現又如何呢？
根據圖表情況，對于每個框架來說，在總體上，良好的 INP 測量比首次輸入延遲（FID）更難實現。雖然每個測試的框架在 FID 上都有80%以上的通過率，但在 INP 上卻沒有一個能做到。唯一接近的只有 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 作為官方的核心頁面指標。
前端性能分析
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 的網站往往表現更好。然而，有太多因素在起作用，無法將這種趨勢與 Web 框架本身的選擇聯系起來。某些框架可能會以不同于其他框架的方式鼓勵/阻止 JavaScript，在得出任何結論之前還需要進行更多的研究。
報告總結
該報告是根據幾個公開可用的數據集編制的。由于容量限制，分析只查看每個跟蹤網站的主頁。此限制的一個好處是每個分析網站的目的和用例差異較小。然而，一個缺點是這也意味著內部頁面（如 /about 和 /admin/... pages）和它們使用的技術未被分析，因此被排除在分析之外。
本報告中未探討的另一個限制是框架的年齡對測量的網絡性能的影響。本文測量的舊框架（Gatsby、Next.js、Nuxt）有更長的遺留網站運行舊版本的框架，這些舊版本包含在數據集中。這造成了一種情況，即只有較新的框架（Astro、Remix、SvelteKit）可以假設在過去 1-2 年內運行其軟件的更現代版本，這是現有數據的局限性。
最后
一臺電腦,一個鍵盤,盡情揮灑智慧的人生;幾行數字,幾個字母,認真編寫生活的美好;
一 個靈感,一段程序,推動科技進步,促進社會發展。
創作不易，喜歡的老鐵們加個關注，點個贊，打個賞，后面會不定期更新干貨和技術相關的資訊，速速收藏，謝謝！你們的一個小小舉動就是對小編的認可，更是創作的動力。
