概念
服务端渲染（吐）
服务端在返回 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 的过程。 有关性能的消耗对比，可以参考这篇文章；
-
缓存方面，只能做到页面级的缓存。如果用户特定（user-specific），即对于不同用户需要渲染不同内容，缓存是不可用的。
是否有其他解决客户端渲染不足之处的方法？
答案肯定是有的：
-
处理 SEO 问题时，使用 prerender 、升级搜索引擎，以及其他。
-
白屏可以加 loading、Skeleton Screen 效果、以及其他。
总结
用户体验才是王道。
原文：https://jkchao.cn/article/5a11155fb520d115154c8fa1