概念
-
服务端渲染（吐）
服务端在返回 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 效果、以及其他。
总结
用户体验才是王道。
