本文以 React、Vue 為例，介紹下主流的渲染模式以及在主流框架中如何實現(xiàn)上述的渲染模式。

前置知識介紹

看渲染模式之前我們先看下幾個主流框架所提供的相關(guān)能力，了解的可跳到下個章節(jié)。

掛載組件到 DOM 節(jié)點

這是主流框架最基本的能力，就是將組件渲染到指定的 DOM 節(jié)點上。在 React 中所使用的 API 是 render，在 Vue 中所使用的是 createApp 后的 mount。

水合

水合用來將組件渲染到已有的靜態(tài)內(nèi)容上，用于為靜態(tài)頁面恢復(fù)其交互和動態(tài)能力。在 React 中所使用的 API 是 hydrate（React 18 前的版本） 和 createHydrate（React 18），在 Vue 中所使用的是 createSSRApp 后的 mount。

Vue 中的 API 語義稍顯奇怪，因為使用 createSSRApp 的場景并不一定是 SSR。

輸出渲染內(nèi)容

主流框架除了可以將組件渲染到 DOM 節(jié)點上以外，還能將其要渲染的內(nèi)容直接輸出為如 HTML 字符串等形式。輸出為字符串的 API 在 React 和 Vue 中所使用的 API 都叫做 renderToString。

React 中還推出了很多其它的 API：如 renderToStaticMarkup、 renderToStaticNodeStream 等等。功能基本一致，不影響本文的內(nèi)容所以此處不細說了。下面的例子中僅以 renderToString 為例。

主流渲染模式

知道了主流框架的這幾種能力，我們再來通過標題提到的幾種主流渲染模式看下他們能用來組合出什么樣的效果，

CSR - Client Side Rendering - 客戶端渲染

CSR 就是我們常見的 SPA 所使用的渲染方式，所有的主流框架都支持，或者說：只要是在客戶端渲染過程中使用到了腳本都可以算作客戶端渲染。

CSR 主要流程為：

1. 瀏覽器加載頁面
2. 加載對應(yīng)的腳本
3. 腳本執(zhí)行時向頁面中渲染內(nèi)容，此步驟一般包含兩種方式：
   1. 向一個空節(jié)點中渲染內(nèi)容，一般應(yīng)用于純粹的 CSR 應(yīng)用。這里使用的就是上面提到的掛載組件的功能。
   2. 向一個已有內(nèi)容的節(jié)點中渲染內(nèi)容，通常應(yīng)用于 CSR 與其它渲染模式（SSR、SSG、ISR）結(jié)合的場景下

CSR 的使用場景定義也很簡單，如果在客戶端頁面有動態(tài)需求或需要交互則必須使用。

SSR - Server Side Rendering - 服務(wù)端渲染

SSR 是另一個比較常見的渲染模式，使用這種渲染模式可以從服務(wù)端直接返回要渲染的靜態(tài)內(nèi)容。

其常見流程為：

1. 瀏覽器發(fā)起 HTTP 請求對應(yīng)的頁面
2. 服務(wù)端接收到請求后準備渲染頁面所需要的數(shù)據(jù)
3. 將所需要的數(shù)據(jù)傳入需要渲染的頁面組件中然后通過 renderToString 輸出為靜態(tài)內(nèi)容
4. 拼接頁面模版、水合腳本等將生成的靜態(tài)內(nèi)容返回到瀏覽器，瀏覽器進行渲染
5. 瀏覽器渲染內(nèi)容，執(zhí)行水合腳本恢復(fù)頁面交互和動態(tài)能力

純粹的 SSR 指代的接收到請求、輸出靜態(tài)內(nèi)容、返回瀏覽器的模式。水合的相關(guān)部分是屬于 CSR 的內(nèi)容。

要注意水合并不是必須的，可以按需選擇。比如如果你的需求是要對不同的用戶展示不同的頁面，然而頁面上并沒有任何可以交互或動態(tài)的內(nèi)容，那完全可以忽略水合的部分。

SSR 一般應(yīng)用于以下場景：

1. 出于首頁打開速度、用戶體驗、SEO 等目的需要讓用戶更快的看到頁面首屏內(nèi)容
2. 想要預(yù)先渲染的頁面內(nèi)容中存在動態(tài)的內(nèi)容

SSG - Static Site Generation - 靜態(tài)站點生成

SSG 現(xiàn)在也比較常見，它所指代的是在構(gòu)建階段就將頁面所需要的數(shù)據(jù)準備好然后將需要的頁面通過腳本構(gòu)建為靜態(tài)內(nèi)容的模式。

