為什麼現在又流行服務端渲染html？

01-14

貌似幾年之前從服務端生成html(如servlet)慢慢開始前後端分離，把一些渲染計算的步驟拋向前端來減輕服務端的壓力。但是為啥現在又開始流行在服務端渲染html了呢？如vue全家桶或者react全家桶，都是推薦通過服務端渲染來實現路由的。單純的是因為Virtual DOM的強大還是別的什麼原因？

不。是那些需要 SEO 的網站，突然都做成 SPA 了。

題主是不是沒搞清一些概念呢？

前端渲染和服務端渲染的「渲染」不是一個意思，頁面的渲染是且僅是在瀏覽器中進行的，就算 server rendering，伺服器給過來的也只是文本。所以不存在「減輕服務端壓力把渲染工作拋向前端」。

前後分離和服務端渲染也不是一條路線的啊。這個命題就好像說「前兩年大家都喜歡坐汽車，現在又流行吃素」一樣讓人摸不著頭腦。

前後分離對減輕伺服器（計算）壓力是有效果的，但這不是主要目的。一個請求伺服器返回一個頁面，和使用 AJAX 相比，PM 在乎的是用戶體驗和功能，程序員在乎的是結構清晰易維護好擴展，好像沒人關注伺服器計算壓力小了多少。（前後分離也不能阻止一個頁面發起n個 AJAX 請求，未必減少服務端壓力）

另外 React 和服務端渲染也不是一個層面的，並不是「先流行 React 然後發現還是需要服務端渲染又重新流行 SS」。如果你需要 SEO，在乎首屏載入體驗，無論用不用 React 都需要服務端渲染，否則無論用不用 React 都不必服務端渲染。

總而言之就是前後分離的流行和服務端渲染的流行是兩個層面的事。題主把一堆概念混在一起強行做對比，得出了一個似是而非的結論。

當然，也有一種可能，是一部分從框架入門的培訓型前端人員短期大量進入，佔據了輿論主流，然後這些人終於發現了框架之外的世界，比如服務端渲染，自然又要熱鬧一番，所以看起來好像服務端渲染又「流行」起來了吧。

如果你說的「流行」是指各種教程開始層出不窮的話。

說到底還是seo的問題。但最根本的原因還是搜索引擎的技術發展跟不上前端的腳步。

其實並不全是SEO的問題。

主要是現在的web應用，需求越來越多，單頁面應用打包出來的js大小會很龐大，幾個M的。
於是就有了按模塊載入，像require.js一樣，非同步請求。webpack盛行，就變成了代碼分割。
即便如此，主庫還是有可能超過1M的大小，資源受限的設備打開頁面還是很捉急。頁面載入之後，還需要通過AJAX從服務端獲取數據，再渲染。對於追求極致體驗的產品，是不能忽視的

所以才有服務端渲染，主要解決兩個痛點

1. SEO
2. 大型應用的首屏渲染

SPA很好的進行了前後端分離，前後端唯一通信就是通過API。減輕服務端壓力也只是順帶。

對於不需要SEO，且多人開發的應用，SPA應該是首選

渲染：指模板與數據裝配的過程。

（1）很久之前，頁面在服務端渲染。

（2）然後，查詢操作在服務端渲染，增刪改在客戶端渲染。這個也是現在絕大多數網站的做法。（甚至一些站點所有操作都是前後端分離，你看到的那個載入圖標就是在等待渲染。）

前端渲染：也就是前後端分離，瀏覽器分別拿到空的頁面和數據，然後用某種方式拼接到一起。

（3）再之後，就變成了spa。這裡注意，spa不僅僅把渲染放到了前端，路由也順便挪到了前端。（但不是所有站點都這麼改，只是一部分。）

前端路由：把所有頁面都寫進一個html中，瀏覽器攔截hash更改事件，然後對頁面元素進行調整。所以不會向伺服器發獲取頁面的請求。

題主所描述的，渲染放到前端，路由放到後端。也就是不帶前端路由的前後端分離（2）。

spa的問題一是seo，即僅僅是hash部分不同，蜘蛛會將其認為成一個頁面（？）。二是頁面的首次載入非常耗時。

