報告種嘗試闡明幾個關鍵問題：
實際使用中，現代架構的使用和性能如何比較？
架構的選擇是否會影響網站的核心網絡名額？
架構的選擇與JavaScript負載大小有多大關系，會有什麼影響？
報告資料來源于不同的公開資料集：
- Chrome 使用者體驗報告 (CrUX)提供了有關真實 Chrome 使用者如何體驗網絡上熱門目的地的使用者體驗名額。
- HTTP Archive通過定期收集 Lighthouse 性能資料來跟蹤和報告超過 1500 萬個網站的性能。
- Core Web Vitals 技術報告從前兩個資料集中收集了有用的見解。
這份報告，包含六種流行的基于JavaScript的Web架構：Astro、Gatsby、Next.js、Nuxt、Remix和SvelteKit。由于WordPress在網絡上的流行和巨大的市場佔有率 (43.2%)，是以還盡可能包含了來自 WordPress 的資料。
一、核心網絡名額
Google 的 Core Web Vitals (CWV)是一組三個标準化名額，可幫助我們了解使用者如何體驗網頁。每個名額都衡量使用者體驗的不同方面——加載速度、響應能力、視覺穩定性——它們共同量化了網站的整體性能。
Google 的Core Web Vitals Assessment是一項測試，它檢視所有三個名額的真實使用者測量資料（來自CrUX資料集），以确定每個網站的總體通過/未通過等級。一個網站要想通過，它必須在所有三個名額中都達到相關的“好”門檻。如果任何名額未達到門檻值，則該網站未通過評估。
CWV 評估在使用真實世界的使用者資料和測量方面是獨一無二的。這使得它可以更準确地反映使用者實際體驗網站的方式，尤其是在較長的會話期間。Lighthouse 和其他實驗室測試工具隻能測量首頁加載，無法捕捉使用網站的完整體驗。
通過CWV的網站百分比
在研究所有使用特定架構建構的網站時，僅有 Astro 和 SvelteKit 超過了所有測試網站的平均通過率（40.5%）。這其中，隻有 Astro 是唯一一個達到谷歌 CWV 評估 50% 以上架構的網站。Next.js 和 Nuxt 排名墊底，僅有大約 1/4 和 1/5 的網站通過評估。
究竟是什麼原因導緻一個網站無法通過谷歌核心網絡名額評估？可以按單個名額對資料進行細分，去深入了解在網絡名額方面的不同架構存在的問題（和經驗）。
二、首次輸入延遲
通過 FID 的站點百分比
首次輸入延遲 (FID)測量從使用者首次與頁面互動到浏覽器能夠響應該互動的時間。Google 的 CWV 評估尋找 100 毫秒或更短的 FID。任何較慢的東西都被認為需要改進并且未通過評估。
大多數架構都輕松通過了這個測試，超過 90% 或更多的網站通過了評估。沒有架構在此測試中的通過率低于 80%。這意味着大多數被測試的網站都會對第一次使用者互動做出響應。
三、累計布局偏移
Cumulative Layout Shift (CLS)衡量頁面的視覺穩定性。要通過此評估，您應該将意外的布局偏移減少到接近零，進而為您的使用者提供可靠的視覺體驗。
CLS 是 Google 将其作為三個核心網絡生命力之一的有趣名額，因為它與速度或響應能力并不嚴格相關。它的包含強調了在衡量網絡使用者體驗的整體品質時，不僅僅要關注性能的重要性。
所有架構在此名額中的得分都在 50% 或更高。然而，在這個名額上得分最高的是最年輕的架構（Astro、SvelteKit 和 Remix）。在所有測試的網站上，這三者在對該名額的評估中得分超過 75%。
四、最大内容繪畫 (LCP)
Largest Contentful Paint (LCP)是三個 Core Web Vitals 中的最後一個，在感覺性能方面可以說是最重要的。它測量頁面的主要内容可能加載的時間點。通過 Google 的 CWV 評估需要 2.5 秒或更短的 LCP。任何較慢的東西都被認為需要改進并且未通過評估。
LCP 是三個名額中最難掌握的。在所有測試的網站中，隻有 52% 通過了該名額。在我們測試的六個架構中，隻有 Astro 和 SvelteKit 超過了這個平均水準。其餘的低于平均水準。
即将推出？與 Next Paint 的互動 (INP)
Interaction to Next Paint (INP)是一個實驗性的 web vital，用于評估整體網站響應能力，類似于 First Input Delay (FID)。這兩個名額的不同之處在于 INP 觀察使用者與頁面進行的所有互動的延遲，而不僅僅是第一次互動。低 INP 意味着頁面始終能夠快速響應所有（或絕大多數）使用者互動。
雖然 INP 不是當今重要的官方核心網絡，但 Chrome 團隊表示他們希望用 INP 取代 FID，作為一種更全面、更準确的響應能力衡量标準。
五、那麼，這些架構如何與這個新的響應名額相提并論呢？
圖表中最值得注意的是，對于每個架構而言，總體而言，良好的 INP 測量比首次輸入延遲 (FID)更難實作。雖然每個測試架構的 FID 通過率都超過 80%，但沒有一個架構能夠在 INP 上看到相同的 80% 通過率。Astro 最接近，傳球率為 68.8%。
值得注意的是，所有跟蹤網站的平均通過率高達驚人的 60.9%。雖然 Astro 和 WordPress 在上圖中看起來取得了突出的成功，但這些網站實際上僅略高于行業平均水準。為什麼許多經過測試的 Web 架構都難以滿足這個名額？
一個原因可能是單頁應用程式 (SPA) 架構通過 JavaScript 驅動所有導航作為用戶端操作。這為沒有用戶端導航的多頁面應用程式 (MPA) 所沒有的輸入延遲創造了機會。在 MPA 中，導航到新頁面會觸發來自伺服器的完整頁面加載，這未歸類為輸入延遲。這有助于解釋為什麼 Astro 和 WordPress（圖表中的兩個 MPA）在此名額上的表現明顯優于其他測試架構（所有 SPA）。
RebelMouse 的 Anne Burnes 寫了一篇關于 FID 和 INP 之間差別的精彩文章：
FID 量化使用者在嘗試與無響應頁面互動時的體驗，但它僅衡量第一次互動。根據 Google 的說法，INP 通過涵蓋網站的整個互動範圍（從頁面首次開始加載到使用者離開頁面），對網站的響應能力進行了更全面的衡量。這種綜合測量使 INP 成為比 FID 更可靠的站點整體響應能力名額。
INP 的整體性使其比 FID 更難解決，因為您的代碼必須以一種在整個旅程中保護使用者響應的方式實施，而不僅僅是在第一次加載時。由于許多互動是通過 JavaScript 完成的，這意味着您的網站必須小心加載以優化性能。
這在移動裝置上尤其困難。我們檢視了整個行業和我們網站網絡内的一些網站，發現移動 INP 分數平均比 FID 低 35.5%。在檢視同一資料集的桌面性能時，平均僅下降了 14.1%。
— 安妮伯恩斯，RebelMouse
這将是 2023 年值得關注的一個有趣名額，谷歌繼續考慮将 INP 添加為官方 Core Web Vital。
六、燈塔表演
Lighthouse是另一個我們可以用來衡量網站使用者體驗的工具。HTTP Archive 在模拟的移動加載條件下運作 Lighthouse。這提供了更詳細和一緻的頁面加載性能分析，低至 100 毫秒的幾分之一秒。Lighthouse 不是檢視大的“好”與“壞”門檻值和桶，而是為您提供更詳細的性能評分（滿分 100）。
像 Core Web Vitals 這樣的真實使用者資料仍然是真實使用者體驗的最佳衡量标準，您可以在下面的一些圖表中看到真實體驗與實驗室體驗的不同之處。然而，仍然可以從 Lighthouse 提供的額外細節中學到有趣的見解。讓我們來看看資料。
為了保持一緻性，我們保留了上一節中的原始順序。但是，您會注意到 Remix 在 Lighthouse 上的表現似乎比在 CWV 評估中的表現要強得多。對此的一種解釋可能是 Remix 在頁面加載時使用startTransition和requestIdleCallback延遲React hydration。從理論上講，這可以在某些實驗室情況下（如 Lighthouse）轉化為更好的性能，但代價是在其他真實情況下會增加首次輸入延遲。
不幸的是，Lighthouse 性能得分的中值全面偏低。一半的測試架構的中值性能被認為是“差”（49 或以下），而另一半的中值分數“需要改進”（50-89）。沒有架構達到 90+ 的“良好”中值分數。
在所有跟蹤的網站中，性能得分的中位數為 34/100。為此，我們測試的架構中有一半（Astro、SvelteKit 和 Remix）确實高于網際網路平均水準。
通過按百分位數分解資料，我們可以開始看到一些稍微更令人鼓舞的數字，其中 Astro 和 SvelteKit 在 p90 或 p95 百分位數中達到 90+ 的分數。然而，資料清楚地表明，所有網站和架構（包括 Astro）仍然難以在現實世界中取得良好的性能。
七、JavaScript 的成本
我們想要探索的最後一件事是在實際使用中架構選擇、性能和總 JavaScript 負載大小之間的關系。最快的架構往往是那些向用戶端發送最少 JavaScript 的架構嗎？
資料的趨勢很明顯：釋出較少 JavaScript 的網站往往表現更好。然而，有太多因素在起作用，我們無法自信地将這種趨勢與 Web 架構本身的選擇聯系起來。某些架構可能會以不同于其他架構的方式鼓勵/阻止 JavaScript，但在我們得出任何結論之前還需要進行更多的研究。
八、方法論和局限性
該報告是根據幾個公開可用的資料集編制的。您可以在此處了解有關這些資料集及其方法的更多資訊：HTTP 存檔方法、CrUX 方法和CWV 技術報告方法。
由于容量限制，我們的分析隻檢視每個跟蹤網站的首頁。此限制的一個好處是每個分析網站的目的和用例差異較小。然而，一個缺點是這也意味着内部頁面（如/about和/admin/...頁面）和它們使用的技術沒有被分析，是以被排除在我們的分析之外。
本報告中未探讨的另一個限制是架構的年齡對測量的 Web 性能的影響。此處測量的舊架構（Gatsby、Next.js、Nuxt）有更長的遺留網站尾巴運作舊版本的架構，這些舊版本包含在資料集中。這造成了一種情況，即隻有較新的架構（Astro、Remix、SvelteKit）可以假設在過去 1-2 年内運作其軟體的更現代版本。這是我們現有資料的局限性，但我們希望在未來的報告中探索這一點。