SSG & CSR & SSR - 現代 Web 的渲染方式

前言

在前端世界中，「渲染策略」一直是核心課題之一。

從最早的靜態網站，到後來需要即時性與互動性的應用，我們不斷嘗試不同的方式來兼顧速度、體驗與維護性。

特別是現在網路的使用場景越來越多元了，單純依靠一種渲染模式已經不足以滿足所有需求。

因此，了解不同的渲染方式就非常重要，這篇文章會帶你了解並比較三種主要的渲染方式：SSG (Static Site Generation)、CSR (Client-Side Rendering)、SSR (Server-Side Rendering)。

SSG (Static Site Generation)：前端渲染的第一步

絕大部分的人在接觸前端開發時，都是先透過 SSG (Static Site Generation) 來做網站的，比如說只用 HTML + CSS 寫基本的網站，並且部署到 GitHub Page，相信你剛學前端可能也是用這種方式。只是當時沒有 SSG 的概念：

SSG 的流程很簡單：

• 建置階段：把 HTML、CSS、JS 全部生成好，放到 CDN。
• 使用者請求：瀏覽器直接拿完整 HTML，快速顯示頁面。
• 之後互動：再由 JS 裝載互動功能。

SSG 很適合在內容不會頻繁更新的網站，想是部落格、公司官網等。因為不需要頻繁更新，代表只需要 Build 一次就好。

SSG 優點

• 首屏加載速度快：HTML 已經準備好，用戶一打開就有內容。
• SEO 友好：搜尋引擎能立即讀到完整 HTML，不需等待 JS。
• 可快取、便於部署：放在 CDN 上，全球都能快速訪問。
• 穩定性高、成本低：沒有動態伺服器邏輯，幾乎不會出問題。

SSG 缺點

但隨著專案越來越複雜，SSG 開始會遇到一些瓶頸：

• 內容更新延遲：一旦資料更新，就必須重新 build 部署。
• 個人化困難：因為是提前 build 好的，所以所有人都會看到相同的 HTML，無法針對使用者定制內容。
• 建置時間過長：當網站頁面數量龐大（例如數萬商品頁），build 會變得非常慢。

這時候，前端社群提出了另一種解法 —— CSR (Client-Side Rendering)。

CSR (Client Side Rendering)：讓瀏覽器自己生 HTML

CSR 的核心想法很直觀：

既然伺服器給不了最新資料，那乾脆讓瀏覽器自己用 JS 抓資料、自己生成 DOM。

也就是我們單純用 React 或是 Vue 的方法，CSR 的流程會是：

一、伺服器回傳一個「空殼 HTML」

<div id="root"></div>
<script src="bundle.js"></script>

二、瀏覽器下載 bundle.js，執行 React/Vue 程式碼。

三、React/Vue 在客戶端 fetch API，組出 DOM，插入畫面。

這樣就解決了 SSG 的問題。

CSR 優點

• 資料即時性：不用重新 build，每次都能即時抓資料。
• 個人化：使用者登入後，可以渲染專屬內容。
• **切換頁面快速：**頁面跳轉只需要更新部分 UI，而不是整個 HTML 重載，使用者體驗上感覺流暢、接近原生 App。
• 前後端解耦：純靜態託管 + API 即可上線，部署與擴展簡單。

CSR 缺點

但是，CSR 又帶來新的挑戰，像是：

• 首屏加載(FCP)慢、Bundle 體積大：所有組件邏輯都必須傳到瀏覽器端執行，頁面、app 越大，JS bundle 體積越龐大，載入時間就越長。
• SEO 不佳：初始載入時，頁面只有 <div id="root">，真正的內容需要等到 JS 執行後才生成。 早期搜尋引擎無法執行 JS，導致網站被判斷為「空白」，SEO 效果極差。雖然現代搜尋引擎已有改善，但 SSR 與 RSC 仍能帶來更佳的效能與 SEO 優勢。
• 裝置效能瓶頸：把所有渲染工作丟給使用者裝置，低階或行動端更易掉幀、交互延遲。

於是，社群又開始思考：我們能不能乾脆讓伺服器，根據使用者需求，直接先渲染好 HTML？

沒錯就是 SSR (Server-Side Rendering)。

SSR (Server-Side Rendering)：讓伺服器幫你預先渲染

為了兼顧 SSG 的速度與 SEO 與 CSR 的即時性與個人化，React 團隊開始思考 SSR (Server-Side Rendering) 的可能性。

