HTML 從哪裡來：用一條路徑看懂 SSR / CSR / SSG / ISR

每次有人問我 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 翻新計劃，新漆未乾。