This website requires JavaScript.

服务端渲染 vs 客户端渲染

2017.11.19 13:23字数 1799阅读 3413喜欢 22评论 14

概念

  • 服务端渲染(吐)

    服务端在返回 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=MzIwNjQ...

  • 缓存方面,只能做到页面级的缓存。如果用户特定(user-specific),即对于不同用户需要渲染不同内容,缓存是不可用的。

是否有其他解决客户端渲染不足之处的方法?

答案肯定是有的:

  • 处理 SEO 问题时,使用 prerender 、升级搜索引擎,以及其他。

  • 白屏可以加 loading、Skeleton Screen 效果、以及其他。

总结

用户体验才是王道。