SSR 的概念是，伺服器先執行 React，渲染好基本的 HTML 並回傳；瀏覽器收到後再做 Hydration 注水。

Hydration 聽起來很複雜，但他的概念也很簡單。在使用者收到伺服器回傳的 HTML 後，是只有內容而不能互動的，例如按鈕點擊、滾動觸發等等需要 JS 的互動功能，這時 React 就會先執行 JS 進行，讓網頁是可以互動的。

可以想像不能互動的網頁是乾的，注水後就有了活力可以互動，所以稱為 Hydration。

SSR 其實不是新的概念，早期很流行的 PHP 就屬於 SSR。

SSR 優點

SSR 可以說是結合 SSG 和 CSR 的優點：

• 更好的 SEO 與首屏速度：使用者一打開就能看到完整內容。
• 即時資料：每次請求都會重新執行伺服器邏輯，可即時顯示最新內容。
• 適合個人化內容：伺服器可以依據 session、cookie、auth token 直接生成使用者專屬 HTML。

SSR 缺點（要面對的工程現實）

儘管 SSR 很厲害，但他也還是有相應的缺點：

• 伺服器壓力大：每個請求都要渲染一次，對流量大的網站是一大挑戰。
• TTFB（Time To First Byte）增加：伺服器需要先計算要渲染的內容後才能回傳，延長了等待時間。
• 複雜度提升：需要平衡伺服器運算成本、快取策略、前後端分工。

TTFB 和 FCP 的差別

一開始看到 SSR 的缺點時，有點疑惑 TTFB 和 FCP 聽起來很像，但他們是不一樣的東西

• TTFB（Time To First Byte）: 收到伺服器回傳的第一筆位元組，簡單說就是伺服器回應的速度，會受到網路延遲以及伺服器的運算影響
• FCP (First Contentful Paint)：使用者從請求開始，到瀏覽器「畫出第一個可見內容」的時間。會受到 TTFB + JS/CSS 資源大小影響

CSR：TTFB 低（伺服器馬上回一個空殼 HTML），但 FCP 高（要等 JS 載入執行後才有畫面）。

SSR：TTFB 高（伺服器慢一點才回應），但 FCP 低（一旦回應了，HTML 已完整，可立即顯示內容）。

如何決定渲染策略？

理解了 SSG、CSR、SSR 的優缺點後，最重要的就是：在不同的專案情境下，我們要如何選擇合適的渲染方式？

有個很重要的重點是，這些渲染策略是可以結合的，我可以一部份用 SSG，一部分用 CSR 來生成網站，所以要依據需求來取捨。

1. 純內容網站（文件、部落格、公司官網）

• 推薦：SSG
• 這類網站的內容更新頻率低，使用者互動性不高。
• 預先建好靜態頁面，放到 CDN，即可達到極佳的效能與 SEO。
• 如果內容偶爾需要更新，可以搭配 Incremental Static Regeneration (ISR) 來避免整站重 build。

2. 高度動態的應用（Dashboard、後台系統、登入後的個人頁面）

• 推薦：CSR 或 SSR
• 使用者資料都是即時且個人化的，SSG 完全不適合。
• 如果 SEO 不重要（例如內部系統），直接使用 CSR 即可，減少伺服器壓力。
• 如果 SEO 重要（例如公開的會員頁），SSR 會更合適。

3. 電商網站 / 資訊平台

• 混合策略：SSG + SSR
• 商品頁數龐大，若全部用 SSG 會導致 build 過慢。
• 可以針對「熱門商品」使用 SSG（甚至加上 ISR 快取），確保首屏快速。
• 其他商品則使用 SSR，確保能即時顯示庫存與價格。

4. 需要即時內容的頁面（新聞、股市、賽事）

• 推薦：SSR
• 每次請求都要是最新的內容，這時候伺服器渲染的優勢就很明顯。
• 可以搭配 Edge Rendering（邊緣渲染）來縮短延遲。

5. App-like 體驗的前端應用（例如 Gmail、Notion）

• 推薦：CSR
• 這類應用幾乎完全依賴使用者互動，SEO 也不是重點。
• CSR 可以讓頁面切換非常流暢，體驗接近原生 App。

總結

• SSG 適合靜態、更新不頻繁的內容型網站。
• CSR 適合互動性強、SEO 不重要的應用型網站。
• SSR 適合需要即時性、個人化、同時也要顧及 SEO 的網站。

而這些渲染方式可以混合使用，在適合的頁面選擇相對的策略才能讓網站的速度提升！