SEO是一個不能打折扣的硬需求。很多技術人沒有理解SPA框架的應用場景，大家一起作了幾年，現在發現了。

JS框架「能」支持伺服器端渲染，不代表項目「應該」用這些框架去作伺服器端渲染，框架的作者當然能自圓其說，但工程的標準不是「能不能」，而是夠不夠簡單。

首先了解需求，再談實現，所謂pick right tool for the job。

瀏覽器段渲染是由瀏覽器解釋執行並渲染dom的，典型的代表便是SPA應用，這樣的問題就是瀏覽器呈現頁面時會需要等待js的執行完畢，如果js沒有執行完畢，那麼頁面便處於長期等待（姑且不考慮代碼分割和按需載入）

說起 SSR，其實早在 SPA ( Single Page Application ) 出現之前，網頁就是在服務端渲染的。伺服器接收到客戶端請求後，將數據和模板拼接成完整的頁面響應到客戶端。客戶端直接渲染，此時用戶希望瀏覽新的頁面，就必須重複這個過程，刷新頁面. 這種體驗在 Web 技術發展的當下是幾乎不能被接受的，於是越來越多的技術方案湧現，力求實現無頁面刷新或者局部刷新來達到優秀的交互體驗。但是 SEO 卻是致命的，所以一切看應用場景。

因為需要SEO呀，除了google，很多搜索引擎都不支持抓取js渲染的頁面。

另外ssr可以讓首屏載入速度更快，現在強調ssr，和之前的伺服器端渲染不是同一個層次。

這正如人生三境界：

看山是山，看水是水
看山不是山，看水不是水
看山是山，看水是水

這個是由於引入虛擬dom了吧，框架內部使用虛擬dom開發，服務端渲染html是提高效率。

因為中國的產品大都喜歡在首頁上加很多東西（為了轉化、KPI，你懂的），然後他們發現用前端渲染這麼多東西好慢影響到轉化，但是公司又沒時間（不願意）把一樣的邏輯再用後端渲染實現一遍，於是乎就出現了這麼一種看似解決問題的方案。

如果你有幸維護一下使用 ssr 技術的產品，就可以體會到這種技術的獨特魅力所在了：P

在實際業務中兩點隱藏的硬性需求一直被現在的技術控忽略，seo友好和用戶體驗友好，說人話就是，搜索引擎更簡單的收錄和減少白屏時間。

現在主流搜索引擎其實已經對簡單的客戶端js輸出的結果收錄。但更直接的方式還是依賴於伺服器直接響應的具體內容。

其次，在面對越來越挑剔的用戶群體的時候，最快的把主要內容給用戶成為產品不折不扣的剛需。

其實主體思想並沒有發生任何變化，只是技術控是不是被裡流行這個詞給綁架了自己的認知

我發現回答里好多人很搞笑，沒有弄明白這個渲染的意義，JSF還有個伺服器端渲染呢，那些說只有瀏覽器渲染的怎麼解釋這個概念，所以首先搞清楚什麼叫渲染。

我們在這裡的渲染是說將模板頁面變成真實的HTML頁面，而不是把HTML頁面變成呈現給用戶的GUI圖像。所以搞清楚這個概念再來討論這個問題。

下一個問題是什麼是應用，什麼是網站。

以前我們把C端的都叫應用，瀏覽器打開的都叫網站，我們來對比下有何不同？

應用本質是根據當前狀態來進行執行操作包括更改頁面，網站是不停的跳轉頁面，他不需要考慮前一個頁面的狀態，當然了HTTP本來就是無狀態的協議。

後來有了js，有了ajax，這時網站也可以根據頁面當前的狀態來變更頁面了。再後來SPA出來了，注意SPA是單頁應用，不是單頁網站。其實我們很早就接觸到這些了，比如在線的office 365，我們把這種東西叫web應用(有人習慣把H5包殼的手機APP叫web app，所以這裡叫web應用吧)。

什麼是web應用？就是用瀏覽器來呈現應用。

所以為了保證應用的開發效率，所以UI組件化的開發思想出現了，以前做過客戶端的可以回憶下，做客戶端應用第一步就是先繼承原始控制項，然後開發自己的控制項，這個自己開發的控制項其實就是好多控制項組合到一起，繼承原始控制項，不就是我們定義CSS和js來定製HTML元素么。

