本文首發頭條號【程式猿最幽默】，文中配圖來自網路，如有侵權請聯絡作者刪除。

之前從服務端生成html（如servlet、jsp、asp。net 、php）慢慢開始前後端分離，把一些渲染計算的步驟拋向前端來減輕服務端的壓力，但是現在很多前端又開始使用一些服務端渲染技術，這是什麼原因？

前後端分離的前生今世：

首先在“一站式”開發的年代，也叫“全棧開發”！硬體還不夠發達，當時的主流作業系統還是Win Xp，瀏覽器也僅僅是IE、火狐、Safari； 前端的任務量還不足以大到需要一個職位去專門做這件事； 絕大多數的公司只需要招聘幾名“全棧工程師”就可以搞定業務；

但是隨著硬體的不斷完善、以及移動端的全面爆發；所謂的“前端” 業務量也不停地增加，透過前後端分離，增加“前端”崗位來專門處理前端已經刻不容緩；這時候傳統的 Web 開發慢慢變成“web 前端”、“h5 開發”、“小程式開發” 等； 技術、業務也完全被獨立開；

渲染模式

服務端渲染（SSR）：DOM樹在服務端生成，然後返回給前端。

客戶端渲染（CSR）：前端去後端取資料在客戶端生成DOM樹。

2。1 客戶端渲染與服務端渲染的優缺點：

客戶端渲染（CSR）

服務端渲染（SSR）

優點

1、前後端分離，開發效率高。

2、使用者體驗更好，我們將網站做成SPA（單頁面應用）或者部分內容做成SPA，當用戶點選時，不會形成頻繁的跳轉。

1、儘量不佔用前端的資源，前端這塊耗時少，速度快。

2、有利於SEO最佳化，因為在後端有完整的html頁面，所以爬蟲更容易爬取資訊。

缺點

1、前端響應速度慢，特別是首屏，這樣使用者是受不了的。

2、白屏：在ajax得到響應之前，頁面中之後Loading。

3、不利於SEO最佳化，因為爬蟲不認識SPA，所以它只是記錄了一個頁面。

1、不利於前後端分離

，開發的效率降低了。

2、對html的解析，對前端來說加快了速度，但是加大了伺服器的壓力。

2。2 客戶端渲染與服務端渲染的區別：

客戶端渲染（CSR）

服務端渲染（SSR）

本質區別（html的完整拼接）

在客戶端生成DOM樹

在服務端生成DOM樹

響應速度

響應速度慢

響應速度快

SEO最佳化

不利於SEO最佳化

多個頁面，更有利於爬蟲爬取資訊，有利於SEO最佳化

開發效率

採用前後端分離的方式開發，效率更高，大部分業務採取的渲染方式

服務端渲染邏輯分離得不好，不利於前後端分離，開發效率低

服務端渲染的一些主流框架

3。1 Next。js 伺服器端渲染

目前最快（開發快 + 部署快 + 訪問快）的技術應該是 Next。js 以及他們家的 Vercel 部署平臺。頁面展現部分透過使用 React + TypeScript 技術開發一套程式即可以用於伺服器端渲染（SSR）又可以用於客戶端渲染（CSR），然後直接 push 到 github 的 main 就可以實現全球部署；

微服務 workers 以及資料互動則放在 serverless functions 中實現，並且將其分發部署到全球各個資料中心，再掛上 load balancer 進一步減少訪問延遲，以及更好地應對各種網路攻擊。這也是我理解的所謂的 edge-computing。

Next。js 渲染主要包括兩種方式：編譯時生成靜態 html 頁面和每次訪問時生成靜態 html 頁面。

編譯時生成靜態 html 頁面的 api 有幾個，其中最重要的是需要實現 getStaticProps 。需要注意的是此函式會在伺服器端被執行，返回的 { props } 資料會被傳遞到 React component 生成靜態頁面。

Serverless Functions 處理微服務workers 以及資料互動

Serverless functions 就是一個簡短的程式碼片段，或者一個後端的非同步 function 執行之後返回資料。大概長這樣：

透過 http 請求訪問這個 endpoint 就能執行裡面的邏輯，然後返回相應的資料。好處就是開發者不需要自行再構建伺服器來處理這些 endpoints。而且因為這是一些普通的函式，可以被分發到全球各個資料中心，形成 edge-computing 從而大大降低延遲。

那有人會問了，如果沒有伺服器 Cron Jobs 怎麼辦？

一個簡單的辦法就是利用第三方平臺定時訪問你的 corn endpoint。例如可以使用 GitHub Actions提供的這種功能。

在 。github/workflows/cron。yaml 中定義一個重複請求，每 15min 請求一次。

3。2 NuxtJS 渲染

Nuxt框架介紹：

1．Nuxt。js 是一個基於 Vue。js 的第三方開源服務端渲染應用框架

2．它可以幫我們輕鬆地實現同構應用

3．透過對客戶端/服務端基礎架構的抽象組織，Nuxt。js 主要關注的是應用的 UI渲染

4．我們的目標是建立一個靈活的應用框架，你可以基於它初始化新專案的基礎結構程式碼，或者在已有 Node。js 專案中使用 Nuxt。js

5．Nuxt。js 預設了利用 Vue。js 開發服務端渲染的應用所需要的各種配置，類似於腳手架生成了專案的基本框架

6．提供了一種命令叫： nuxt generate ，為基於 Vue。js 的應用提供生成對應的靜態站 點的功能，是向開發整合各種微服務（Microservices）的 Web 應用邁開的新一 步

7．作為框架，Nuxt。js 為 客戶端/服務端 這種典型的應用架構模式提供了許多有用的特性，例如非同步資料 載入、中介軟體支援、佈局支援等非常實用的功能

NuxtJS 渲染流程

下圖闡述了 Nuxt。js 應用一個完整的伺服器請求到渲染（或使用者透過

切換路由渲染頁面）的流程：

SEO

SEO，又叫Search Engine Optimization，可以理解為網頁要為搜尋引擎做兩件事，一是能讓搜尋引擎讀得到，二是讓搜尋引擎讀得懂。

首先Single-page application就在讀得到方面就天然劣勢，很多搜尋引擎，比如Facebot，Twitterbot，會直接解析服務端發過來的html，而Single-page application發往瀏覽器的是一個很輕量的html，以及大體量的javascript，搜尋引擎只能讀取這很有限的html，沒法讀取其他動態生成的URL，就很難爬到其他頁面。

既然爬不到，那能不能直接告訴搜尋引擎我有哪些URL呢？當然可以，如果你是網站的開發者，可以在搜尋引擎的console上傳sitemap（站點地圖），直接透過一定的格式告訴搜尋引擎，我這個Single-page application上面有哪些URL，不過無法讀取動態生成的問題仍然存在。

考慮到很多站點需要做SEO 最佳化，以及對效能的追求，選擇SSR方式會更有優勢。

在這個前後端分離的時代，如果你的站點還需要做SEO，讓搜尋引擎更容易認識，選擇SSR也就成了必然。

如果覺得本文對你有益，右上角記得【關注】，歡迎大家在評論區和諧討論~

TAG: 渲染服務端JShtml頁面