網頁HTML渲染方式
Tuesday, Mar 17, 2026 | 5 minute read | Updated at Tuesday, Mar 17, 2026
CSR / SSR / SSG / ISR 渲染方式的差異
核心概念
簡而言之，最根本的差異是 「網頁的 HTML 是在哪裡/何時產生的？」
- CSR — 地點特殊：唯一在瀏覽器產生的
- SSR vs SSG vs ISR — 地點相同（都在 Server），但時機不同
| 方法 | 在哪裡產生 | 什麼時候產生 |
|---|---|---|
| CSR | 瀏覽器 | 使用者造訪時 |
| SSR | Server | 每次收到請求時 |
| SSG | Server | Build 的時候（提前） |
| ISR | Server | Build 時 + 定時重新產生 |
名詞解釋
ISR
Incremental Static Regeneration 增量靜態再生
Client Side Render
客戶端渲染，HTML 由瀏覽器（使用者的電腦）負責產生
運作流程：
使用者輸入網址 ↓ Server 回傳一個「幾乎空白」的 HTML + 一包 JavaScript ↓ 瀏覽器下載並執行 JavaScript ↓ JavaScript 向 API 請求資料 ↓ 拿到資料後，JavaScript 在瀏覽器中動態產生畫面 ↓ 使用者看到內容
時間軸特徵
首次載入慢：要等 JS 下載 → 執行 → 請求資料 → 渲染，才能看到內容 後續切換快：頁面切換不需要再向 Server 要 HTML，只需要拿資料 白畫面期：在 JS 執行完之前，使用者看到空白或 loading 畫面
代表框架
React（純 CSR）、Vue（純 CSR）
Server Side Render
伺服器端渲染，HTML 由伺服器負責產生，完整送給瀏覽器
運作流程
使用者輸入網址 ↓ Server 收到請求，向資料庫/API 取得資料 ↓ Server 將資料填入 HTML 模板，產生完整 HTML ↓ 將完整 HTML 回傳給瀏覽器 ↓ 使用者立即看到內容（瀏覽器幾乎不需要額外處理）
時間軸特徵
首次載入快：HTML 已經包含完整內容，瀏覽器直接顯示 每次切換都要請求 Server：每個頁面都重新向伺服器要一份新的 HTML TTFB（Time to First Byte）較長：Server 要先處理完才能回傳
代表框架
Next.js、Nuxt.js、傳統 PHP / Ruby on Rails
Static Site Generation
靜態生成，HTML 在「build 的時候」就產生好了，不是 request 的時候
運作流程
開發者執行 build 指令 ↓ 框架一次性產生所有頁面的 HTML 檔案 ↓ 這些 HTML 靜態檔案部署到 CDN ↓ 使用者請求 → CDN 直接回傳現成的 HTML
時間軸特徵
載入極快：HTML 已經預先產生好，CDN 直接回傳，不需要 Server 即時運算 內容是「build 時的快照」：如果資料更新了，需要重新 build 才能反映 適合內容不常變動的網站：部落格、文件網站、行銷頁面
代表框架
Hugo、Gatsby、Next.js（靜態匯出）、Nuxt.js（靜態模式）
Incremental Static Regeneration
增量靜態再生，SSG 的進化版，靜態頁面可以「定時自動更新」，不用重新 build 整個網站
運作流程
第一位使用者請求頁面 ↓ 回傳已經 build 好的靜態 HTML（立即回應） ↓ 同時在背景，Server 偷偷重新產生新版 HTML ↓ 第二位使用者請求同一頁面 ↓ 如果新版 HTML 已經好了 → 回傳新版 如果還沒好 → 仍回傳舊版（不會讓使用者等）
時間軸圖解
時間 0s → 使用者 A 拿到靜態 HTML（舊的，但極快） 時間 0s → 背景開始重新生成新 HTML 時間 2s → 新 HTML 生成完成，存起來 時間 10s → 使用者 B 來了，拿到新 HTML
代表框架
Next.js（唯一原生支援 ISR 的框架）
四種渲染方式 — 時間流程比較
| 時間 | CSR | SSR | SSG | ISR |
|---|---|---|---|---|
| Build 階段 | （無） | （無） | 產生所有頁面 HTML | 產生所有頁面 HTML |
| ① 使用者請求 | 發出請求 | 發出請求 | 發出請求 | 發出請求 |
| ② Server 處理 | 回傳空白 HTML + JS 檔案 | 查資料庫 / API 取資料 | CDN 直接回傳現成 HTML | CDN 直接回傳現成 HTML |
| ③ Server 組裝 | （無） | 將資料填入模板，組合完整 HTML | （無） | （無） |
| ④ 回傳給瀏覽器 | 空白 HTML + 一包 JS | 完整 HTML | 完整 HTML | 完整 HTML |
| ⑤ 瀏覽器處理 | 下載並執行 JS | 直接顯示 | 直接顯示 | 直接顯示 |
| ⑥ 畫面狀態 | 白畫面 / Loading | ✅ 看到內容 | ✅ 看到內容 | ✅ 看到內容 |
| ⑦ 請求資料 | JS 向 API 發請求 | （已完成） | （已完成） | （已完成） |
| ⑧ 等待回傳 | 等 API 回傳資料 | （已完成） | （已完成） | 背景偷偷重新產生新版 HTML |
| ⑨ 渲染畫面 | JS 動態產生畫面 | （已完成） | （已完成） | （已完成） |
| ⑩ 畫面狀態 | ✅ 看到內容 | （已完成） | （已完成） | 下次請求拿到新版 ✅ |
重點：看 ✅ 出現在第幾步
- SSG / ISR → 第 ⑥ 步就看到（最快）
- SSR → 第 ⑥ 步看到（但 ②③ 要等 Server 處理，所以比 SSG 慢一點）
- CSR → 第 ⑩ 步才看到（最慢，中間都在等 JS 和 API）
四種渲染方式比較
| 比較項目 | CSR | SSR | SSG | ISR |
|---|---|---|---|---|
| HTML 產生位置 | 瀏覽器 | Server | Server（Build 時） | Server（Build 時 + 背景更新） |
| 首次載入速度 | 慢（要等 JS 執行） | 中等（等 Server 處理） | 極快（CDN 直接回傳） | 極快（CDN 直接回傳） |
| SEO | 差（搜尋引擎看到空白 HTML） | 好（完整 HTML） | 好（完整 HTML） | 好（完整 HTML） |
| 內容即時性 | 高（每次都拿最新資料） | 高（每次都即時產生） | 低（build 時的快照） | 中（定時更新） |
| Server 負擔 | 低（Server 只給靜態檔案） | 高（每次請求都要運算） | 極低（只有 CDN） | 低（只在背景偶爾運算） |
| 適用場景 | 後台管理系統、互動性高的 SPA | 需要 SEO + 即時資料的頁面 | 部落格、文件、行銷頁面 | 電商商品頁、新聞網站 |
| 代表框架 | React、Vue | Next.js、Nuxt.js、PHP | Hugo、Gatsby、Next.js | Next.js |
面試常見問題
Q1：CSR 和 SSR 最大的差異是什麼？
HTML 產生的「地點」不同。CSR 是在瀏覽器（Client）用 JavaScript 產生 HTML；SSR 是在伺服器（Server）產生完整 HTML 後才回傳給瀏覽器。
Q2：為什麼 CSR 對 SEO 不友善？
因為搜尋引擎爬蟲拿到的是一個幾乎空白的 HTML（只有 <div id="root"></div>），實際內容要等 JavaScript 執行完才會出現。雖然 Google 爬蟲已經可以執行 JS，但不保證每次都會等，其他搜尋引擎支援更差。
Q3：SSG 和 SSR 都在 Server 產生 HTML，差在哪？
差在「時機」。
- SSG 是在 build 階段就把所有頁面產生好，之後每次請求都回傳同一份靜態檔案；
- SSR 是每次收到請求時才即時產生 HTML，所以內容永遠是最新的，但 Server 負擔較大。
Q4：什麼情況下會選擇 ISR？
當網站內容需要更新，但不需要「每次請求都是最新的」。例如電商的商品頁，價格可能一天更新幾次，用 ISR 設定每 60 秒重新生成一次，既有 SSG 的速度，又能定期更新內容。
Q5：Next.js 為什麼同時支援 CSR、SSR、SSG、ISR？
Next.js 讓你在同一個專案裡，針對不同頁面選擇不同的渲染方式。例如首頁用 SSG（不常變動）、商品頁用 ISR（定期更新）、購物車用 CSR（純互動）、搜尋結果用 SSR（每次都不同）。這種彈性是 Next.js 的最大優勢。
Q6：你的部落格用的是哪種渲染方式？為什麼？
Hugo 是 SSG。因為部落格文章寫完後不常變動，不需要即時資料，用 SSG 產生靜態 HTML 部署到 CDN，載入速度最快、Server 成本最低。