返回文章列表

CSR vs. SSR vs. SSG：前端渲染方式

22 分鐘
前端Web

前端應用程式有三種主要的渲染策略，決定了 HTML 在哪裡、什麼時候被產生：

  • CSR (Client-Side Rendering)：在瀏覽器端渲染
  • SSR (Server-Side Rendering)：在伺服器端渲染
  • SSG (Static Site Generation)：在建置時預先產生

選擇哪種方式，直接影響頁面的載入速度、SEO、開發複雜度和伺服器成本。

CSR

CSR (Client-Side Rendering，客戶端渲染) 是 React、Vue、Angular 等 SPA 框架的預設方式。

運作方式

  1. 瀏覽器向伺服器請求頁面
  2. 伺服器回傳一個幾乎空白的 HTML 和 JavaScript bundle
  3. 瀏覽器下載並執行 JavaScript
  4. JavaScript 向 API 請求資料
  5. 資料回來後，JavaScript 在瀏覽器中動態產生 HTML，渲染頁面

優點

  • 頁面切換流暢，不需要重新載入整個頁面
  • 伺服器負擔低，只需提供靜態檔案和 API
  • 前後端完全分離，開發靈活

缺點

  • 首次載入較慢 (FCP 慢)：使用者需要等 JS 下載、執行完才看到內容
  • SEO 較差：搜尋引擎爬蟲可能看不到動態產生的內容 (雖然現代爬蟲已改善)
  • 需要 JavaScript 才能顯示內容，JavaScript 失敗時頁面會空白

適合場景

  • 需要登入的應用程式 (Dashboard、管理後台)
  • 即時互動性高的應用 (聊天室、協作工具)
  • SEO 不重要的內部工具

SSR

SSR (Server-Side Rendering，伺服器端渲染) 在每次請求時，由伺服器動態產生完整的 HTML 再回傳給瀏覽器。

運作方式

  1. 瀏覽器向伺服器請求頁面
  2. 伺服器取得資料 (查詢資料庫或呼叫 API)
  3. 伺服器用資料產生完整的 HTML
  4. 瀏覽器收到完整的 HTML，直接顯示內容
  5. JavaScript 下載後，接管頁面的互動 (Hydration)

優點

  • FCP 快：使用者收到的是完整的 HTML，不需要等 JS 執行
  • SEO 好：搜尋引擎爬蟲可以直接讀取完整的 HTML
  • 適合需要即時資料的頁面

缺點

  • TTFB (Time to First Byte) 較慢：伺服器需要先取得資料再回傳
  • 伺服器負擔較高，每次請求都要重新產生 HTML
  • 部署比 CSR 複雜，需要 Node.js 伺服器

適合場景

  • 電商商品頁 (即時庫存、價格)
  • 新聞、部落格 (SEO 重要且內容頻繁更新)
  • 需要個人化內容的頁面 (登入狀態影響顯示內容)

SSG

SSG (Static Site Generation，靜態網站生成) 在建置時預先產生所有頁面的 HTML，部署後直接提供靜態檔案。

運作方式

  1. 建置時，框架取得所有資料
  2. 根據資料和模板，預先產生所有頁面的 HTML 檔案
  3. 部署到 CDN 或靜態檔案伺服器
  4. 使用者請求頁面時，直接回傳預先產生的 HTML

優點

  • 最快的載入速度：靜態檔案可以放在 CDN，全球快速分發
  • SEO 最好：完整的 HTML 在建置時就已產生
  • 伺服器成本低，靜態檔案幾乎不需要計算資源
  • 安全性高，沒有動態伺服器就沒有伺服器端漏洞

缺點

  • 資料不是即時的：頁面內容在建置時就固定了，更新需要重新建置
  • 頁面數量多時，建置時間會很長
  • 不適合高度個人化或頻繁變動的內容

適合場景

  • 部落格、文件網站
  • 行銷頁面、企業官網
  • 內容變動不頻繁的網站

差異總覽

CSRSSRSSG
HTML 產生位置瀏覽器 (執行時)伺服器 (每次請求)建置時
首次載入速度慢中最快
SEO較差好最好
資料即時性即時即時不即時 (建置時固定)
伺服器需求低 (只需靜態伺服器)高 (需要 Node.js)低 (CDN 即可)
適合場景SPA、管理後台電商、新聞部落格、文件

使用時機

選 CSR 當：

  • 不需要 SEO (登入後的頁面)
  • 互動性高、資料頻繁變動
  • 想要最簡單的部署方式

選 SSR 當：

  • SEO 重要，且資料需要即時更新
  • 頁面內容依使用者狀態而變化
  • 可以接受較高的伺服器成本

選 SSG 當：

  • 內容相對固定，不需要即時資料
  • SEO 和載入速度是首要考量
  • 想要最低的伺服器成本和最高的安全性

總結

三種渲染方式各有取捨，沒有絕對的最佳解：

  • CSR：開發簡單、互動性好，但 SEO 和首次載入較弱
  • SSR：SEO 好、資料即時，但伺服器成本高
  • SSG：速度最快、成本最低，但資料不即時

現代框架 (Next.js、Nuxt.js) 讓你可以在同一個專案中混用三種方式，對不同頁面選擇最適合的策略。

其中值得一提的是 Next.js 的 ISR (Incremental Static Regeneration) (SSG 的延伸)，透過設定 revalidate 讓靜態頁面可以在背景定期重新生成，不需要完整重建整個網站。對於內容會更新但不需要每次請求都即時產生的頁面，ISR 是 SSG 與 SSR 之間實用的折衷選擇。

CSR / SSR / SSG 是 Runtime 階段的渲染策略。無論採用哪種策略，瀏覽器收到 HTML 後都要走過同樣的渲染流程，參考 瀏覽器渲染流程；想了解完整執行週期，參考 從原始碼到畫面。