服務器端渲染SSR

什麼是服務器端渲染

渲染：就是將數據和模版組裝成html

後端渲染（服務器端渲染）

多年前，Web是一羣由HTML和CSS構建的靜態頁面，沒有太多的交互性。每一個用戶行爲要求服務器來建立和提供一個完整的頁面。後端渲染HTML的狀況下，瀏覽器會直接接收到通過服務器計算以後的呈現給用戶的最終的HTML字符串，這裏的計算就是服務器通過解析存放在服務器端的模板文件來完成的，在這種狀況下，瀏覽器只進行了HTML的解析，以及經過操做系統提供的操縱顯示器顯示內容的系統調用在顯示器上把HTML所表明的圖像顯示給用戶。

        國企的網站所有是使用的後端渲染，也就是說，你點擊一下，他就會刷新一個，而後從後臺請求新的頁面數據。

好處：前端耗時少（前端只負責將html進行展現），利於SEO

壞處：網絡傳輸數據量大，佔用（部分、少部分）服務器運算資源，response 出的數據量會（稍）大點，模板改了前端的交互和樣式什麼的同樣得跟着聯動修改

 

前端渲染（客戶端渲染）

前端渲染的方式起源於JavaScript的興起，ajax的大熱更是讓前端渲染更加成熟，前端渲染真正意義上的實現了先後端分離，前端只專一於UI的開發，後端只專一於邏輯的開發，先後端交互只經過約定好的API來交互，後端提供json數據，前端循環json生成DOM插入到頁面中去。

好處：網絡傳輸數據量小（減小了服務器壓力）

壞處：前端耗時較多，不利於SEO

 

        其實先後端的渲染本質是同樣的，都是字符串的拼接，將數據渲染進一些固定格式的html代碼中造成最終的html展現在用戶頁面上。  由於字符串的拼接必然會損耗一些性能資源。 因此……

        若是在 服務器端渲染，那麼消耗的就是server端的性能。因此用戶量達到必定程度後，後端會考慮緩存部分數據，避免消耗過多資源重複渲染一些對及時性要求並不高的地方以節約資源。例如常見的排行榜，能夠將渲染後的模塊緩存起來，十分鐘更新一次。

        若是是在客戶端渲染，常見的手段，好比是直接生成DOM插入到html 中，或者是使用一些前端的模板引擎等。他們初次渲染的原理大可能是將原html中的數據標記（例如{{text}}）替換。通常來講只要不做死無腦用了document.write，瀏覽器端初次渲染的性能消耗都是能夠接受的。

瀏覽器端渲染的難點在於數據變動後，頁面響應式變動時如何節省資源？要知道DOM直接讀寫的速度是很慢的，並且不當心還會觸發重繪，在複雜的SPA下直接讀寫DOM帶來的影響會很明顯。拿React、Vue來舉例子，在數據變動後，他會幫你diff，沒有改變能夠複用的部分是不會從新渲染一遍的。

 

SEO
browser端渲染是對搜索引擎不太友好的，雖然SPA怎麼作SEO已經有過無數討論和實踐，可是browser端很大程度是不如server端渲染容易作SEO。

後端渲染html 叫 吐或者 噴，爬蟲能夠看到完整的呈現源碼
前端模板渲染html叫 填，爬蟲看不到完整的呈現源碼

維護

server端渲染不少時候先後端是一塊兒完成的。有的團隊是前端開發人員直接寫模板文件，可是也有的團隊是前端寫了靜態html文件，後端改成模板。後一種團隊在維護時是比較蛋疼的，改個css都要先後端在一塊兒搞定（個人上一家公司就是這麼作的）

 

如何選擇

關於在server端仍是在browser端渲染的選擇，更多的是要看業務場景。

 

例如一個注重SEO的新聞站點，非強交互的頁面，作成SPA意義並不大，仍是建議server端渲染。
像後臺管理頁面，或者是QQ空間這類強交互的網頁應用，能夠嘗試瀏覽器端渲染。後端開發人員也能更加專一於接口服務的提供，不用去考慮頁面的渲染問題，分工合做更加愉快。

在瀏覽器端渲染時，若是數據量並不大，也沒有什麼大的改變，那麼本身用原生的DOM API去操做綽綽有餘了，即便有時候有些操做會浪費一些性能資源，影響也不會太大，反而引入了框架和庫卻只用了一部分功能是一種浪費。可是若是作一個複雜的頁面應用，我仍是建議使用Vue這類庫/框架來幫你完成。一方面來講，他們會幫你把業務邏輯抽象，不讓你去關注渲染這些操做，能夠提高開發效率；另外一方面，恐怕大多數人本身實現渲染以及數據變動後的DOM變動未必會比庫/框架作得好。若是他能作的更好，必定要請他爲主流框架/庫去提PR或者issues來幫助庫/框架作的更好；或者激進點，他本身寫一個框架造福你們吧。

 

既然已經走在前面，就不要頻繁的日後看！

 

參考連接： 連接：https://www.zhihu.com/question/28725977/answer/116918471