前端渲染決策框架：CSR / SSR / SSG / ISR / RSC 什麼時候選什麼

結論先講

渲染策略（CSR/SSR/SSG/ISR/RSC）不是「選最新最潮」。每種解決不同問題、有不同成本。選錯會：

• 靜態部落格用 CSR → SEO 掛掉
• 個人化 Dashboard 用 SSG → 每次要手動重 build
• 大流量電商用 SSR → 伺服器被打爆
• 所有頁面都用 RSC → 開發複雜度爆炸

這篇給你三個維度的判斷框架：內容特性 × 個人化程度 × 即時性需求。依此選對策略。

---

先對齊術語

縮寫	全名	什麼時候產生 HTML
CSR	Client-Side Rendering	瀏覽器 JS 跑完後
SSR	Server-Side Rendering	每次 request 時伺服器產生
SSG	Static Site Generation	Build 時產生（預編譯）
ISR	Incremental Static Regeneration	Build 時先產，定期背景更新
RSC	React Server Components	每次 request，但是 React 元件級
Streaming SSR	Streaming Server-Side Rendering	一邊產生一邊送

---

三維判斷框架

維度 1：內容特性

• 完全靜態：部落格文章、marketing page、文件 → 適合 SSG
• 動態內容但公開：新聞、商品資訊 → 適合 ISR 或 SSR
• 個人化內容：Dashboard、訂單、會員中心 → 適合 CSR 或 SSR
• 即時變動：股票、聊天、協作 → CSR + WebSocket

維度 2：SEO 需求

• 需要被爬（部落格、電商商品）→ 不能純 CSR（或需要 SSR/SSG）
• 不需要被爬（後台系統）→ CSR 沒問題

維度 3：更新頻率

• 一天更一次以下：SSG（build 一次就好）
• 幾小時更一次：ISR（定期背景重產）
• 秒級更新：SSR 或 CSR

---

各策略的本質

CSR：瀏覽器動態算

瀏覽器載入空 HTML → 下載 JS → JS 跑完 → 畫面出現

優點：伺服器只需回傳靜態檔、部署簡單（CDN）、互動性佳 缺點：

• SEO 壞（爬蟲可能拿到空頁）
• 首頁白屏久（要等 JS）
• 手機慢（裝置差異大）

適合：後台系統、Web App（Gmail、Figma）

SSR：每次 request 伺服器算

request 進來 → 伺服器跑 React/Vue → 產生完整 HTML → 回傳 → 瀏覽器 hydrate

優點：

• SEO 完美（HTML 是完整的）
• 首次內容快（不用等 JS）
• 支援個人化（可以讀 cookie、session）

缺點：

• 伺服器成本高（每次請求都要跑渲染）
• TTFB 可能久（伺服器算完才回）
• 流量爆炸時容易掛

適合：個人化 + 需要 SEO 的（社群、電商會員中心）

SSG：Build 時算好

build 時 → 產出 HTML 檔 → 部署 → 瀏覽器直接拿現成 HTML

優點：

• 極快（CDN 檔案，不經過伺服器邏輯）
• 伺服器成本接近零
• SEO 完美
• 高可用性（靜態檔壞不掉）

缺點：

• 內容變要重 build（不適合常更新）
• 無法個人化（build 時不知道誰訪問）
• 大站 build 慢（1000+ 頁可能要數分鐘）

適合：部落格、文件、landing page、marketing

ISR：SSG + 定期更新

build 時先產 → 使用者訪問拿快取 → 定期背景重產 → 下次拿到新的

Next.js 的 ISR：

export async function getStaticProps() {
  return {
    props: { data: await fetchData() },
    revalidate: 60,  // 每 60 秒過期，背景重產
  };
}

優點：兼顧 SSG 的快 + 不用重 build 就能更新 缺點：仍有「過期快取」時間窗；複雜度介於 SSG 跟 SSR

適合：內容常更新但不需要即時（新聞、商品、部落格列表）

RSC（React Server Components）：元件級 SSR

Server Component 在伺服器跑 → 產生序列化結果 → 推到 client
Client Component 照常在瀏覽器跑

優點：

• 元件級選擇（同一頁混用 server/client）
• 不送沒用的 JS 給 client（bundle size 更小）
• 可以直接在元件裡 access DB

缺點：

• 複雜度高（server/client 界線要搞清楚）
• 生態未完全成熟（第三方 lib 相容性）
• 只有 Next.js App Router 穩定支援

適合：大型 Next.js 專案、重視 bundle size 的 app

Streaming SSR：一邊產一邊送

HTML 不等全部好才送，分塊 streaming：

<header> 先送 → <main> 接著送 → <footer> 最後送

優點：TTFB 更快，使用者更快看到東西 適合：SSR 但有慢載元件時（<Suspense>）

---

實戰決策樹

頁面類型？
├── 靜態內容（部落格、文件、landing）
│   ├── 內容穩定 → SSG
│   └── 常更新但不即時 → ISR
│
├── 動態公開內容（新聞、商品列表）
│   ├── 每頁數據可以預生 → ISR
│   └── 需要即時 → SSR
│
├── 個人化內容（Dashboard、會員中心）
│   ├── 需要 SEO → SSR
│   └── 不需要 SEO → CSR
│
├── 即時互動（聊天、股票）
│   └── CSR + WebSocket / SSE
│
└── 混合（電商商品頁個人化推薦）
    └── SSR 主內容 + CSR 個人化區塊，或 RSC

---

常見混搭策略

策略 A：SSG 主頁 + CSR 互動

電商首頁 SSG（商品列表靜態），購物車 CSR（個人化）。

策略 B：SSR + CDN Cache

SSR 頁面套 CDN 快取 60 秒。兼顧個人化跟效能。

策略 C：SSR First Paint + CSR Hydration

首次 SSR 送完整 HTML，後續互動靠 CSR。Next.js / Nuxt / SvelteKit 預設模式。

策略 D：Islands Architecture

Astro 的模式：預設 SSG，互動區塊才打包 JS。

---
// 伺服器跑
const posts = await fetchPosts();
---
<Header /> <!-- 靜態 HTML -->
<PostList posts={posts} /> <!-- 靜態 -->
<CommentSection client:load /> <!-- 這塊才打包 JS -->

適合：內容型網站有少量互動。

---

選錯的代價（真實例子）

場景	選錯	結果
Gatsby 靜態部落格用 SSR	浪費	伺服器費用 10 倍
會員後台 CRM 用 SSG	不可行	個人化資料無法預生
大型電商全 SSR（沒 CDN）	流量尖峰掛	黑五當機
公司官網全 CSR	SEO 崩潰	Google 排名蒸發
小型 Dashboard 用 RSC	過度工程	開發速度拖慢、人員學習成本

---

實戰 Checklist

• 先問「需要 SEO 嗎」決定能不能純 CSR
• 個人化 + SEO 需求 → SSR 或 RSC
• 內容穩定 → SSG
• 內容常更新但可延遲 → ISR
• 別預設 RSC 是未來（複雜度成本要評估）
• 混合策略常常是正解（SSR 主內容 + CSR 局部）
• 大流量 SSR 一定要配 CDN
• Astro Islands 對內容站是好選擇

---

相關文章

• 前端渲染策略比較 — 更深入技術面比較
• Lighthouse 效能排名 — 渲染策略對效能的影響
• Frontend Roadmap F07
• 好的前端專案該有什麼