快捷導(dǎo)航

關(guān)于Nuxt的五種渲染模式的差異和使用場景全解析

更新時(shí)間：2023年04月20日 08:40:24 作者：SYBH.

這篇文章主要介紹了關(guān)于Nuxt的五種渲染模式的差異和使用場景全解析,在過去傳統(tǒng)開發(fā)中，頁面渲染任務(wù)是由服務(wù)端完成的,那么Nuxt是如何渲染的呢,需要的朋友可以參考下

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

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

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

客戶端渲染

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

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

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

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

服務(wù)端渲染

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

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

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

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

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

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

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

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

因此 Nuxt3 默認(rèn)渲染模式就是 SSR。

靜態(tài)站點(diǎn)生成

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

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

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

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

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

混合渲染

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

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