概念
-
服务端渲染（吐）
服务端在返回 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 后，渲染到页面上。
利弊
image
同构
为了解决客户端渲染首屏慢与 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 效果、以及其他。
总结
用户体验才是王道。
网友评论