【CSDN 編者按】基于某些資料基準更好地選擇架構、性能和網絡上實際使用者體驗之間的關系。
原文連結：https://astro.build/blog/2023-web-framework-performance-report/
未經允許，禁止轉載！
整理 | 王子彧出品 | CSDN（ID：CSDNnews）随着 Web 開發的高速發展，越來越多的前端渲染架構出現在了開發者的視野中。這些架構的衆多功能往往能夠幫助開發者建構高性能、可擴充和易于維護的 Web 應用程式，提高開發效率和使用者體驗。近日，《2023 Web 架構性能報告》新鮮出爐。對當下流行的 JavaScript 架構 Astro、Gatsby、Next.js、Nuxt、Remix 和 SvelteKit 進行多項名額的評測，其中在研究所有使用特定架構建構的網站時，僅有 Astro 和 SvelteKit 超過了所有測試網站的平均通過率（40.5%）；在累積布局偏移（CLS）名額上，最新的架構（ Astro、SvelteKit 和 Remix ）表現出色；在最難掌握的 LCP 上， 也是僅有 Astro 和 SvelteKit 超過了這個平均水準。由此可見，此次評測中，Astro 和 SvelteKit 表現較為出色。 而 INP 成為 2023 年值得關注的一個名額。
關鍵問題
首先，試圖闡明幾個關鍵問題。
- 在現實生活中，現代網絡架構的使用和性能如何比較？
- 架構的選擇是否會影響網站的核心網絡名額？
- 架構的選擇與 JavaScript 有效負載的大小有什麼關系，會帶來什麼影響？
資料
為此，我們研究了三個不同的公開資料集。
- 谷歌使用者體驗報告 （CrUX）提供使用者體驗名額，用來說明谷歌使用者實際是如何體驗網絡上的熱門目标頁面；
- HTTP 存檔通過定期收集 Lighthouse 的性能資料，對超過 15 萬個網站的性能進行跟蹤和報告；
- 核心網絡名額技術報告收集了前兩個資料集的有益見解。
所有資料均由獨立管理的公共資料集中收集，Astro 團隊并沒有直接測量性能資料。在下面的章節中，我們可以了解到更多。
核心網絡名額
谷歌的核心網絡名額（CWV）是一組三個标準化的名額，能夠幫助了解使用者體驗網頁的方式。每個名額都衡量着不同方面的使用者體驗——加載速度、響應能力、視覺穩定性——它們共同量化了網站的整體性能。
谷歌的核心網絡名額評估是一個關于真實使用者測量資料的測試（來自 CrUX 資料集），用來确定每個網站的總體合格/不合格等級。網站若想要達到合格，則必須三個名額都達到“良好”。如果有任一名額未達到門檻值，則無法通過評估。
CWV 評估的獨特之處在于它使用了真實的使用者資料和測量，能更準确地反映使用者對網站的長期實際體驗。而 Lighthouse 和其他實驗室測試工具隻能測量首頁的負載，無法捕獲使用網站的完整體驗。
通過 CWV 的網站百分比
在研究所有使用特定架構建構的網站時，僅有 Astro 和 SvelteKit 超過了所有測試網站的平均通過率（40.5%）。這其中，隻有 Astro 是唯一一個達到谷歌 CWV 評估 50% 以上架構的網站。Next.js 和 Nuxt 排名墊底，僅有大約 1/4 和 1/5 的網站通過評估。
究竟是什麼原因導緻一個網站無法通過谷歌核心網絡名額評估？我們可以按單個名額對資料進行細分，去深入了解在網絡名額方面的不同架構存在的問題（和經驗）。
首次輸入延遲 （FID）
通過 FID 的網站百分比
首次輸入延遲（FID）是用來衡量使用者首次與頁面互動到浏覽器能夠作出反應的時間。谷歌的 CWV 評估力求的是 100 毫秒或更少的 FID。任何較慢的速度在其眼中都是需要改進且無法通過評估的。
大多數架構和網站都順利通過了這一評估。在此次測試中，沒有通過率低于 80% 的架構。這也說明大多數測試的網站都對第一次使用者互動做出了響應。
累積布局偏移 （CLS）
通過 CLS 的網站百分比
累積布局偏移（CLS）是用來衡量頁面的視覺穩定性。要通過這個評估，需要将布局偏移減少到接近零，才能為使用者提供一個可靠的視覺體驗。
CLS 對于谷歌來說是一個有趣的名額，因為從嚴格意義上來說，它與速度或響應能力沒有關系，是以被列為三個核心網絡名額之一。它的加入強調了在衡量網絡使用者體驗的整體品質時，要關注性能的重要性。
所有的架構在這個名額上的得分都在 50% 以上。在所有測試的網站中，最新的架構（ Astro、SvelteKit 和 Remix ）在該名額上得分最高，均超過75%。
最大内容繪制 (LCP)
通過 LCP 的網站百分比
最大内容繪制（LCP）是最後一個核心網絡名額，在感覺性能方面可以說是最重要的。它用來衡量頁面主要内容可能已加載的時間點。想要通過谷歌 CWV 評估，2.5 秒或更少的 LCP 是必要條件。
LCP 是三個名額中最難掌握的一個。在所有測試的網站中，隻有 52% 的網站通過了這一名額。在我們測試的六個架構中，隻有 Astro 和 SvelteKit 超過了這個平均水準，其餘的都低于平均水準。
即将推出? 與下一個繪制的互動（INP）
與下一個繪制的互動 （INP）是一個實驗性的網絡名額，用于評估網站的整體響應能力，類似于首次輸入延遲 （FID）。這兩個名額的不同之處在于，INP 觀察的是使用者與頁面進行的所有互動的延遲，而不僅僅是首次互動的延遲。低 INP 意味着頁面能夠持續快速響應所有或絕大部分的使用者互動。
雖然 INP 現在不是官方核心網絡，但谷歌團隊已經表明，為了達到更全面、更準确的響應能力衡量标準，他們希望用 INP 取代 FID。
那麼，這些架構如何與這個新的響應能力名額相提并論呢？
通過 INP 的網站百分比
根據圖表情況，對于每個架構來說，在總體上，良好的 INP 測量比首次輸入延遲（FID）更難實作。雖然每個測試的架構在 FID 上都有80%以上的通過率，但在 INP 上卻沒有一個能做到。唯一接近的隻有 Astro，通過率為68.8%。
值得注意的是，所有跟蹤的網站平均通過率都高達 60.9%。雖然 Astro 和 WordPress 在上圖中看起來略勝一籌，但這些網站實際上隻是略微高于行業平均水準。為什麼許多測試的網絡架構都難以使用此名額？
其中一個原因可能是，單頁應用程式（SPA）架構通過 JavaScript 驅動所有的導航來作為用戶端動作。這為沒有用戶端導航的多頁應用 （MPA） 沒有的輸入延遲創造了機會。在 MPA 中，導航到新的頁面會觸發來自伺服器的整頁加載，這并不屬于輸入延遲。這可以有助于解釋為什麼 Astro 和 WordPress（圖表中的兩個 MPA ）在這個名額上的表現明顯優于其他被測試的架構（所有 SPA ）。
RebelMouse 的 Anne Burnes 有一篇關于 FID 和 INP 差別的文章。
FID 量化了使用者在嘗試與無響應的頁面互動時的體驗，但它僅測量了首次互動。根據谷歌的說法，INP 通過覆寫網站的整個互動範圍來更全面地衡量網站的響應能力，從頁面首次開始加載到使用者離開頁面。這種全面的測量使 INP 成為比 FID 更可靠的網站整體響應能力名額。
INP 的整體性使得它比 FID 更具挑戰性，因為你必須通過保護使用者在整個過程中的響應能力的方式來實作代碼，而不僅僅是在第一次加載時。由于許多互動都是通過 JavaScript 完成的，是以你的網站必須仔細加載來優化性能。
這在移動端更加困難。我們看了一下整個行業和我們的一些網站，發現移動端 INP 的平均得分比 FID 差35.5%。在檢視同一資料集的桌面性能時，平均隻下降了14.1%。
- Anne Burnes, RebelMouse
這是 2023 年值得關注的一個名額，谷歌繼續考慮将 INP 作為官方的核心頁面名額。
前端性能
Lighthouse 是我們可以用來衡量網站使用者體驗的另一種工具。HTTP Archive 在模拟的移動加載條件下運作 Lighthouse，并且提供了精确到100毫秒的零頭的詳細和一緻頁面加載性能分析。Lighthouse 提供的了更詳細的性能評分（滿分 100 分），而不是 "好 "與 "壞 "的門檻值和存儲空間。
核心頁面名額的真實使用者資料仍然是衡量真實使用者體驗的最佳名額，在下面的一些圖表中可以看到真實體驗與實驗室體驗的不同之處。然而，從 Lighthouse 提供的額外細節中仍然可以了解到一些有趣的見解。讓我們來看看這些資料。
前端性能得分，中值
為了保持一緻性，我們保留了上一節中的原始順序。但是，你會注意到，Remix 在 Lighthouse 上的性能表現比它在 CWV 評估中要強得多。對此，一種解釋可能是，Remix 使用 startTransition 和 requestIdleCallback 來推遲頁面加載時的反應水化。理論上，在某些實驗室情況中（如 Lighthouse ）可以轉化為更好的性能，而在其他實際情況下，則會增加首次輸入延遲。
不幸的是，Lighthouse 的性能得分中位數全面偏低。測試的架構中有一半中值被認為是“差”（49分或以下），而另一半的中值得分為“需要改進”（50-89）。沒有架構達到90＋的 "良好 "中值
在所有跟蹤的網站中，性能得分的中值是34/100。是以，我們測試的架構（ Astro，SvelteKit 和 Remix ）中有一半确實高于網際網路平均水準。
前端性能得分，細分
通過将資料按百分位數進行細分，我們可以開始看到一些稍微興奮的數字，Astro 和 SvelteKit 在 p90 或 p95 百分位數中達到了90分以上。然而，資料清楚地表明，所有網站和架構（包括 Astro）仍然難以在現實生活中達到良好的性能。
JavaScript 的成本
最後，我們想探讨的是架構選擇、性能和實際使用中 JavaScript 總有效負載大小之間的關系。那麼，最快的架構是否是向用戶端發送最少的 JavaScript 的架構？
JavaScript 的中位數 KB 與通過 CWV 的網站百分比
資料的趨勢很明顯：JavaScript 釋出較少的網站往往表現更好。然而，基于複雜因素，我們無法自信地将這一趨勢與選擇的網絡架構本身聯系起來，可能 JavaScript 在某些架構中并不适配。是以，在得出具體結論之前，我們仍需要多研究。
方法和局限性
本報告是根據幾個公開的資料集彙編而成。您可以在此了解有關這些資料集及其方法的更多資訊：HTTP 存檔方法, CrUX 方法論 和 CWV 技術報告方法。
由于能力有限，我們隻着眼于對每個跟蹤網站的首頁進行分析。唯一好處是，每個分析網站的目的和使用情況的差異較小。當然，也有局限性，這也意味着内部頁面及其使用的技術被我們排除分析之外。
本報告中沒有探讨的另一個局限性是架構的使用年限對測量的網絡性能的影響。這裡測量的舊架構（Gatsby，Next.js，Nuxt）有一個較長的尾巴，即運作其架構舊版本的遺留網站，這些網站被包含在資料集中。這就造成了一種情況，即隻有較新的架構（Astro，Remix，SvelteKit）才可以被認為是過去 1-2 年内運作的現代版本軟體，這是我們現有資料的局限性。
總結
此報告一經釋出，引起了不少開發者的熱議。有網友稱：這是一篇很棒的報告，其中準确指出了很多警告。也有一些網友表示，在報告中提到的 Nuxt ，談論的究竟是哪個版本？最好能夠再添加一些注釋。對此，福克斯本人也做出了相關回應，并表示在今後的報告中加以探讨。