結論先講
6 個前端框架的 Lighthouse 效能分數差距只有 6 分。 React 99、Vue 98、Svelte 97、Angular 93——在這個範圍內比分數沒有意義。真正影響用戶體驗的是兩件事：打包後的檔案大小（Svelte 326KB vs Angular 784KB，差 2.4 倍）和渲染策略（CSR vs SSR vs Islands）。
這一步怎麼來的：後端框架的差距可以到 20 倍（Go vs Django）。但用戶體驗不只是 API 回應速度——前端的載入、渲染、bundle size 也會影響「用戶覺得快不快」。後端測完了，自然想知道前端差多少。
為什麼測前端
後端框架壓測（Part 3）告訴我們服務端的天花板。但用戶體驗不只是 API 回應速度——前端的首屏載入、bundle 大小、渲染策略同樣影響「用戶覺得快不快」。
這兩篇 F2E 測試回答的問題是：前端框架的效能差異有多大？大到值得為了效能換框架嗎？（劇透：差距只有 6 分，不值得。）
測試怎麼做的
| 項目 | 設定 |
|---|---|
| 框架 | React / Vue / Angular / Svelte / Astro-React / Astro-Vue |
| 測試 | Lighthouse × 3 次，取中位數 |
| 頁面 | 3 種：靜態頁、登入表單、動態列表（Todos） |
| 環境 | Production Build，統一 Docker 部署 |
為什麼測 3 種頁面？因為前端框架在不同頁面類型的表現差異比框架之間的差異更大。靜態頁大家都 100 分；動態列表才看得出真正的效能差異。
Lighthouse Performance 排名
| # | 框架 | Performance 分數 | 備註 |
|---|---|---|---|
| 1 | React | 99 | 社群最大、套件最多 |
| 2 | Vue | 98 | 首屏載入最快（1.69s） |
| 3 | Svelte | 97 | 打包最小、零效能警告 |
| 4 | Astro-React | 96 | Islands 架構 |
| 5 | Angular | 93 | 打包最大（784KB） |
| 6 | Astro-Vue | 93 | Islands 架構 |
6 分差距代表什麼
在 Lighthouse 的評分系統中，90-100 都是綠色（Good）。93 分和 99 分在實際用戶體驗上幾乎沒有感知差異。
真正會被用戶感受到的是：
- 首屏載入時間（LCP）: Vue 1.69 秒 vs Astro 2.5+ 秒
- 互動就緒時間（TTI）: 和 bundle size 直接相關
- 輸入延遲（FID）: 和 JavaScript 執行量相關
這些指標的差距比 Lighthouse 總分更值得關注。
Bundle Size：真正的差距在這裡
| 框架 | JS + CSS 大小 | 對比 |
|---|---|---|
| Svelte | 326 KB | 基準 |
| Vue | 485 KB | 1.49x |
| React | 712 KB | 2.18x |
| Angular | 784 KB | 2.40x |
Svelte 326KB 只有 Angular 784KB 的 42%。
為什麼 Bundle Size 比分數重要
- 手機用戶: 3G 網路下載 784KB 要 3-4 秒，326KB 只要 1-2 秒
- 弱網路環境: 東南亞、非洲市場的用戶很多在 2G/3G
- SEO: Google 的 Core Web Vitals 會懲罰慢的首屏載入
- 體感: 用戶不知道 Lighthouse 幾分，但感覺得到「怎麼還沒跑出來」
Svelte 為什麼這麼小
Svelte 在 build 時把框架本身編譯掉了——產出的是純 JavaScript，沒有 runtime library。React 和 Vue 的 bundle 裡包含框架的 runtime（虛擬 DOM diff 算法、響應式系統等），Svelte 把這些事在 compile time 做完。
Angular 最大是因為：RxJS + Zone.js + Dependency Injection + Template Compiler 都打包進去了。
首屏載入速度
| 框架 | LCP（Largest Contentful Paint） |
|---|---|
| Vue | 1.69 秒 |
| React | 1.82 秒 |
| Svelte | 1.75 秒 |
| Angular | 2.10 秒 |
| Astro-React | 2.50+ 秒 |
| Astro-Vue | 2.60+ 秒 |
Vue 首屏最快。Astro 的 Islands 架構在簡單頁面反而更慢——下一篇會解釋為什麼。
Astro Islands：為什麼簡單頁面反而更慢
Astro 的設計理念是「預設零 JavaScript」——只有標記為 client:load 的互動元件才會載入 JS。理論上這應該更快。
但在我們的測試中（Todos 動態列表），Astro 版本的 LCP 超過 2.5 秒，比純 React 的 1.82 秒慢 37%。
原因：Hydration 的額外成本。 Astro 先在 server 端渲染 HTML，然後在 client 端「hydrate」互動元件。對於一個整頁都是互動元件的 Todos 應用，hydration 的成本比直接 CSR 更高——因為你同時付出了 SSR 的渲染成本和 CSR 的 JavaScript 執行成本。
Astro Islands 的甜蜜點是「內容為主、互動為輔」的網站：部落格、文件站、行銷頁。整頁都是互動元件的 SPA 不適合用 Astro。
選什麼框架
React（大部分情況）
- Lighthouse 99 分（最高）
- 社群最大、學習資源最多、第三方套件最豐富
- Bundle 712KB 偏大，但可以透過 code splitting + lazy loading 解決
- 適合：團隊已經會、中大型專案、需要很多第三方套件
Svelte（對檔案大小敏感）
- Bundle 326KB（最小），唯一沒有任何 Lighthouse 效能警告
- 生態較小，第三方套件選擇少
- 適合：手機/弱網路用戶多、小型快速專案、追求極致效能
Vue（均衡選擇）
- 首屏載入最快（1.69 秒）
- 各方面表現均衡，學習曲線比 React 平
- 適合：團隊偏好、需要均衡表現、中型專案
Angular（團隊已經會就不用換）
- 分數最低（93）但只差 6 分
- Bundle 最大（784KB）
- 換框架的成本遠大於 6 分的差距——如果團隊已經熟悉 Angular，沒必要為了分數換
Astro（內容型網站）
- 不適合 SPA（互動為主的應用）
- 適合部落格、文件站、行銷頁
- 可以搭配 React 或 Vue 做互動元件（Islands 架構）
和後端壓測的對照
後端框架的效能差距可以到 20 倍（Go 74 RPS vs Django 1 RPS @500VU）。前端框架的效能差距只有 6%（93 vs 99 分）。
前端選型應該看生態和開發效率，不看效能。 後端選型在高併發場景下需要認真看效能數據。
這也呼應了 第一篇 說的：壓力測試的價值在於「知道極限在哪裡」。前端的極限很高（都在 90+ 分），不是瓶頸；後端的極限因框架而異，才需要實測。
下一篇
CSR vs SSR vs Islands：首屏速度的三種哲學 — 同一個 Todos 頁面，用三種不同的渲染策略，LCP 差距可以到 37%。什麼時候用 CSR、什麼時候上 SSR、Islands 適合誰。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：Laravel CRUD：Nginx 的快速拒絕是把雙刃劍 → 下一篇：CSR vs SSR vs Islands：首屏速度的三種哲學