• 服務端渲染（吐）

  服務端在返回 html 之前煮嫌，在特定的區(qū)域，符號里用數(shù)據(jù)填充抱虐，再給客戶端昌阿，客戶端只負責解析 HTML 。

服務端渲染

也被稱為 fat-server, thin-client 模式



服務端渲染

• 客戶端渲染（填）

  html 僅僅作為靜態(tài)文件，客戶端端在請求時懦冰，服務端不做任何處理灶轰，直接以原文件的形式返回給客戶端客戶端，然后根據(jù) html 上的 JavaScript刷钢，生成 DOM 插入 html笋颤。

客戶端渲染

也被稱為 fat-client, thin-server 模式


客戶端渲染

異同

• 渲染本質一樣，都是字符串拼接闯捎，將數(shù)據(jù)渲染進一些固定格式的html代碼中形成最終的html展示在用戶頁面上椰弊。

• 拼接字符串必然引起性能的消耗。

  服務端渲染性能消耗在服務端瓤鼻，當用戶量比較多時秉版，緩存部分數(shù)據(jù)以避免過多數(shù)據(jù)重復渲染。 客戶端渲染茬祷，如當下火熱的 spa 框架清焕，Angular、React祭犯、Vue秸妥，在首次渲染時，大多是將原 html 中的數(shù)據(jù)標記（如 {{ text }} ）替換沃粗≈嗑澹客戶端渲染較難的一點是數(shù)據(jù)更新以后，頁面響應式更新時如何節(jié)省資源最盅，直接 DOM 的讀寫突雪，是很消耗性能的。 Vue 2.0 + 有 Vnode涡贱，進行 diff 后咏删，渲染到頁面上。

利弊

[圖片上傳失敗...(image-b97b92-1542164471424)]

同構

為了解決客戶端渲染首屏慢與 SEO 問題问词，同構開始出現(xiàn)督函。

同構：前后端共用 JS，首次渲染時使用 Node.js 來直出 HTML激挪。一般來說同構渲染是介于前后端中的共有部分辰狡。

[圖片上傳失敗...(image-825a-1542164471424)]

同構

同構優(yōu)點有很多，balabalabala……

簡單說下在使用 Vue SSR（nuxt）的一些坑：

• 服務端必須是 node.js 或者專門跑個 node.js 來支持灌灾；

• document 對象找不到搓译，由于前端使用的 window，在 node 環(huán)境不存在锋喜；

• 數(shù)據(jù)預獲取時些己，組件尚未實例化（無法使用 this ）豌鸡，于是在 created 生命鉤子調用 method 里的方法行不通，數(shù)據(jù)請求及格式化等操作都應該放置在專門的數(shù)據(jù)預取存儲容器（data store）或"狀態(tài)容器（state container）"中處理段标；

• string-based 模板性能肯定要比 virtual-dom-based 模板的性能好涯冠。string-base 模板只要填數(shù)據(jù)即可，virtual-dom-based 模板需要經歷 Vue 模板語法 ---> Vnode ---> 拼接字符串 html 的過程逼庞。 有關性能的消耗對比蛇更，可以參考這篇文章 mp.weixin.qq... ；

• 緩存方面赛糟，只能做到頁面級的緩存派任。如果用戶特定（user-specific），即對于不同用戶需要渲染不同內容璧南，緩存是不可用的掌逛。

是否有其他解決客戶端渲染不足之處的方法？

答案肯定是有的：

• 處理 SEO 問題時司倚，使用 prerender... 豆混、升級搜索引擎，以及其他动知。

• 白屏可以加 loading皿伺、Skeleton Screen 效果、以及其他盒粮。

總結

用戶體驗才是王道鸵鸥。

后端渲染（SSR、服務端渲染）

后端渲染HTML的情況下丹皱，瀏覽器會直接接收到經過服務器計算之后的呈現(xiàn)給用戶的最終的HTML字符串脂男，這里的計算就是服務器經過解析存放在服務器端的模板文件來完成的，在這種情況下种呐，瀏覽器只進行了HTML的解析，以及通過操作系統(tǒng)提供的操縱顯示器顯示內容的系統(tǒng)調用在顯示器上把HTML所代表的圖像顯示給用戶弃甥。

前端渲染（SPA爽室、單頁面應用）

