前面我們提到過 Nuxt 能夠滿足我們更多開發(fā)場景的需求，這主要是因為 Nuxt3 中提供了多種渲染模式：

• 客戶端渲染 - CSR；
• 全局渲染 - SSR；
• 靜態(tài)站點生成 - SSG；
• 混合渲染 - hybrid rendering；
• 邊緣渲染 - edge-side rendering。

本節(jié)我們將深入探討幾種渲染模式的差異和各自使用場景。

傳統(tǒng)服務端渲染

在過去傳統(tǒng)開發(fā)中，頁面渲染任務是由服務端完成的，服務器負責獲取數(shù)據(jù)，拼裝頁面，客戶端僅負責內(nèi)容顯示，使用這種方式的典型技術(shù)有 JSP、PHP、ASP.NET 等等。

很顯然，這種方式中，服務器的任務比較繁重，服務器負載相對較大，這樣同等情況下一臺機器能夠同時負載的用戶數(shù)就變少了。另外開發(fā)過程中，由于前后端內(nèi)容是混在一起的，這就要求開發(fā)者要同時掌握前后端知識，要求較高。如果是由前后端工程師合作開發(fā)，也容易造成時間沖突，前端頁面不出來，后端工程師就要干等著，開發(fā)效率不高。于是后來便有了大家熟悉的 Vue.js、React 等 SPA 框架大行其道。

客戶端渲染

Vue.js、React 這類框架之所以能解決前面提到的問題，主要是因為采用了前后端分離的開發(fā)模式，這種方式的特點是頁面是由客戶端渲染的，應用在客戶端首次獲取的是空 HTML 文檔，瀏覽器下載并運行 JS，獲取數(shù)據(jù)之后再創(chuàng)建頁面，也就是大家熟悉的單頁面應用 - SPA。

這種方式，服務端僅提供數(shù)據(jù)接口，拼裝頁面的任務交給了客戶端，這樣充分利用客戶端性能，提高了服務器負載能力。開發(fā)過程中，前后端分離，前后端工程師各司其職，有效提升開發(fā)效率。

但同時，這種渲染模式也存在缺點：用戶不得不等待瀏覽器下載并執(zhí)行 JS 代碼才能看到內(nèi)容，這跟客戶端網(wǎng)速和硬件性能有關(guān)，會增加首屏加載時間，影響用戶體驗。同時，由于頁面內(nèi)容一開始為空，也會導致搜索引擎無法爬取結(jié)果，不利于 SEO。

因此，CSR 適合那些不需要 SEO 或者用戶訪問頻率不高的強交互應用，例如：SaaS 系統(tǒng)、后臺管理系統(tǒng)、在線文檔等。同時，利用瀏覽器緩存特性，這些應用也可以避免再次下載資源從而提高性能表現(xiàn)。

服務端渲染

前面提到 SPA 的 SEO 問題和首屏加載速度問題，有什么好辦法可以解決它們呢？其實傳統(tǒng)的服務端渲染就行。但是這樣一來豈不是開歷史倒車，兜兜轉(zhuǎn)轉(zhuǎn)又回去了？

解決方案也不難，只需對傳統(tǒng)服務端渲染模式做一些改進：

當用戶請求一個 URL 時，先按照傳統(tǒng)模式在服務端渲染完整 HTML 頁面給瀏覽器，這樣用戶立刻可以獲得首屏內(nèi)容；與此同時，客戶端會加載 JS 代碼，使前面加載的靜態(tài)內(nèi)容重新變成可交互的 SPA，這樣后續(xù)的頁面切換就不再需要刷新和重新獲取頁面內(nèi)容了。

為了保證前端程序員能夠使用熟悉的方式編寫頁面，即“同構(gòu)開發(fā)”，服務端渲染時，Nuxt 實際上是在服務器上執(zhí)行 Vue，將我們編寫的組件渲染為 HTML 并返回客戶端?？蛻舳思せ顣r執(zhí)行的 JS 實際上也是 Vue，它會重新接管文檔，恢復數(shù)據(jù)和狀態(tài)，使靜態(tài)頁面變得可交互，這一過程稱為“注水(hydration)”。

可以看到，SSR 保留 CSR 優(yōu)點的同時，還給用戶提供了快速加載首屏的能力，這同時也解決了 SEO 問題。

但這種方式也并不完美，因為服務器和瀏覽器環(huán)境有差異，它們不能給開發(fā)者提供相同 API，例如，組件在服務端創(chuàng)建時就沒有 mounted 鉤子，因為根本沒有掛載這一步，這導致不少組件庫不能在服務端環(huán)境正常使用。

