結論先講
沒有「最好的渲染策略」，只有「最適合你頁面類型的渲染策略」。 CSR 適合互動為主的 SPA，SSR 適合 SEO + 首屏速度兼顧，Islands 適合靜態內容多、互動少的內容型網站。選錯渲染策略，效能反而比不選更差。
三種策略一句話
| 策略 | 一句話 | 首屏來源 |
|---|---|---|
| CSR | 瀏覽器下載 JS → 執行 → 產生 HTML | 全靠瀏覽器 |
| SSR | Server 產生 HTML → 瀏覽器收到就能看 → 再載入 JS 做互動 | Server 先畫 |
| Islands | Server 產生靜態 HTML → 只有互動區塊載入 JS | 混合 |
我們測到了什麼
同一個 Todos 頁面的首屏速度
| 渲染方式 | 框架 | LCP | 備註 |
|---|---|---|---|
| CSR | React | 1.82s | 瀏覽器端渲染 |
| CSR | Vue | 1.69s | 瀏覽器端渲染 |
| CSR | Svelte | 1.75s | 瀏覽器端渲染 |
| CSR | Angular | 2.10s | 瀏覽器端渲染 |
| Islands | Astro-React | 2.50s+ | SSR + 局部 hydration |
| Islands | Astro-Vue | 2.60s+ | SSR + 局部 hydration |
CSR 的 Vue 最快（1.69s），Islands 的 Astro 最慢（2.5s+）。
為什麼 Islands 比純 CSR 慢
直覺上，SSR 應該比 CSR 快——server 先畫好 HTML，瀏覽器收到就能看。但 Astro 的 Islands 在 Todos 頁面反而更慢，原因有三：
1. Hydration 成本
Astro 先在 server 渲染 HTML，傳給瀏覽器。瀏覽器收到 HTML 後，還需要「hydrate」——把 JavaScript 的事件綁定和狀態管理接上去。
CSR: [下載 JS] → [執行 JS 產生 DOM] → 可互動
─────────────1.82 秒──────────────
Islands: [下載 HTML] → [顯示] → [下載 JS] → [Hydrate] → 可互動
───────0.5s──── ─────────2.0s───────── = 2.5s
看起來 Islands 分成兩階段：先看到內容（0.5s），再等互動（2.0s）。但 Lighthouse 的 LCP 看的是「最大內容繪製」，而 Todos 頁面的「最大內容」就是那個列表——在 hydration 完成前，列表是靜態的（不能勾選、不能新增）。
2. Todos 頁面全部都是互動元件
Islands 的設計是「大部分是靜態 HTML，少部分是互動島嶼」。但 Todos 頁面的每一行都是互動元件（勾選、刪除）。等於整個頁面都是「島嶼」——你付出了 SSR 的渲染成本，又付出了 CSR 的 hydration 成本。
3. 額外的 HTTP roundtrip
CSR 只需要一次 HTTP 請求（下載 JS bundle）。Islands 需要兩次：先下載 HTML，再下載 JS 做 hydration。在高延遲網路下，每個 roundtrip 都是成本。
什麼時候用什麼
CSR（客戶端渲染）
適合：
- 登入後的 dashboard、管理後台
- 互動為主的 SPA（類似 Figma、Notion）
- 不需要 SEO 的內部工具
不適合：
- 需要 SEO 的公開頁面
- 首屏速度是 KPI 的場景
為什麼： CSR 的 HTML 初始只有一個 <div id="root"></div>，搜尋引擎爬到的是空白頁面。雖然 Googlebot 現在能執行 JavaScript，但 crawl budget 有限，CSR 頁面被索引的速度比 SSR 慢。
SSR（服務端渲染）
適合：
- 電商產品頁、部落格文章
- 需要 SEO + 首屏速度兼顧
- Next.js / Nuxt.js 的主場
不適合：
- Server 負載已經很高的場景（SSR 會增加 server 壓力）
- 純 API + SPA 的架構
注意： SSR 把渲染工作從瀏覽器搬到 server。如果你的 server 已經在跑 bcrypt（參考 第 25 篇），再加 SSR 的 CPU 消耗，server 會更早到達瓶頸。
Islands（部分 hydration）
適合：
- 部落格、文件站、行銷頁
- 「90% 靜態內容 + 10% 互動元件」的頁面
- Astro 的主場
不適合：
- SPA（整頁都是互動元件）
- 互動元件多於靜態內容的頁面
Hydration 的 Main Thread 成本
我們測了 Todos 頁面各框架在 hydration 階段佔用 Main Thread 的時間：
| 框架 | Hydration Main Thread 時間 | 說明 |
|---|---|---|
| Svelte | 最低 | 編譯時處理完，runtime 幾乎無 hydration |
| Vue | 低 | 響應式系統輕量 |
| React | 中 | Virtual DOM diff + reconciliation |
| Angular | 高 | Zone.js + Change Detection |
| Astro | 最高 | SSR HTML + 全頁 hydration = 雙重成本 |
Main Thread 時間直接影響 FID（First Input Delay）。 如果 hydration 佔了 Main Thread 500ms，用戶在這 500ms 內點按鈕不會有反應。
和後端壓測的連結
前端渲染策略的選擇會影響後端壓力：
| 策略 | 對後端的影響 |
|---|---|
| CSR | 後端只需要回 API JSON，壓力最小 |
| SSR | 後端要渲染 HTML，CPU 壓力增加 30-50% |
| Islands | 後端渲染靜態 HTML（可快取），壓力介於 CSR 和 SSR 之間 |
如果你的後端已經在 CRUD 場景 中被 bcrypt 打到天花板，加 SSR 等於雪上加霜。這也是為什麼很多團隊選擇 CSR + API 分離——讓前端的渲染壓力留在瀏覽器端，不要加到 server 上。
F2E 小結
兩篇 F2E 的核心 takeaway：
- Lighthouse 分數差距小（6 分），不是選框架的依據（第 34 篇）
- Bundle size 和渲染策略才是真正的差異（本篇）
- React 是安全牌，Svelte 是極致效能，Vue 是均衡，Angular 不用為了 6 分換掉
- Astro Islands 適合內容型網站，不適合 SPA
- 前端選型看生態，後端選型看壓測數據
接下來進入 DB 層——PG vs MySQL、ORM vs Raw SQL、Bulk Insert 快 26 倍。和後端框架比較不同，DB 層的選型直接影響每一層的效能天花板。
下一篇
PostgreSQL vs MySQL：3.2 倍的 JSON 差距 — 同一個 Express-TS + Sequelize，只換 DB。PG 在 JSON 查詢快 3.2 倍，但 MySQL 在大量寫入快 2.5 倍。不是「PG 一定比較好」。
本系列文章
完整 68 篇目錄見 系列首頁
← 上一篇：前端框架 Lighthouse 排名：React 99 分但差距其實不大 → 下一篇：PostgreSQL vs MySQL：不是誰比較好，是場景不同