前端渲染就是指瀏覽器會從后端得到一些信息，這些信息或許是適用于題主所說的angularjs的模板文件淆攻，亦或是JSON等各種數(shù)據(jù)交換格式所包裝的數(shù)據(jù)阔墩，甚至是直接的合法的HTML字符串。這些形式都不重要瓶珊，重要的是啸箫，將這些信息組織排列形成最終可讀的HTML字符串是由瀏覽器來完成的，在形成了HTML字符串之后伞芹，再進行顯示忘苛。

題主所提到的幾個技術蝉娜，我認為模板這個詞語并不能用來區(qū)分這些技術的本質，模板只是一種提供給程序來解析的一種語法扎唾，換句話說召川，模板是用于從數(shù)據(jù)（變量）到實際的視覺表現(xiàn)（HTML代碼）這項工作的一種實現(xiàn)手段，而這種手段不論在前端還是后端都有應用胸遇。

以下為本人自己的想法：在性能上荧呐，我認為后端渲染最終會被前端渲染，因為后端渲染將所有的HTML生成集中在了一個服務器上纸镊，而前端渲染將這部分工作分發(fā)到各個終端上倍阐。另外，對于開發(fā)而言逗威，這樣能夠避免后端開發(fā)人員過多的編寫HTML代碼峰搪，后端開發(fā)人員只需和前端開發(fā)事先商定好數(shù)據(jù)格式，后端就只需將數(shù)據(jù)生成庵楷，用數(shù)據(jù)交換格式包裝罢艾，再發(fā)送出去就可以了，這樣能夠使開發(fā)人員之間的分工更加明確尽纽。

再附上稀土掘金上的一段理解：

SEO

很重要咐蚯，所以要普及。

SEO： 搜索引擎優(yōu)化（Search Engine Optimization）弄贿，它是指通過站內優(yōu)化春锋，如：網站結構調整、網站內容建設差凹、網站代碼優(yōu)化以及站外優(yōu)化等方法期奔，來進行搜索引擎優(yōu)化。

簡單說： 通過各種技術（手段）來確保危尿，你的Web內容被搜素引擎最大化收錄呐萌，最大化提高權重，帶來更多流量谊娇。

常見關鍵詞：白帽肺孤、黑帽、SEM济欢、Backlink赠堵、Linkbait、PageRank法褥、Keyword Stuffing...茫叭，總之都圍繞著一個核心：SEO；流量是變現(xiàn)的快車道半等，SEO是低成本獲取流量的最佳方法揍愁。

SPA

SPA：單頁Web應用（single page web application呐萨，SPA），就是只有一張Web頁面的應用吗垮，是加載單個HTML 頁面并在用戶與應用程序交互時動態(tài)更新該頁面的Web應用程序垛吗。

簡單說： Web不再是一張張頁面，而是一個整體的應用烁登，一個由路由系統(tǒng)怯屉、數(shù)據(jù)系統(tǒng)、頁面（組件）系統(tǒng)...組成的應用程序饵沧，其中路由系統(tǒng)是非必須的锨络。

大部分的Vue項目，本質是SPA應用狼牺，Angular.js羡儿、Angular、Vue是钥、React...還有最早的"Pjax"均如此掠归。

SPA時代，主要是在Web端使用了history或hash（主要是為了低版本瀏覽器的兼容）API悄泥，在首次請求經服務端路由輸出整個應用程序后虏冻，接下來的路由都由前端掌控了，前端通過路由作為中心樞紐控制一系列頁面（組件）的渲染加載和數(shù)據(jù)交互弹囚。

而上面所述的各類框架則是將以：路由厨相、數(shù)據(jù)、視圖為基本結構進行的規(guī)范化的封裝鸥鹉。

最早的SPA應用蛮穿，由Gmail、Google Docs毁渗、Twitter等大廠產品實踐布道践磅，廣泛用于對SEO要求不高的場景中。

SSR

SSR： 服務端渲染（Server Side Render）灸异，即：網頁是通過服務端渲染生成后輸出給客戶端音诈。

在SPA之前的時代，我們的Web架構大都是SSR绎狭，如：Wordpress（PHP）、JSP技術褥傍、JavaWeb...或者DEDECMS儡嘶、Discuz!等這些程序都是傳統(tǒng)典型的SSR架構，
即：服務端取出數(shù)據(jù)和模板組合生成html輸出給前端恍风，前端發(fā)生請求時蹦狂，重新向服務端請求html資源誓篱，路由也由服務端來控制。

其次凯楔，有個概念叫預渲染（Prerendering）窜骄。

