你是否曾經看到 SSR、CSR、SSG、ISR 這些縮寫，卻完全不知道它們在說什麼？
這篇文章會帶你從頭理解這四種渲染方式的差別、各自的優缺點，以及什麼情況下該選哪一種。
先搞懂這四個縮寫的意思
- SSR：Server Side Rendering（伺服器端渲染）
- CSR：Client Side Rendering（客戶端渲染）
- SSG：Static Site Generation（靜態網站生成）
- ISR：Incremental Static Regeneration（增量靜態再生）
光看名字還是很抽象對吧？
別擔心，我們先來了解一個網頁從「開發完成」到「呈現在使用者螢幕上」會經過哪些步驟，因為這四種方式的差異，全都藏在這個流程裡。
網頁從開發到顯示的三個步驟
每個網站從「開發者寫完程式碼」到「使用者看到畫面」，都會經歷以下三個階段。
理解這三個步驟非常重要，因為 SSR、CSR、SSG、ISR 的所有差異，其實就是「這三個步驟各自花多少時間、由誰來做」的不同分配方式。
第一步：Build（建置）
開發者在寫程式時，通常會使用一些比較新的語法（例如 TypeScript）或工具（例如 React），但瀏覽器和伺服器並不認識這些東西，它們只看得懂最基本的 HTML、CSS 和 JavaScript。
所以在把網站部署上線之前，需要先執行一道「Build」程序，把開發者寫的程式碼轉換成瀏覽器和伺服器真正能執行的格式。
Build 這個步驟就是在做這件事：
- 把 TypeScript 編譯成 JavaScript
- 把多個 JavaScript 檔案打包成一個或少數幾個檔案（Bundle）
- 把 CSS 壓縮、圖片最佳化
- 移除開發用的除錯資訊，讓檔案更小、更快
Build 通常發生在「開發者把程式碼部署到伺服器之前」，也就是還沒有任何使用者造訪的時候。
這個步驟的特點是：只做一次（或每次更新程式碼時重做一次），不會因為使用者增加而變慢。
第二步：Server（伺服器處理請求）
當使用者在瀏覽器輸入網址、按下 Enter 的那一刻，其實是在向伺服器「發出請求」，告訴它：「我想看這個頁面。」
伺服器收到請求後，會從資料庫撈取需要的資料、組出 HTML 頁面，再傳回給使用者。
這個步驟的特點是：每次有使用者造訪就會觸發一次，使用者越多、頻率越高，所以伺服器越忙、成本越高。
第三步：Client（客戶端渲染）
「Client」指的就是使用者的瀏覽器，也就是 Chrome、Safari、Firefox 這些應用程式。
瀏覽器從伺服器收到資料後，需要把它轉換成你實際看到的畫面，這個過程就叫做「渲染」。
伺服器傳來的資料通常是 HTML、CSS 和 JavaScript 檔案。
瀏覽器會先讀取 HTML，決定頁面上有哪些元素（標題、段落、圖片等），再套用 CSS 決定每個元素的樣式（顏色、大小、位置），最後執行 JavaScript 讓頁面能夠互動（按鈕點擊、表單送出等）。
這個步驟的特點是：發生在使用者的裝置上，所以工作量越大，低階手機或舊電腦的使用者感受越差。
這三個步驟各自花多少時間、由誰來承擔，就是 SSR、CSR、SSG、ISR 最大的差別所在。
接下來我們就來看每一種方式是怎麼運作的。
傳統伺服器渲染是什麼？最古老的網頁渲染方式
在 React 等前端框架出現之前，網頁基本上都是用這種方式運作的。
傳統伺服器渲染流程特色
傳統 SSR 的 Build 時間短
這個階段只需要把程式碼編譯打包成可以執行的格式，不需要做任何與頁面內容相關的事情。
傳統 SSR 的 Server 負擔最重
每次使用者發出請求，伺服器都要即時執行以下流程：連線資料庫、撈取這個使用者需要的資料、把資料填進 HTML 模板、組出完整的頁面，最後再把頁面傳給使用者。
這整個過程每次請求都要重新走一遍，使用者越多、伺服器越忙。
傳統 SSR 的 Client 幾乎不用做任何事
因為伺服器已經把完整的 HTML 頁面傳過來了，瀏覽器只需要直接顯示就好，不需要額外執行任何 JavaScript 來組出內容。
如何辨識傳統伺服器渲染
每次點擊連結，整個頁面都會重新載入（Full Page Refresh），通常就是傳統伺服器渲染。
CSR 是什麼？客戶端渲染的運作方式與優缺點
這是 React 等前端框架剛出現時，最常見的做法。
CSR 流程特色
CSR 的 Build 時間短
和傳統伺服器渲染一樣，這個階段只需要把程式碼編譯打包，不需要做任何與頁面內容相關的事情。
CSR 的 Server 幾乎不做任何事
使用者發出請求後，伺服器只是把一個幾乎空白的 HTML 檔案和一堆 JavaScript 檔案傳給使用者，完全不做任何額外處理。
這個空白的 HTML 檔案裡幾乎沒有任何內容，只有一個空的 <div> 和幾個 <script> 標籤，用來載入 JavaScript。
CSR 的 Client 負擔最重
瀏覽器收到空白 HTML 之後，需要下載並執行所有的 JavaScript，再由 JavaScript 去呼叫 API 取得資料、組出頁面結構、套上樣式，最後才把內容顯示出來。
這意味著在 JavaScript 還沒執行完之前，使用者看到的只是一片空白。
裝置越慢、網路越差，等待時間越長。
如何確認一個網站是 CSR
你可以在瀏覽器對著網頁按右鍵 → 「檢視頁面原始碼」，如果你看到的 HTML 裡面幾乎是空的，只有一些 <script> 標籤，那這個網站就是 CSR。
適合的情境：
- 快速搭建不需要伺服器的網站（例如 prototype、內部工具）。
- 不在乎 SEO 的應用程式。
缺點：
- SEO 差，因為搜尋引擎爬到的是空白 HTML。
- 使用者裝置越慢，畫面出現的時間越長。
SSR 是什麼？伺服器端渲染如何解決 CSR 的問題
SSR 結合了傳統伺服器渲染與 CSR 的優點，是目前許多現代框架（例如 Next.js）的主要做法。
SSR 流程特色
SSR 的 Build 時間短
和 CSR 一樣，這個階段只需要把程式碼編譯打包，不需要預先生成任何頁面內容。
SSR 的 Server 負責組出完整的 HTML
使用者發出請求後，伺服器會連線資料庫、撈取需要的資料，再把資料填進頁面模板，組出一份完整的 HTML，才傳給使用者。
所以使用者收到的不是空白頁面，而是已經有內容的完整頁面，可以立即看到畫面，不需要等待 JavaScript 執行。
SSR 的 Client 只需要執行 Hydration
瀏覽器收到完整 HTML 後，頁面雖然看起來已經有內容，但這時候還是一個「靜止的」頁面，按鈕點不了、表單沒有反應。
瀏覽器接著會載入 JavaScript，把 React 等前端框架和現有的 HTML 連結起來，讓頁面上的互動功能生效，這個過程就叫做 Hydration。
Hydration 的字面意思是「補水」。
這個命名其實很直觀：SSR 傳來的 HTML 有結構、有內容，但缺少互動邏輯，就像脫水的狀態，只有外型但沒有生命力。
Hydration 做的事，就是把 JavaScript 的互動邏輯「注入」進去，讓頁面從靜態變成可以互動的動態應用。
這和 CSR 不同。
CSR 是瀏覽器拿到空白 HTML，要用 JavaScript 從頭把整個頁面內容組出來。
Hydration 則是頁面內容已經在 HTML 裡了，JavaScript 只需要接管互動功能，工作量少很多。
適合的情境：
- 需要登入功能、個人化資料等動態內容的網站。
- 重視 SEO 的網站（因為 HTML 是完整的）。
- 需要在低階裝置上有良好體驗的應用程式。
SSG 是什麼？靜態網站生成的優缺點與適用情境
SSG 的概念是「把所有工作都在 Build 階段做完」，讓伺服器和客戶端都輕鬆。
SSG 流程特色
SSG 的 Build 時間長
這是 SSG 和其他方式最大的不同。
Build 時不只是編譯打包程式碼，還會把網站裡每一個頁面的 HTML 全部提前生成好，並存成靜態檔案。
如果你的網站有 100 篇文章，Build 時就會生成 100 個 HTML 檔案，每一個都是完整的頁面，裡面已經填好所有資料。
SSG 的 Server 幾乎不做任何事
使用者發出請求後，伺服器不需要連線資料庫、不需要組頁面，只是把 Build 時已經生成好的 HTML 檔案直接傳出去。
SSG 的 Client 負擔極小
瀏覽器收到完整的 HTML，幾乎不需要做任何額外處理，直接顯示就好。
不需要像 CSR 一樣執行大量 JavaScript 才能看到內容，也不需要像 SSR 一樣執行 Hydration，頁面載入速度非常快。
為什麼 SSG 這麼快？
因為 SSG 的頁面是在 Build 時就已經生成好的靜態檔案，伺服器不需要做任何運算，可以直接傳出去。
這種「不需要即時處理」的特性，讓這些檔案可以提前複製到全球各地的 CDN（內容傳遞網路）伺服器上。
當使用者發出請求，CDN 會自動把請求導向距離最近的節點，讓使用者直接從附近拿到檔案，不需要繞到遠端的原始伺服器，速度非常快。
SSR 和 CSR 無法這樣做。
SSR 的頁面是根據每個使用者的請求即時產生的。
例如登入後看到自己的名字、購物車、個人化推薦等，每個人看到的內容可能都不一樣。
所以無法提前生成一份靜態檔案放到 CDN 上讓所有人共用。
CSR 則需要在瀏覽器端執行 JavaScript 才能組出內容，同樣沒有可以直接分發的靜態檔案。
適合的情境：
- 部落格、技術文件、行銷官網等內容相對固定的網站。
- 對效能和 SEO 都有極高要求的網站。
缺點：
- 無法處理動態內容（例如使用者登入後看到不同的資料）。
- 如果網站頁面數量龐大（例如有上萬個商品的電商），Build 時間可能長達數小時，甚至更久。
ISR 是什麼？增量靜態再生如何結合 SSG 與 SSR
ISR 可以說是 SSG 和 SSR 的混合體，專門解決 SSG 在「動態資料」和「頁面太多」這兩個痛點。
ISR 流程特色
ISR 的 Build 時間比 SSG 短
SSG 在 Build 時要把所有頁面全部生成完，如果網站有上萬個頁面，Build 時間可能長達數小時。
ISR 不需要這樣做，Build 時只需要先生成最重要或最常被造訪的頁面，其他頁面等到使用者第一次造訪時再生成就好，大幅縮短了 Build 的時間。
ISR 的 Server 處理時間比 SSR 短
ISR 的伺服器有兩種情況：
如果使用者請求的頁面已經有快取好的靜態版本，伺服器直接把它傳出去，就和 SSG 一樣快，幾乎不需要做任何運算。
如果使用者請求的頁面資料已經過期，或者是第一次被造訪、還沒有靜態版本，伺服器才會重新生成這個頁面，然後把新版本快取起來，之後的使用者就能拿到快取好的版本了。
ISR 的 Client 負擔極小
和 SSG 一樣，瀏覽器收到的是完整的 HTML，直接顯示就好，不需要執行大量 JavaScript 來組出內容。
ISR 的運作邏輯
上面的圖可以看到兩根柱子，分別代表 ISR 的兩種情況。
Cached（快取命中）：使用者請求的頁面已經有快取好的靜態版本，伺服器直接傳出去，幾乎不需要任何處理，所以柱子很短。
Out Of Date（資料過期）：使用者請求的頁面資料已經過期，或者是第一次被造訪還沒有靜態版本，伺服器需要重新生成這個頁面，所以 Server 的部分比較長。
以一個商品有上萬個的電商網站為例。
Build 時只需要先生成熱門商品的頁面，其他頁面等到使用者第一次造訪時再生成，這就是 Out Of Date 的情況。
一旦頁面生成並快取後，之後造訪的使用者就會走 Cached 的流程，速度和 SSG 一樣快。
當商品資料更新後，也不需要重新 Build 整個網站，只要下一個使用者造訪該頁面，ISR 就會在背景自動重新生成最新版本，之後所有人都會拿到更新後的頁面。
適合的情境：
- 頁面數量龐大但更新頻率不高的電商網站。
- 使用 CMS（內容管理系統，例如 WordPress）的網站，內容偶爾更新但不是每秒都在變。
SSR、CSR、SSG、ISR 怎麼選？
一個簡單的判斷流程：
- 網站內容完全靜態（部落格、文件）→ 優先選 SSG。
- 頁面很多、偶爾更新 → 選 ISR。
- 有動態資料、需要使用者登入 → 選 SSR（現代版）。
- 只是要快速做一個 demo 或不需要 SEO → 選 CSR。
總結：SSR、CSR、SSG、ISR 的差異與選擇
這四種渲染方式其實都在解決同一個問題：「網頁要怎麼又快又好地呈現給使用者？」
- CSR 把工作全推給客戶端，設備越慢越痛苦。
- SSR 讓伺服器分擔工作，客戶端輕鬆很多。
- SSG 把所有工作提前在 Build 時做完，伺服器和客戶端都輕鬆，但不適合動態內容。
- ISR 結合 SSG 和 SSR 的優點，適合頁面多但不需要即時更新的網站。
沒有哪種方式是「最好的」，選擇適合自己專案需求的才是最重要的。