概念
-
服務端渲染（吐）
服務端在返回 html 之前，在特定的區域，符號里用數據填充，再給客戶端，客戶端只負責解析 HTML 。
也被稱為 fat-server, thin-client 模式
-
客戶端渲染（填）
html 僅僅作為靜態文件，客戶端端在請求時，服務端不做任何處理，直接以原文件的形式返回給客戶端客戶端，然后根據 html 上的 JavaScript，生成 DOM 插入 html。
也被稱為 fat-client, thin-server 模式
異同
- 渲染本質一樣，都是字符串拼接，將數據渲染進一些固定格式的html代碼中形成最終的html展示在用戶頁面上。
-
拼接字符串必然引起性能的消耗。
服務端渲染性能消耗在服務端，當用戶量比較多時，緩存部分數據以避免過多數據重復渲染。
客戶端渲染，如當下火熱的 spa 框架，Angular、React、Vue，在首次渲染時，大多是將原 html 中的數據標記（如 {{ text }} ）替換。客戶端渲染較難的一點是數據更新以后，頁面響應式更新時如何節省資源，直接 DOM 的讀寫，是很消耗性能的。 Vue 2.0 + 有 Vnode，進行 diff 后，渲染到頁面上。
利弊
同構
為了解決客戶端渲染首屏慢與 SEO 問題，同構開始出現。
同構：前后端共用 JS，首次渲染時使用 Node.js 來直出 HTML。一般來說同構渲染是介于前后端中的共有部分。
同構優點有很多，balabalabala……
簡單說下在使用 Vue SSR（nuxt）的一些坑：
服務端必須是 node.js 或者專門跑個 node.js 來支持；
document 對象找不到，由于前端使用的 window，在 node 環境不存在；
數據預獲取時，組件尚未實例化（無法使用 this ），于是在 created 生命鉤子調用 method 里的方法行不通，數據請求及格式化等操作都應該放置在專門的數據預取存儲容器（data store）或"狀態容器（state container）"中處理；
string-based 模板性能肯定要比 virtual-dom-based 模板的性能好。string-base 模板只要填數據即可，virtual-dom-based 模板需要經歷 Vue 模板語法 ---> Vnode ---> 拼接字符串 html 的過程。
有關性能的消耗對比，可以參考這篇文章 https://mp.weixin.qq.com/s?__biz=MzIwNjQwMzUwMQ%3D%3D&mid=2247485171&idx=1&sn=b1b0f2e2fe4a3f53a275c0764d4b21ca&chksm=97236431a054ed2755ca6f2e8e16100b843c8f55a73d1a1eb880230a67fce7914d10f88889ae ；緩存方面，只能做到頁面級的緩存。如果用戶特定（user-specific），即對于不同用戶需要渲染不同內容，緩存是不可用的。
是否有其他解決客戶端渲染不足之處的方法？
答案肯定是有的：
處理 SEO 問題時，使用 prerender 、升級搜索引擎，以及其他。
白屏可以加 loading、Skeleton Screen 效果、以及其他。
總結
用戶體驗才是王道。
