揭秘前端渲染：CSR、SSR、SSG 全方位解析與實戰指南

發表於 分類於

當我們談論現代網頁應用時，「渲染（Rendering）」是一個繞不開的核心議題。使用者按下 Enter 鍵後，從看到第一個像素到頁面可以互動，這中間究竟發生了什麼事？這不僅決定了使用者體驗的順暢度，更直接影響了網站的 SEO 表現與維護成本。

這篇文章將會用清晰易懂的方式，帶你一次搞懂 CSR、SSR、SSG 這些渲染模式的原理、優缺點，並提供一份實戰指南，幫助你在下一個專案中，自信地選擇最適合的渲染策略。

什麼是網頁渲染？

簡單來說，渲染就是瀏覽器將我們寫的程式碼（HTML, CSS, JavaScript）轉換為使用者在螢幕上看到的、可互動的畫面的過程。這個過程的核心在於：HTML 是在哪裡被構建出來的？ 是在使用者端的瀏覽器（Client） 還是遠端的伺服器（Server）？這個問題的答案，就決定了將要探討的各種渲染模式。

三大渲染模式深度解析

1. Client-Side Rendering (CSR) - 客戶端渲染

CSR 是現代 單頁式應用（Single-Page Application, SPA） 最常採用的模式。像是 React, Vue, Angular 建立的專案，預設情況下就是 CSR。

它是如何運作的？

  1. 瀏覽器向伺服器發送請求。
  2. 伺服器回傳一個幾乎空白的 HTML 檔案，裡面只包含一個 <div id="root"></div> 的空殼，以及一個巨大的 JavaScript 檔案連結。
  3. 瀏覽器下載並執行這個 JavaScript 檔案。
  4. JavaScript 在瀏覽器中執行，向 API 伺服器請求資料，然後動態生成所有 HTML 內容，並將其「掛載」到那個空殼 <div> 上。
  5. 頁面完整顯示，並具備互動性。

一個生動的比喻：
CSR 就像去 IKEA 買家具。從倉庫（伺服器）拿到的是一堆扁平的零件包（JavaScript Bundle）和一本說明書。你必須自己回家（在瀏覽器裡）花時間組裝，才能得到一張完整的桌子（網頁）。

優點

  • 豐富的互動性與流暢的體驗：首頁載入後，後續的頁面切換都只是在客戶端進行資料交換和 DOM 更新，無需重新向伺服器請求整個頁面，速度極快，感覺就像桌面應用程式一樣。
  • 伺服器壓力小：伺服器只負責提供靜態資源和作為 API 端點，大部分的渲染運算都轉移到了使用者端，大大減輕了伺服器的負擔。
  • 前後端分離：開發模式清晰，前端專注於 UI/UX，後端專注於業務邏輯與資料接口（API）。

缺點

  • 首次載入速度慢（FCP/TTI 慢）：使用者需要等待巨大的 JavaScript 檔下載、解析、執行完畢後才能看到內容，這導致首次內容繪製（First Contentful Paint, FCP） 時間很長，俗稱「白屏時間」。
  • 對 SEO 不友善：雖然 Google 的爬蟲已經能執行部分 JavaScript，但並非所有搜尋引擎都如此。爬蟲收到的初始 HTML 是一個空殼，可能無法正確索引網站內容，對 SEO 造成負面影響。
  • 對裝置性能有要求：運算壓力都在使用者端，如果使用者的裝置性能較差，可能會感到卡頓。

2. Server-Side Rendering (SSR) - 伺服器端渲染

SSR 是一種更傳統的渲染模式，但近年來在現代框架（如 Next.js, Nuxt.js）的加持下重獲新生。

它是如何運作的？

  1. 瀏覽器向伺服器發送請求。
  2. 伺服器接收到請求後，在後端環境執行 JavaScript，獲取所需資料，將頁面內容完整地生成為 HTML 字串。
  3. 伺服器將這個包含完整內容的 HTML 檔案回傳給瀏覽器。
  4. 瀏覽器接收到後立刻就能顯示頁面內容。
  5. 與此同時，瀏覽器會下載對應的 JavaScript 檔案，並在背景執行一個稱為「Hydration（注水）」的過程，為靜態的 HTML 綁定事件，使其具備互動性。

