概念


服务端渲染


服务端在返回 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 ×××(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 效果、以及其他。


总结


用户体验才是真道理。