我們之所以需要使用前後端分離，是為了提高開發效率，讓分工更細化，讓工作更專業。同時也可以減少不必要的開發量，因為分離了APP和網頁就可以用同樣一套後端了。

說到前端渲染，其實是存在一些問題的，首先你有可能呈現給用戶的不是真實的頁面，可能會出現用戶誤點擊造成錯誤；再一個，如果頁面拉過來了，但是介面訪問出錯，顯示的頁面也是原始頁面，這也是不好的體驗；再有時候，後端為了偷懶會傳遞多餘的數據，這就很討厭了，如果數據傳到瀏覽器可能會暴露一些不必要的信息。

因此我們提倡後端渲染，都是用js渲染，其實沒有任何差別。所謂的降低壓力，幾乎沒有任何意義，搞個緩存就好了。

網站是需要SEO的，但是應用是不需要SEO的，網站以展示內容為主，而應用是以使用功能為主，這是完全不同的兩個概念，希望題主能明白。

既然我們要把最終能用的完全展示給用戶，那麼後端渲染是一次性展示的，前端渲染是多次展示的。後端渲染等於告訴用戶結果要麼是渲染失敗，要麼渲染成功；前端渲染就是0，0.3，0.6，0.8，1；對於網站來說還好，只要能看內容就好，可是我要是前端渲染，對SEO又不友好，那乾脆後端渲染吧，對於應用來說要麼能用，要麼不能用，你出來個即能用又不能用算個什麼鬼，所以還不如後端渲染。

通常來說是針對單頁面應用(spa)。

比如說，一個spa有兩個路由，List和Detail，前者需要訪問列表介面拿到列表數據，然後才能在頁面上繪製列表。後者吸引訪問詳情介面，才能在頁面上輸出詳細信息。

用戶從/list入口打開頁面，再路由到/detail/12時，spa應該向/api/detail/12發送請求獲取數據然後渲染沒有錯。

那麼，當用戶直接找伺服器要/detail/12這個路由作為入口時，伺服器應該怎麼辦？

1 先把單頁面應用發給用戶，再讓他發向api/detail/12發請求拿到數據並渲染

2 直接在這次返回中把需要的數據一併帶過去

明顯2更合理吧？

ssr只是比這個更進了一步。

不是是說近年來又大熱流行同構或者服務端渲染，其基本都是圍繞 SEO 和性能、用戶體驗的應用場景為出發點。

服務端渲染是當伺服器接收到用戶請求後，把需要展示的組件渲染成 HTML 字元串，然後把它返回給客戶端，接下來，客戶端會接手渲染控制權的一種渲染機制。

《也談React服務端渲染》

最近在使用next.js做React服務端渲染，遇到了一些問題，所以才有了這邊文章。希望對你有用

不光是因為SEO，伺服器端渲染html，載入頁面速度更快，體驗更好

需要SEO基本上是最主要的硬性條件，只能在伺服器端渲染。

服務端渲染和客戶端渲染從來就不是對立項。

服務端渲染並非時髦或過時的技術，20多年前就有服務端渲染，那時候全在服務端拼好html字元串再傳給瀏覽器。

單純的服務端渲染並不能滿足spa的需求。比如我想要從pathA無等待跳轉到pathB，除了用錨點外仍需要服務端渲染pathB。於是有了單頁面應用。路由控制權交給前端，前端一次性載入所需資源。等spa初始化後，後台退化成model層，提供介面數據。

這種載入方式有2個缺點，一是seo，另一個是初始化載入太慢。很像進入遊戲時載入地圖一樣。

於是有了isomorphic，首屏在伺服器端渲染，這樣大大減少了載入地圖的時間，等到所有資源載入完畢後，控制權交給瀏覽器端。

附錄：關於isomorphic我看到的最好的中文文章( IMVC（同構 MVC）的前端實踐 · Issue #14 · Lucifier129/Lucifier129.github.io)

Python web搞起的吧

根本原因是現在的爬蟲太落後了，不能完全模擬瀏覽器的行為