一個生動的比喻：
SSR 就像去家具店直接買一張組裝好的桌子。店家（伺服器）在你下單後，把桌子完完整整地送到你家。你立刻就能看到並使用它，只是上面的一些精巧機關（互動性）需要等送來的電池（JavaScript）裝好後才能啟動。

優點

  • 極佳的 SEO 表現：搜尋引擎爬蟲直接就能收到包含完整內容的 HTML，有利於網站的索引和排名。
  • 首頁載入速度快（FCP 快）：使用者能非常快地看到頁面內容，大大減少了白屏時間，提升了使用者感知效能。
  • 對所有裝置友好：渲染壓力在伺服器端，使用者端只需負責顯示，對低階裝置更友好。

缺點

  • 伺服器壓力大：每個使用者的請求都需要在伺服器端即時進行一次完整的渲染，對伺服器運算能力和 QPS 都是考驗。
  • 互動延遲（TTI 較慢）：雖然使用者很快看到了內容（FCP 快），但頁面要等到 JavaScript 下載並完成 Hydration 後才能進行互動（可互動時間 Time to Interactive, TTI 較晚）。
  • 開發複雜度較高：需要處理伺服器端和客戶端的環境差異，專案架構更複雜。

3. Static Site Generation (SSG) - 靜態網站生成

SSG 是近年來越來越流行的一種模式，可以看作是 SSR 的一種極致優化。

它是如何運作的？

  1. 在建置階段（Build Time），而不是請求階段（Request Time），開發者就執行程式，抓取所有需要的資料。
  2. 針對網站的每一個頁面，都預先生成一個完整的、純靜態的 HTML 檔案。
  3. 將所有這些 HTML、CSS、JS 檔案部署到 CDN 或靜態主機上。
  4. 當使用者請求時，伺服器（或 CDN）不需做任何運算，直接將對應的靜態 HTML 檔案回傳給瀏覽器。

一個生動的比喻：
SSG 就像是大規模印刷書籍。出版社（開發者在建置階段）在書籍上市前就把成千上萬本書全部印刷、裝訂好，放在各地倉庫（CDN）。讀者想買書時，直接從最近的倉庫拿一本現成的就行了，速度快得驚人。

優點

  • 極致的效能：由於提供的是純靜態檔案，載入速度無與倫比。搭配 CDN 使用，全球使用者都能享受飛快的存取體驗。
  • 絕佳的安全性與可靠性：沒有資料庫、沒有伺服器端即時運算，攻擊面極小，網站極其穩定。
  • 成本極低：可以託管在非常便宜甚至免費的靜態主機或 CDN 服務上。
  • 完美的 SEO：跟 SSR 一樣，每個頁面都有完整的 HTML 內容。

缺點

  • 內容更新延遲：每次內容有變動（例如發布一篇新文章），都必須重新建置（Rebuild） 整個網站並重新部署，無法做到即時更新。
  • 建置時間可能很長：如果網站有數千甚至數萬個頁面，建置時間可能會非常可觀。
  • 不適用於高度動態內容：無法處理個人化、即時性的內容（例如使用者儀表板、即時聊天等）。

圖解渲染流程差異

讓我們用時序圖（Sequence Diagram）來視覺化這三種模式的差異。