又比如，有時候我們的代碼只想在客戶端運行，如果不小心在服務端執(zhí)行了就會報錯。這些都給開發(fā)帶來了復雜度和約束性。同樣的，由于頁面渲染操作發(fā)生在服務端，所以服務器負載增加了，只是由于后續(xù) hydration 操作，這個負載增加量被大幅減少了。最后，大家還應該注意的是，SSR 還額外增加了 node.js / serverless 這樣的運行時需求，這實際上也是一筆費用。

綜上所述，SSR 方式非常靈活，幾乎可以適配大多數(shù)需求，尤其是一些基于內(nèi)容的網(wǎng)站：博客，電商，官網(wǎng)等等。

因此 Nuxt3 默認渲染模式就是 SSR。

靜態(tài)站點生成

大家可以看一下 Nuxt 項目中 packages.json 文件，里面提供了一個 generate 命令。這個命令的作用是將寫好的動態(tài)頁面基于數(shù)據(jù)生成為靜態(tài)網(wǎng)站，這一過程稱為靜態(tài)內(nèi)容生成 - Static Site Generate，即 SSG。

為什么要做靜態(tài)內(nèi)容生成哪？答案也很簡單，因為如果用戶每次訪問一個相同的頁面都要重新渲染一次相同的內(nèi)容，無疑是在浪費資源，比如一篇博客或者一個商品詳情頁，編輯完成之后它們通常不怎么變動，這就沒有必要每次重新渲染，如果提前渲染好一個靜態(tài)頁，將會獲得最小的服務器負載，最好的性能表現(xiàn)，同時也減少網(wǎng)站的安全風險。

同時，服務器需求也是最少的，我們僅需要靜態(tài)網(wǎng)站服務即可，這顯然可以大幅降低服務器成本。如果我們只是開發(fā)一個個人網(wǎng)站或博客，甚至可以通過 github page、vercel 等靜態(tài)服務零成本建站。

當然 SSG 也存在一些問題，比如網(wǎng)站內(nèi)容一旦變化，我們就需要重新生成整站，網(wǎng)站內(nèi)容比較少時這并沒有什么問題，如果內(nèi)容比較龐大，則每次重新生成的時間成本就太大了。因此也就有了增量內(nèi)容生成 - ISG，但是這個功能 Nuxt3 目前還在開發(fā)中。

所以，SSG 僅適合內(nèi)容創(chuàng)建之后不經(jīng)常變化的網(wǎng)站，例如：個人博客、網(wǎng)站、宣傳頁等。

混合渲染

之前的 Nuxt 版本中，一個應用只能使用一種渲染模式，要么客戶端渲染，要么服務端渲染，這種非黑即白的方式不靈活，一些情況下，應用的不同部分用不同的渲染方式更適合。比如電商應用首頁經(jīng)常變動，適合服務端渲染，商品詳情頁則希望靜態(tài)化；又比如 CMS 中 admin 部分不需要 SEO，則適合客戶端渲染，而所有內(nèi)容頁則僅需要生成一次。

Nuxt3 帶來一個新的渲染模式，稱為混合渲染 - hybrid rendering，顧名思義，這是一種根據(jù)不同路由規(guī)則使用不同方式渲染的模式。這種方式就可以用來解決前面提出的需求。

所以，如果大家的項目需求使用一種渲染模式不能滿足時，就可以考慮混合渲染模式。

邊緣渲染

過去，SSR 只能運行在 Node.js 環(huán)境，但是 Nuxt3 提供了跨平臺支持，能夠同時運行在 Node.js、Deno、Workers 等運行時環(huán)境。

這就給用戶帶來一種全新使用方式：邊緣渲染 - edge-side rendering，這種方式能夠在 CDN edge worker 環(huán)境下直接執(zhí)行渲染，這樣 Nuxt 應用能夠運行在離用戶更近的環(huán)境中，從而降低延遲和服務器花銷。

因此，如果大家需要深度優(yōu)化應用打開和交互速度，例如：實時游戲，交易系統(tǒng)，就可以嘗試邊緣渲染模式。

總結(jié)

最后我們總結(jié)一下渲染模式的一些差異：

• 客戶端渲染：開發(fā)速度快，節(jié)約服務器資源；首屏慢，SEO 不友好；
• 服務端渲染：首屏快，SEO 友好，適應性強；開發(fā)約束大，服務器費用高；
• 靜態(tài)站點生成：首屏極快，SEO 友好，服務器成本低；適應性弱，可維護性差；
• 混合渲染：按需渲染，適應性強，可維護性好；穩(wěn)定性、可用性不好；
• 邊緣渲染：性能好，服務器成本低；穩(wěn)定性、可用性不好。

到此這篇關(guān)于關(guān)于Nuxt的五種渲染模式的差異和使用場景全解析的文章就介紹到這了,更多相關(guān)Nuxt五種渲染模式解析內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論