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