sequenceDiagram
    participant User as 使用者
    participant Browser as 瀏覽器
    participant Server as 網頁伺服器
    participant APIServer as API 伺服器
    participant CDN as CDN（SSG 使用）

    %% 客戶端渲染 CSR
    Note over User,Browser: 客戶端渲染 (CSR)
    User->>Browser: 訪問網站
    Browser->>Server: 請求 HTML
    Server->>Browser: 回傳幾乎空白的 HTML + JS 連結
    Browser->>Browser: 執行 JS
    Browser->>APIServer: 請求資料 (fetch/axios)
    APIServer->>Browser: 回傳 JSON 資料
    Browser->>Browser: 渲染完整頁面

    %% 伺服器端渲染 SSR
    Note over User,Browser: 伺服器端渲染 (SSR)
    User->>Browser: 訪問網站
    Browser->>Server: 請求頁面
    Server->>Server: 抓取資料並渲染 HTML
    Server->>Browser: 回傳包含內容的完整 HTML
    Browser->>Browser: 顯示頁面 (內容可見)
    Browser->>Server: 下載 JS 檔案
    Browser->>Browser: 執行 JS (Hydration)

    %% 靜態網站生成 SSG
    Note over User,CDN: 靜態網站生成 (SSG)
    User->>CDN: 請求頁面
    Note over CDN: 頁面在建置時已生成並存放在此
    CDN->>User: 回傳靜態 HTML
    User->>User: 立即顯示頁面

快速比較表

特性 Client-Side Rendering (CSR) Server-Side Rendering (SSR) Static Site Generation (SSG)
渲染地點 使用者瀏覽器 網頁伺服器 建置伺服器（Build Time）
首次載入速度 (FCP) 慢 快 極快
頁面切換速度 極快 較慢 (需請求伺服器) 極快
SEO 友善度 較差 極佳 極佳
伺服器負擔 低 高 幾乎為零
開發複雜度 相對簡單 高 中等
適用場景 高度互動的 Web App、管理後台 重視 SEO 的內容網站、電商網站 部落格、文件站、行銷頁面、作品集

實務上，該如何選擇？

沒有最好的技術，只有最適合的場景。可以問自己以下幾個問題來做決定：

  1. 網站的 SEO 重要嗎？

    • 是，非常重要：優先考慮 SSR 或 SSG。這是內容型網站、新聞媒體、電商平台的首選。
    • 否，不重要：CSR 完全可以。例如，內部管理系統、需要登入才能使用的 Web App 等，SEO 不是主要考量。

  2. 內容是高度動態的，還是相對靜態的？

    • 高度動態且個人化：例如社群媒體的動態牆、股票看板。這種情況下 SSR 是個好選擇，因為內容因人而異且即時變化。CSR 搭配 SWR 或 React Query 等資料快取策略也很適合。
    • 相對靜態：例如部落格文章、產品介紹頁、公司官網。內容不常變動。SSG 是完美選擇，能提供極致的效能和安全性。

  3. 使用者體驗的哪個環節最重要？

    • 希望使用者盡快看到內容：選擇 SSR 或 SSG，它們的 FCP 表現優異。
    • 希望首次載入後，後續操作如絲般順滑：選擇 CSR，它能提供最佳的 App-like 體驗。

  4. 團隊和伺服器資源如何？

    • 伺服器預算有限，團隊希望快速開發：CSR 或 SSG 是更經濟實惠的選擇。SSG 可以部署在免費的平台上（如 Vercel, Netlify, GitHub Pages）。
    • 有足夠的伺服器資源和維運能力：SSR 可以納入考量，它雖然成本較高，但能靈活應對各種需求。

現代框架的混合方案

值得一提的是，像 Next.js 和 Nuxt.js 這樣的現代框架已經模糊了這些模式的界線。它們允許在同一個專案中，為不同的頁面選擇不同的渲染策略。

  • 可以將行銷頁面設為 SSG。
  • 將部落格文章設為 SSR（或使用 ISR - 增量靜態再生，一種 SSG 的進化版，可以定期更新靜態頁面而無需重建整個網站）。
  • 將使用者儀表板設為 CSR。

這種靈活性，讓開發者能夠針對每個頁面的特性做出最優化的選擇。

結論

理解 CSR、SSR 和 SSG 不再是一件困難的事。它們各自代表了在效能、SEO、開發體驗和成本之間的不同權衡。

  • CSR：為互動而生，適合內部應用。
  • SSR：為 SEO 和快速首屏而生，適合動態內容網站。
  • SSG：為極致效能和低成本而生，是靜態內容的王者。

希望這篇文章能為你撥開前端渲染的迷霧。下一次啟動新專案時，將能更有信心地說出：「根據我們的需求，我選擇…」，並為使用者打造出更快、更棒的網路體驗。