大家好，我是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 在網絡上占據市場佔有率 (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 年内運作其軟體的更現代版本，這是現有資料的局限性。
最後
一台電腦,一個鍵盤,盡情揮灑智慧的人生;幾行數字,幾個字母,認真編寫生活的美好;
一 個靈感,一段程式,推動科技進步,促進社會發展。
創作不易，喜歡的老鐵們加個關注，點個贊，打個賞，後面會不定期更新幹貨和技術相關的資訊，速速收藏，謝謝！你們的一個小小舉動就是對小編的認可，更是創作的動力。