# HTML 從哪裡來：用一條路徑看懂 SSR / CSR / SSG / ISR
> SSR、CSR、SSG、ISR 都在回答同一個問題：這份 HTML 是在 build 時、每次 request 時，還是在瀏覽器裡生成的。先決定生成位置，再挑框架功能，縮寫就不用背。
原文：https://sheng.page/posts/where-does-html-come-from/ · 發布：2025-11-15 · 作者：Sheng
每次有人問我 SSR 跟 SSG 差在哪，我都不想直接背定義。背完縮寫，下次換個框架、換個行銷名詞，又得重背一次。比較耐用的問法只有一個：使用者這次在瀏覽器裡看到的這份 HTML，到底是「何時、在哪裡」被生出來的。把這個問題想清楚，那堆縮寫就只是同一條路徑上的幾個切點而已。
那條路徑很單純：有人發了一個 request，某個地方把資料填進 template，產出 HTML，最後送到瀏覽器渲染。差別只在「填資料、產 HTML」這一步發生在哪個時間點、哪一台機器上。
## 同一條路徑，四個切點
SSR 是每次 request 進來，server 當場跑一遍，把當下的資料組成 HTML 再回傳。使用者收到的第一份文件就是完整的內容，資料是這一刻的。CSR 反過來，server 先丟一個幾乎空的殼，真正的內容等瀏覽器把 JS 載完、跑完、打完 API 才畫得出來，第一屏的責任整個壓在 client 身上。SSG 更早，HTML 在 build 的時候就先生好存成靜態檔，request 進來只是把現成的檔案送出去，快歸快，但內容停在你上次 build 的那個瞬間。
ISR 是補 SSG 的洞。純 SSG 的痛是資料一變就得重 build 整站，站一大就慢到不像話。ISR 的作法是 build 時先生一批，之後讓某個頁面在「過期」時按需在背景重生一份，重生好就換掉快取裡的舊版。於是你拿到靜態檔的速度，又不必為了改一篇內容把整站重跑一次。
講到這裡會發現，這四個名詞其實是在回答同一個問題的不同答案：產 HTML 這件事，要放在 build 時、第一次 request 時，還是每一次 request 時做。SSG 在 build 時，SSR 在每次 request，ISR 卡在兩者中間，CSR 乾脆把這步推到瀏覽器去。框架的命名再花俏，骨子裡都跑不出這條軸線。
## 為什麼這個心智模型比名詞值錢
名詞會過時，框架行銷詞每年換一輪，但「HTML 在哪生成」這個問題不會。你一旦習慣這樣想，遇到任何新框架、新 render 模式，會自動去問四個對的問題，而不是被它的命名牽著走。
第一要看資料需要多新：報價、庫存與即時排行若放在 SSG，使用者會看到過期資料；三個月才改一次的技術文章若每次 request 都重算，又是在浪費 server。第二是運算由誰負擔，SSR 把組 HTML 的成本留在伺服器，流量尖峰會考驗容量；CSR 把成本交給使用者的瀏覽器，低階手機可能因此變慢。第三是快取失效條件，SSG 與 ISR 靠靜態檔換取速度，也必須說清楚舊資料何時、依什麼條件換掉。第四是第一屏由誰負責，SSR 與 SSG 送出的第一份文件已有內容，對 SEO 與首屏速度較友善；CSR 則要等 JS 跑完才顯示內容。
拿同一個頁面套四種模式，trade-off 立刻現形。一個電商商品頁：走 SSG，快但價格庫存可能過期；走 SSR，永遠最新但每次 request 都吃 server；走 ISR，多數時候送靜態檔、過幾分鐘背景更新一次，價格的即時性和伺服器成本之間取個平衡；走純 CSR，HTML 秒回但使用者要先盯著骨架等資料載進來，對 SEO 也不友善。沒有哪個一定對，全看你願意拿新鮮度換延遲、還是拿伺服器成本換新鮮度。
所以順序應該倒過來。先想清楚「這個頁面的 HTML 該在哪裡生成」，這是一個關於資料新鮮度、運算成本、快取邊界的設計決定；想清楚之後，再回頭去看哪個框架、哪個 render 模式剛好實作了你要的那個切點。先選框架功能、再回頭勉強兜出一套說法，通常就是被命名牽著走的開始。
## 補充筆記
- 不要背縮寫，先問「使用者這次看到的 HTML 是何時、在哪裡生成的」。
- SSR、CSR、SSG、ISR 是同一條 request→HTML 路徑上的不同切點，差別在產 HTML 放在 build 時、每次 request、還是丟給瀏覽器。
- 想通生成位置，你會自動問對問題：資料多新、運算誰扛、快取怎麼失效、第一屏誰負責。
- 同一個頁面套四種模式，本質是在新鮮度、延遲、伺服器成本之間取捨，沒有通用最佳解。
- 先決定 HTML 在哪生成，再去挑框架功能，不要讓框架的命名替你做設計決定。
> 想法與技術判斷出自 Sheng，和 Claude 一起起草 · 列入 20260613 blog 翻新計劃，新漆未乾。