SSR 為什麼到現在還是繞不開
在規劃網站架構時，尤其是高度仰賴搜尋引擎流量的專案，往往會接觸到 SSR（Server-Side Rendering，伺服器端渲染）。這個名詞廣泛出現在 Next.js、Nuxt 等現代前端框架的官方文件中，也是技術顧問在討論產品頁收錄與首屏載入速度時的核心議題。
然而，SSR 並非解決所有網頁效能與搜尋排名的萬靈丹。它是一種明確的渲染時機選擇，具備顯著優勢，也伴隨相應的伺服器運算成本與架構複雜度。以下將深入解析 SSR 的底層運作機制，對比 CSR 與 SSG 的架構差異，並釐清各應用場景的適用邊界。
SSR 是什麼：一次請求的完整生命週期
SSR 的核心邏輯在於：當瀏覽器發起網址請求時，伺服器端會即時執行應用程式的渲染邏輯，將元件樹、動態資料與版面結構完整組裝，輸出成帶有完整內容的 HTML 字串後回傳給客戶端。
這意味著瀏覽器接收到的並非空白骨架，而是結構完整的網頁。使用者在開啟頁面的瞬間，即可看見文字、標題、產品圖與排版，無需等待龐大的 JavaScript 檔案全數下載並執行完畢。
伺服器接收請求後的運作流程
以現代前端框架為例，伺服器端的處理流程如下：
- 框架路由比對請求路徑，識別對應的頁面元件。
- 執行資料獲取邏輯，查詢內部資料庫或呼叫後端 API。
- 將元件與資料結合並轉換為 HTML 字串（例如 React 的
renderToPipeableStream或 Vue 的renderToString）。 - 將產生的 HTML 連同序列化後的狀態資料（如 hydration state 或 RSC payload）及 JavaScript 腳本標籤一同回傳給瀏覽器。
瀏覽器接收 HTML 後的後續處理
瀏覽器解析 HTML 時即可逐步繪製畫面，First Contentful Paint (FCP) 與 Largest Contentful Paint (LCP) 指標在此階段能快速完成。與此同時，瀏覽器於背景非同步下載、解析並執行 JavaScript bundle。
當腳本執行完畢後，框架啟動 Hydration（水合 / 補水） 程序：將客戶端虛擬 DOM 與伺服器傳來的靜態 DOM 進行比對綁定，掛載事件監聽器並初始化元件狀態。完成後，頁面上的表單、導航選單與購物按鈕方可進行完整互動。
Hydration 機制與常見技術挑戰
Hydration 是 SSR 架構中最關鍵、也最容易衍生問題的環節。伺服器產出的 HTML 僅是一份靜態視圖快照，不包含任何事件監聽邏輯。在 JavaScript 尚未完全載入並完成 Hydration 前，使用者雖能看見按鈕，點擊卻無法即時觸發反應，這段視覺呈現與可互動之間的落差常被稱為「可互動延遲（Uncanny Valley）」。
架構核心觀念：SSR 加速的是「內容可見時間」，而非「功能可互動時間」。優化 SSR 網站的關鍵，在於盡可能縮短從「看見畫面」到「可完成互動」之間的等待間隔。
在進行 Hydration 時，若客戶端初始渲染的結果與伺服器回傳的 HTML 不一致，便會引發 Hydration Mismatch 警告。在嚴重情況下，框架甚至必須捨棄既有 DOM 重新渲染，導致畫面發生明顯閃爍（Layout Shift）。常見誘因包括：
- 在渲染邏輯中直接使用
Date.now()或Math.random()等非確定性函式。 - 直接讀取
localStorage或在元件初次渲染時依賴window物件。 - 未指定統一時區而直接依據客戶端語系格式化時間與貨幣。
CSR 是什麼：將渲染完全交付客戶端
CSR（Client-Side Rendering，客戶端渲染） 模式下，伺服器僅回傳極為精簡的 HTML 骨架（通常僅為一個空容器標籤）與相應的腳本連結。頁面所有 DOM 結構與資料渲染，均交由瀏覽器下載並執行 JavaScript 後動態建構。
優勢：伺服器負載極低，所有靜態資源均可部署於全球 CDN 節點進行邊緣快取；前後端分工明確，頁面切換由前端路由直接接管，互動體驗流暢。
限制：首屏需要依賴龐大的腳本下載與解析，在中低階行動裝置或網路不穩定的環境下，容易出現白屏現象，導致 LCP 指標表現不佳。儘管現代搜尋引擎（如 Googlebot、Bingbot）具備執行 JavaScript 的能力，但根據 Google 官方 JavaScript SEO 指南，客戶端渲染的頁面仍需進入渲染佇列（Render Queue），可能導致時效性內容的索引延遲。
SSG 是什麼：於建置階段提前產出頁面
SSG（Static Site Generation，靜態網站生成） 則是在專案打包建置（Build Time）階段，直接將所有路徑預先編譯為對應的靜態 HTML 檔案，並全面發布至 CDN 節點。
優勢：首字節時間（TTFB）可壓至極低水準，無伺服器執行階段負載與運算開銷，安全風險與維運成本極低。
限制：資料變更需要觸發全站或增量重新建置。當網站規模擴展至數萬頁面時，建置時間將顯著拉長；且無法在伺服器端根據個別請求的 Cookie 或權限提供即時個人化內容。
SSR、CSR 與 SSG 全方位架構對照
| 比較維度 | SSR（伺服器端渲染） | CSR（客戶端渲染） | SSG（靜態網站生成） |
|---|---|---|---|
| HTML 產生時機 | 每次使用者發起請求時 | 瀏覽器下載並執行 JS 後 | 專案建置打包階段 |
| TTFB（首字節時間） | 需等待運算與 API 查詢 | 極快（由 CDN 傳回空骨架） | 最快（CDN 直接回應靜態檔） |
| 首次內容可見（FCP/LCP） | 快（隨 HTML 即時呈現） | 慢（需等待 JS 執行完畢） | 極快（靜態資源快速渲染） |
| 伺服器運算負載 | 較高（每次請求消耗 CPU/記憶體） | 極低（僅提供靜態檔案） | 無（建置後全由 CDN 承載） |
| 動態個人化支援 | 完整支援（可讀取 Cookie/身份） | 完整支援（前端依狀態動態請求） | 限制較高（所有人取得相同 HTML） |
| 社群預覽（Open Graph） | 原生完整支援動態標籤 | 需額外依賴預渲染或邊緣處理 | 原生完整支援靜態標籤 |
| 典型適用場景 | 動態電商、即時新聞、會員個人化首頁 | SaaS 後台系統、互動儀表板、Web App | 企業形象站、官方技術文件、靜態部落格 |
現代混合渲染架構演進
隨著前端技術的發展，單一架構已逐步演進為依據區塊彈性組合的混合渲染模式：
- ISR（增量靜態再生）：結合 SSG 的快取速度與 SSR 的即時性，頁面建置後可依據時間或事件在背景非同步更新特定路徑的靜態頁面。
- 串流 SSR（Streaming SSR）：利用 React 18 Suspense 機制，優先傳輸已就緒的頁面外殼與關鍵內容，耗時較長的安全資料查詢則透過 HTML 串流逐步傳送，大幅改善感知延遲。
- React Server Components (RSC)：讓部分元件完全在伺服器端執行，其相依函式庫不會被打包進客戶端 bundle 中，從源頭縮減 JavaScript 體積並優化 INP（Interaction to Next Paint） 指標。
- 島嶼架構（Islands Architecture）：頁面整體維持靜態 HTML，僅將需要使用者互動的元件定義為獨立「島嶼」並執行局部 Hydration，大幅降低主執行緒負擔。
搜尋引擎與社群分享的實質影響
在搜尋優化與內容傳播層面，SSR 的核心價值主要體現在以下維度：
- 中繼資料與結構化標記可靠度：Canonical、hreflang 多語系標籤以及 JSON-LD 結構化資料，均隨伺服器原始碼輸出，確保各類搜尋爬蟲直接解析，避免依賴客戶端執行所衍生的潛在遺失。
- 社群預覽卡片支援：根據 Facebook 爬蟲規範 及各大即時通訊平台機制，多數社群爬蟲僅抓取初始 HTML 內的 Open Graph 標籤，不主動執行 JavaScript。SSR 能確保動態產品頁在即時通訊工具中正確呈現縮圖與標題。
- 內部連結可爬取性：導覽列與深層內容連結直接存在於 HTML 原始碼中，利於爬蟲進行全站權重傳遞與索引發現。
技術選型決策路徑
在評估專案渲染模式時，可依據以下邏輯進行梳理：
- 頁面是否需要搜尋引擎索引或社群即時預覽？
若為純登入後系統（如管理後台、內部工具），建議優先採用 CSR。 - 頁面內容是否依據不同使用者或請求即時變更？
若內容高度穩定（如品牌介紹、技術文件、部落格文章），優先選擇 SSG 或 ISR，兼顧極致效能與極低營運成本。 - 頁面既需即時動態內容，又具備強烈 SEO 需求？
例如具備庫存與價格變動的電商產品頁、多語系多貨幣動態切換站點，此時 SSR 搭配邊緣快取 為最合適的架構選擇。
常見問題 FAQ
Q1：採用 SSR 後，網站 SEO 排名就一定會提升嗎？
不一定。SSR 能確保 HTML 原始碼具備完整的內容可讀性與中繼標籤，解決的是技術可爬取性（Crawlability）問題。搜尋排名仍取決於內容原創品質、網站權重、資訊架構以及 Core Web Vitals 的整體表現。SSR 提供了堅實的技術基礎，但無法取代高質量的內容本身。
Q2：SSR 會不會讓伺服器回應時間（TTFB）變慢？
會的。相較於 CDN 直接吐出靜態檔案的 SSG 或 CSR 空骨架，SSR 必須在伺服器端完成資料拉取與 HTML 渲染，因此 TTFB 通常會略高。實務上可透過邊緣快取（Edge Caching）、資料預取快取（SWR / Redis）以及串流 SSR 來大幅縮短等待時間。
Q3：Next.js App Router 預設就是 SSR 嗎？
不是。在 Next.js App Router 中，元件預設為 Server Component，但渲染策略預設為靜態渲染（Static Rendering）。只有當頁面使用了讀取請求資訊的動態函式（例如 cookies、headers）或配置了動態資料請求時，才會自動切換為按次請求執行的 SSR（Dynamic Rendering）。
Q4：同一個專案內可以同時混用 SSR、SSG 與 CSR 嗎？
可以，這也是現代全端框架（如 Next.js、Nuxt、Astro）的標準實踐。例如行銷首頁與活動頁使用 SSG/ISR，產品詳細頁採用 SSR 搭配快取，而會員中心與訂單管理系統則採用 CSR，以達到效能、成本與互動體驗的最佳平衡。