其常見流程為：

1. 在構(gòu)建階段構(gòu)建腳本遍歷所有需要靜態(tài)構(gòu)建的頁面
2. 獲取渲染所需要的數(shù)據(jù)并通過 renderToString 輸出為靜態(tài)內(nèi)容
3. 將靜態(tài)內(nèi)容拼接頁面模版和水合腳本等內(nèi)容后保存到文件中
4. 瀏覽器發(fā)起請求時從服務(wù)端返回靜態(tài)頁面（一般直接使用靜態(tài)文件服務(wù)器即可）
5. 瀏覽器渲染內(nèi)容，執(zhí)行水合腳本恢復(fù)頁面交互和動態(tài)能力

純粹的 SSG 指代的同樣是不包含 CSR 部分的內(nèi)容，即構(gòu)建階段生成靜態(tài)頁面并在請求時直接將靜態(tài)頁面返回的過程。水合過程同樣不是必須的，視需求決定即可。

SSG 一般應(yīng)用于以下場景：

1. 出于首頁打開速度、用戶體驗、SEO 等目的需要讓用戶更快的看到頁面首屏內(nèi)容
2. 頁面中基本都是靜態(tài)內(nèi)容，變動很少或變動的時機比較固定

所以常用于通過 CMS 生成內(nèi)容、博客站點等靜態(tài)內(nèi)容較多的場景。

ISR - Incremental Static Regeneration - 增量靜態(tài)再生

ISR 目前使用的不多，它算是 SSG 的一種增強版，指的是在 SSG 的基礎(chǔ)上，服務(wù)端在收到頁面請求時會對頁面的時效性進行判斷，如果認定失效則會對該頁面進行增量構(gòu)建的一種模式。

其常見的流程如下：

可以看出 ISR 在構(gòu)建和客戶端環(huán)節(jié)沒有任何的變化，而是增加了 Server 端的邏輯：

1. 在服務(wù)端收到對應(yīng)頁面請求時服務(wù)端會先返回當前內(nèi)容然后對頁面做失效驗證
2. 如果頁面實現(xiàn)，服務(wù)端會對失效的頁面進行后臺增量構(gòu)建
3. 當下次請求到達時如果新的頁面已經(jīng)生成成功則會返回新頁面的內(nèi)容，但在此之前還會繼續(xù)使用舊頁面的內(nèi)容

當然上述的邏輯并不絕對，先增量構(gòu)建再返回也同樣是 ISR，只是一般這樣會影響到用戶體驗一般不推薦。

ISR 適用的場景是：

1. 網(wǎng)站匹配 SSG 場景
2. 但對頁面有一定的實時性要求

比如說天氣預(yù)報頁面，可能半小時更新一次即可，或者是新聞頁面，在存在新數(shù)據(jù)時再進行增量構(gòu)建也是一種解決方案。

如何選擇

在選擇渲染模式時我們通過以下邏輯進行簡單的判斷：

1. 客戶端頁面是否需要動態(tài)或交互能力，如果要則 CSR 為必選
2. 如果頁面有 SEO、首屏、性能等需求
   1. 如果頁面中想要靜態(tài)展示的內(nèi)容對每次訪問都可能存在差異——比如每個用戶看到的頁面信息不同，則可以選擇 SSR
   2. 如果頁面中靜態(tài)展示的內(nèi)容對每次訪問沒有差異性即可選擇 SSG
      1. 如果頁面中的靜態(tài)內(nèi)容變動較為頻繁，則可選擇 ISR

其次還要注意 SSR 和 ISR 都需要服務(wù)端的支持，所以如果只有靜態(tài)文件服務(wù)器那需要的改動就比較大了。

最后

渲染模式其實遠不止以上幾種，很多場景下都可以進行相應(yīng)的優(yōu)化。以下是一些我能想到的場景：

• 在錄入或更新數(shù)據(jù)時通過 WebHook 等通知構(gòu)建系統(tǒng)進行增量構(gòu)建，算是 ISR 的一種變種
• 在 SSR 場景下可以對靜態(tài)組件和動態(tài)組件進行區(qū)分，將靜態(tài)組件使用 SSG 輸出，然后將其拼接到頁面中。

所以沒有最好的只有最適合的，按需選擇最適合自己需求的渲染模式即可。

如果想要看 SSR、SSG、ISR 的具體實現(xiàn)請看我之前的文章。文章來源地址http://www.zghlxwxcb.cn/news/detail-513952.html

到了這里，關(guān)于什么是 CSR、SSR、SSG、ISR - 渲染模式詳解的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！