前端面試問「CSR / SSR 差異」時，通常不會只停在這兩個名詞。
面試官很可能會接著問：
- SSG 是什麼？
- SSR 和 SSG 哪個比較適合 SEO？
- Next.js 為什麼比純 React SPA 更適合 SEO？
- hydration 是什麼？
- 什麼情境應該選 CSR、SSR、SSG 或 ISR？
這篇就把渲染策略和 SEO 一次整理清楚。
CSR 是什麼？
CSR 是 Client-Side Rendering，也就是主要在瀏覽器端產生畫面。
簡化流程：
Browser request
→ Server 回傳很薄的 HTML shell
→ Browser 下載 JavaScript bundle
→ React 在瀏覽器執行並產生畫面
→ 前端再呼叫 API 取得資料優點：
- 適合互動性高的 App
- 登入後系統、後台、Dashboard 很常用
- 前後端責任分離清楚
- server 壓力相對小
缺點：
- 首屏內容要等 JS 載入與執行
- 搜尋引擎一開始拿到的 HTML 內容較少
- 使用者在慢網路或低階裝置上可能感覺比較慢
面試可以這樣回答：
CSR 是瀏覽器端渲染，server 先回一個 HTML shell，真正的 UI 由前端 JavaScript 在 client 端產生。它適合互動性高、SEO 不敏感的應用，例如後台系統；但首屏速度與 SEO 需要額外處理。
SSR 是什麼？
SSR 是 Server-Side Rendering，每次 request 進來時，伺服器先把頁面渲染成 HTML，再回給瀏覽器。
簡化流程：
Browser request
→ Server 取得資料
→ Server render HTML
→ Browser 先看到完整內容
→ React hydration 接手互動優點：
- 使用者可以更早看到有內容的 HTML
- 搜尋引擎更容易讀到頁面文字
- 適合公開頁、商品頁、文章頁、需要即時資料的頁面
缺點：
- 每次 request 都可能增加 server 負擔
- 快取策略需要設計
- hydration 前後內容不一致時會出現警告或 UI 抖動
面試可以補一句：
SSR 不代表頁面沒有 JavaScript。SSR 只是先在 server 產出 HTML，之後瀏覽器仍然需要載入 JavaScript 做 hydration，讓頁面變得可互動。
SSG 是什麼？
SSG 是 Static Site Generation，在 build time 就先把頁面產生成靜態 HTML。
簡化流程：
Build time
→ 讀取資料
→ 產生 HTML
→ 部署到 CDN
User request
→ CDN 直接回 HTML優點：
- 速度快，CDN 友善
- server 負擔低
- SEO 友善
- 很適合 Blog、文件、行銷頁、產品介紹頁
缺點：
- 資料更新後通常需要重新 build
- 不適合每個使用者都不同的個人化頁面
- 如果頁面數量極大，build time 可能變長
面試回答：
SSG 是在 build 階段就把頁面產成 HTML，使用者請求時可以直接從 CDN 拿到靜態內容。它很適合內容變動不頻繁、但需要 SEO 和速度的頁面，例如 Blog、文件和行銷頁。
ISR 是什麼？
Next.js 還有 ISR：Incremental Static Regeneration。
它介於 SSG 和 SSR 之間。
概念是：
先產生靜態頁，但可以設定一段時間後在背景重新產生頁面。
例如商品頁不需要每秒更新，但也不能永遠停在 build 當下，就可以用 ISR。
第一次 request → 回傳已產生的 HTML
超過 revalidate 時間 → 背景重新產生
下一個 request → 拿到新版本面試不用講得太深，但可以補一句：
ISR 適合內容需要更新，但不需要每次 request 都即時 render 的頁面，可以兼顧靜態頁速度和資料新鮮度。
CSR / SSR / SSG / ISR 比較
| 模式 | HTML 產生時機 | 優點 | 適合場景 |
|---|---|---|---|
| CSR | 瀏覽器執行 JS 時 | 互動彈性高、server 負擔低 | 後台、Dashboard、登入後 App |
| SSR | 每次 request 時 | 內容即時、SEO 較友善 | 商品頁、個人化公開頁 |
| SSG | build time | 速度快、CDN 友善、SEO 佳 | Blog、文件、行銷頁 |
| ISR | build 後按時間再生成 | 兼顧速度與資料更新 | 商品頁、內容站、新聞列表 |
不要把它們講成誰一定比較好。成熟的回答應該是：
要看頁面需求。登入後的管理系統通常 CSR 就足夠；公開內容頁適合 SSR 或 SSG；資料不常變的頁面可以用 SSG；需要更新但不用每次即時的頁面可以用 ISR。
Hydration 是什麼？
Hydration 是 SSR / SSG 很常被追問的概念。
server 已經回傳 HTML，所以使用者一開始可以看到內容。但這些 HTML 還沒有 React event handler，按鈕還不能真正互動。
瀏覽器下載 JavaScript 後，React 會把事件、狀態和元件邏輯接回既有 HTML，這個過程就是 hydration。
Server HTML
→ Browser 顯示內容
→ JS bundle 下載完成
→ React hydrate
→ 頁面可以互動常見問題是 hydration mismatch。
例如 server render 出來的時間和 client render 出來的時間不同：
export function Time() {
return <p>{new Date().toLocaleString()}</p>;
}server 和 client 產生的文字不同，就可能造成 mismatch。
Next.js 為什麼比純 React SPA 適合 SEO？
純 React SPA 通常是 CSR。搜尋引擎一開始拿到的 HTML 可能只有：
<div id="root"></div>真正內容要等 JavaScript 執行後才出現。
Next.js 的優勢是它讓你比較容易做到 SEO 需要的幾件事：
1. 預先產生 HTML
Next.js 支援 SSR、SSG、ISR。搜尋引擎進來時，可以更早拿到有內容的 HTML。
2. Metadata 管理完整
可以針對每個頁面設定：
titledescription- canonical URL
- Open Graph
- Twitter Card
export async function generateMetadata({ params }) {
const post = await getPostBySlug(params.slug);
return {
title: post.meta.title,
description: post.meta.summary,
openGraph: {
title: post.meta.title,
description: post.meta.summary,
},
};
}3. sitemap / robots / routing 更容易整合
Next.js 的 file-based routing 讓 URL 結構清楚，也比較容易產生 sitemap、robots.txt 和 canonical。
4. 效能基礎比較好
Next.js 提供 image optimization、code splitting、streaming、route-level data fetching 等能力。SEO 不只看 HTML，也會受到頁面速度和使用體驗影響。
面試常見追問
SSR 一定比 CSR 快嗎？
不一定。
SSR 可能讓使用者更早看到內容，但 server 需要 render HTML。如果 server 很慢、資料查詢很慢，TTFB 也可能變高。
SSG 內容更新怎麼辦？
可以重新 build，或使用 ISR。若內容需要即時更新，就不適合純 SSG。
SEO 只靠 SSR 就夠嗎？
不夠。
還要看：
- 內容品質
- 正確標題階層
- metadata
- canonical
- sitemap
- 頁面速度
- mobile experience
- structured data
面試回答模板
CSR 是瀏覽器端渲染，適合互動性高但 SEO 不敏感的頁面；SSR 是每次 request 時 server 產生 HTML，適合需要即時資料與 SEO 的公開頁；SSG 是 build time 產生靜態 HTML，適合 Blog、文件、行銷頁；ISR 則是在靜態頁基礎上定期重新產生。Next.js 比純 React SPA 適合 SEO，是因為它可以用 SSR、SSG、ISR 讓搜尋引擎更早拿到內容，也提供 metadata、sitemap、routing 和效能相關能力。不過 SEO 不是只靠 SSR，還要看內容品質、語意結構和頁面速度。