如果你只是用服務端渲染來改善一個少數(shù)的營銷頁面（如 首頁，關于摆屯，聯(lián)系 等等）的SEO邻遏，那你可以用預渲染來實現(xiàn)。
預渲染不像服務器渲染那樣即時編譯HTML虐骑，它只在構建時為了特定的路由生成特定的幾個靜態(tài)頁面准验，等于我們可以通過webpack插件將一些特定頁面組件build時就編譯為html文件，直接以靜態(tài)資源的形式輸出給搜索引擎廷没。

但實際的商業(yè)應用中糊饱，大部分時候我們需要的是即時渲染，這也是我們今天討論的主題颠黎。

Why

為什么要SSR另锋，為了體驗，還有SEO狭归。

首先夭坪，用戶可能在網絡比較慢的情況下從遠處訪問網站 - 或者通過比較差的帶寬。 這些情況下唉铜，盡量減少頁面請求數(shù)量台舱，來保證用戶盡快看到基本的內容。
可以用Webpack的代碼拆分避免強制用戶下載整個單頁面應用潭流，但是竞惋，這樣也遠沒有下載個單獨的預先渲染過的HTML文件性能高。

對于世界上的一些地區(qū)人灰嫉，可能只能用1998年產的電腦訪問互聯(lián)網的方式使用計算機拆宛。
而Vue只能運行在IE9以上的瀏覽器，你可能也想為那些老式瀏覽器提供基礎內容 - 或者是在命令行中使用 Lynx的時髦的黑客讼撒。

在大部分的商業(yè)應用中浑厚，我們有SEO的需求，我們需要搜索引擎更多地抓取到我們的內容根盒，更詳細地認識到我們的網頁結構钳幅，而不是僅對首頁或特定靜態(tài)頁進行索引，這是SSR最重要的意義炎滞。

簡單說就是敢艰，我們需要搜素引擎看到這樣的代碼：

這里寫圖片描述

而不是這樣的代碼：

這里寫圖片描述

且，我們還需要在SSR的基礎上實現(xiàn)SPA册赛，即：首屏渲染钠导。

基本流程是：

在瀏覽器第一次訪問某個URI資源的時候（首屏）震嫉，Web服務器根據(jù)路由拿到對應數(shù)據(jù)渲染并輸出，且輸出的數(shù)據(jù)中包含兩部分：

• 路由頁對應的頁面及已渲染好的數(shù)據(jù)
• 完整的SPA程序代碼

在客戶端首屏渲染完成之后牡属，此時我們看到的其實已經是一個和之前的SPA相差無幾的應用程序了票堵，接下來我們進行的任何操作都只是客戶端的應用進行交互，
頁面/組件由Web端渲染逮栅，路由也由瀏覽器控制悴势，用戶只需要和當前瀏覽器內的應用打交道就可以了。

之前在各大SPA框架還未正式官方支持SSR時证芭，有一些第三方的解決方案瞳浦，如：prerender.io，
它們做的事情就是建立HTTP一個中間層废士，在判斷到訪問來源是蜘蛛時叫潦，輸出已緩存好的html數(shù)據(jù)，此數(shù)據(jù)若不存在官硝，則調用第三方服務對html進行緩存矗蕊，往復進行。

另一方法是自行構建蜘蛛渲染邏輯氢架，當識別UA為搜索引擎時傻咖，拿服務端已準備好的模板和數(shù)據(jù)進行渲染輸出html數(shù)據(jù)，反之岖研，則輸出SPA應用代碼卿操；

我當時也考慮過此方法，但有很多弊端孙援，如：

需要針對蜘蛛編寫一套獨立的渲染模板害淤，因為大部分情況下SPA的代碼是沒法直接在服務端使用的
搜索引擎若檢測到蜘蛛抓取數(shù)據(jù)和真實訪問數(shù)據(jù)不一致，會做降權懲罰拓售，也就意味著渲染模板還必須和SPA預期輸出一模一樣
所以窥摄，最好的方法是SPA能和服務端使用同一套模板，且使用同一個服務端邏輯分支础淤，再簡單說：最好Vue崭放、Ng2...能直接在服務端跑起來。

作者：牧碼人小鵬
鏈接：http://www.reibang.com/p/14c3c4f61d90
來源：簡書
簡書著作權歸作者所有鸽凶，任何形式的轉載都請聯(lián)系作者獲得授權并注明出處币砂。