浅析前端渲染与服务端渲染

背景知识:

  「后端渲染」指传统的 ASP、Java 或 PHP 的渲染机制;

  「前端渲染」指使用 JS 来渲染页面大部分内容,代表是现在流行的 SPA 单页面应用;

  「同构渲染」指前后端共用 JS,首次渲染时使用 Node.js 来直出 HTML。一般来说同构渲染是介于前后端中的共有部分。

  客户端渲染路线:1. 请求一个html -> 2. 服务端返回一个html -> 3. 浏览器下载html里面的js/css文件 -> 4. 等待js文件下载完成 -> 5. 等待js加载并初始化完成 -> 6. js代码终于可以运行,由js代码向后端请求数据( ajax/fetch ) -> 7. 等待后端数据返回 -> 8. react-dom( 客户端 )从无到完整地,把数据渲染为响应页面

  服务端渲染路线:2. 请求一个html -> 2. 服务端请求数据( 内网请求快 ) -> 3. 服务器初始渲染(服务端性能好,较快) -> 4. 服务端返回已经有正确内容的页面 -> 5. 客户端请求js/css文件 -> 6. 等待js文件下载完成 -> 7. 等待js加载并初始化完成 -> 8. react-dom( 客户端 )把剩下一部分渲染完成( 内容小,渲染快 )

  说明:对同一个组件,服务端渲染“可视的”一部分( render/componentWillMount部分代码  ),为确保组件有完善的生命周期及事件处理,客户端需要再次渲染。即:服务端渲染,实际上也是需要客户端进行 再次地、但开销很小的二次渲染。

前端渲染的优势

  • 局部刷新。无需每次都进行完整页面请求
  • 懒加载。如在页面初始时只加载可视区域内的数据,滚动后rp加载其它数据,可以通过 react-lazyload 实现
  • 富交互。使用 JS 实现各种酷炫效果
  • 节约服务器成本。省电省钱,JS 支持 CDN 部署,且部署极其简单,只需要服务器支持静态文件即可
  • 天生的关注分离设计。服务器来访问数据库提供接口,JS 只关注数据获取和展现
  • JS 一次学习,到处使用。可以用来开发 Web、Serve、Mobile、Desktop 类型的应用

后端渲染的优势

  • 服务端渲染不需要先下载一堆 js 和 css 后才能看到页面(首屏性能)
  • SEO
  • 服务端渲染不用关心浏览器兼容性问题(随意浏览器发展,这个优点逐渐消失)
  • 对于电量不给力的手机或平板,减少在客户端的电量消耗很重要

以上服务端优势其实只有首屏性能和 SEO 两点比较突出。但现在这两点也慢慢变得微不足道了。React 这类支持同构的框架已经能解决这个问题,尤其是 Next.js 让同构开发变得非常容易。还有静态站点的渲染,但这类应用本身复杂度低,很多前端框架已经能完全囊括。

耗时对比:

  时间耗时比较:

    1. 数据请求:由服务端请求数据而不是客户端请求数据,这是“快”的一个主要原因。服务端在内网进行请求,数据响应速度快。客户端在不同网络环境进行数据请求,且外网http请求开销大,导致时间差(主要原因)。

    2. 步骤:服务端是先请求数据然后渲染“可视”部分,而客户端是等待js代码下载、加载完成再请求数据、渲染。即:服务端渲染不用等待js代码下载完成再请求数据,并会返回一个已经有内容的页面。

    3. 渲染性能:服务端性能比客户端高,渲染速度快( 猜测,该项数据不详 )。

    4. 渲染内容:服务端渲染会把”可视“部分先渲染,然后交给客户端再作部分渲染。而客户端渲染,则是从无到有,需要经历完整的渲染步骤。

山外有山,看看别人这么说:

知乎大神这么说,

作者:徐飞 链接:https://www.zhihu.com/question/28207685/answer/39893889 来源:知乎

对于前后端分离,认识上有个误区,那就是很多人自称:我们老早就分离了,全AJAX,使用Angular或者什么什么就可以了。

这个说法是不合适的,打个比方,别人问的是“如何解决家禽把蛋生在水草边的问题?”,但实际上人家养的是鸭子,答题的却是养鸡的,所以回答“不让去水边就行了”,这显然不在点子上。

这两年业界说的前后端分离,是限于偏展示类的系统(用A代替),而不是应用、管控类Web项目(用B代替),在B类项目里,前后端是天然分离的,对此,除了少部分后端开发人员,基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目,在B类项目里,前后端分离是共识,不需要讨论。

那么,剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢,在于模板的与数据结合的位置,以及,模板的控制权在谁手里。经过这两年的讨论,基本上我们可以达成的共识就是:模板应当由前端人员去控制,主要原因有两方面:

- 性能优化(尤其是外部资源的管理与发布,请求合并等等) - 协作的顺畅性(已形成模板的界面片段的返工等问题)

那么,模板到底应该在什么地方跟数据结合?

这个问题就比较折腾了,有部分人尝试像B类项目那样,使用js模板,然后在浏览器端执行,这是存在一些问题的,比如说seo不友好,首屏性能不够,尤其对于首页DOM量很大的电商类网站,差距很明显。

所以我们还是得把主要的模板放在服务端来执行。在这个过程中,阿里作了一些尝试,那就是引入Node层,在这一层把模板与数据进行合成,然后浏览器拿到的就是生成好的HTML了,但也不是所有HTML都是这么生成好的,还是会有一些内容等到了浏览器之后,再用js去加载和生成。

所以这一定会是一个混合方案,同一个系统中存在两种模板,一种在服务端执行,一种在浏览器中执行,互为补充。

至于说这个方案中,是否中间层一定要是node,我觉得无所谓,只要是能正常做web项目的东西都可以,这个还是要看所在企业的技术积累方向,当然node做这块是有一些优势的,比如对前端人员的语言友好性,前后端模板的通用性等等,但这些都是细节,重点还是整体方案和流程。

这时候回头看你问题中的这句:

> 前后端分离的意思是,前后端只通过 JSON 来交流,组件化、工程化不需要依赖后端去实现。

我相信你这里对前后端的限定是以浏览器为准的,但事实上,A类项目中,前后端的分界一定要延伸到服务器端的模板层,也就是在这一层里,把各种来源的数据整合到模板中,这个数据未必是JSON格式的,会存在有JSON,XML,特定的二进制等等。

组件化这个话题就更复杂了,在刚才组织形式中,很难说出究竟什么才是组件。是某个商品的模板吗?是数据吗?是数据和模板的结合体吗?没法回答。在此,我说一句自己的看法:像电商这种项目的前端部分,基本不存在组件的概念,甚至不存在组件化的价值,因为这里面可复用的东西太少了,也不易提取,大多数东西都是不带逻辑的界面模板。

最近因为ReactJS的流行,带来了一个Isomorphic的概念,这是一种很有意义的探索,但是否能解决这类问题,尚不得而知,根据我的理解,它对B类项目是较好的补充方案,但对A类项目暂时还缺乏可用性,因为A类项目中,运行期的DOM变更并不多,多是整片的改变,用这个方案去解决的话,有些牛刀杀鸡的感觉。

我的理解:

  这里我补充一下,项目可以分为三类,a类是电商前台,b类就是电商后台,c类就是移动端项目,介于两者之间,有自己的特点。

  对于交互性不强的页面,比如新闻,信息展示比较多的,服务器渲染优先,交互多的,比如QQ空间,建议浏览器渲染优先。所以不能为了前后端分离而前后端分离,要根据具体的业务场景来具体问题具体分析。

  在浏览器端渲染时,如果数据量并不大,也没有什么大的改变,那么自己用原生的DOM API去操作绰绰有余了,即使有时候有些操作会浪费一些性能资源,影响也不会太大,反而引入了框架和库却只用了一部分功能是一种浪费。但是如果做一个复杂的页面应用,我还是建议使用Vue这类库/框架来完成。一方面来说,他们会把业务逻辑抽象,不用去关注渲染这些操作,可以提升开发效率;另一方面,恐怕大多数人自己实现渲染以及数据变更后的DOM变更未必会比库/框架做得好。

阅读上面内容发现,淘宝的解决方案我们是可以借鉴的,一句话就是利用node中间层。node拿需要的数据和html渲染好了,再送到浏览器,从而减少初始化页面时候带来的时间。

  但是这种方案也并不完美,   一方面不是所有东西都可以通过模板渲染,也就存在一些在node渲染,一些通过js插入!跟传统方式一样,增加维护成本,降低体验 一方面,增加了node层也就增加了页面挂掉的风险,因为node服务也不能保证百分一百稳定。所以使用node层就又得考虑node服务不了用的兜底方案,比如读缓存服务器等 另一方面使用node层无疑是减轻了服务端的工作量,他们只操作提供数据提供接口!增加了前端的工作量,需要多维护node层。

解决方案:

  一、前端和后端先行讨论对接,确定哪些是前端渲染哪些是后端渲染,确定字段,接口格式。

  前端渲染的部分,又分为2种,

  1、前端模板,vue、react去绑数据,实现方式为virtual Dom。

  2、jq html append 接收json数据拼接后挂载到页面上,实现方式为拼字符串。

  二、利用node中间层,这一块需要学习node方面知识,目前还不熟悉,下一步准备尝试一下。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏DeveWork

Google Fonts导致WordPress 速度问题的三个解决方案

本来实在是不想写这个的,因为相关方法在圈子里面已经烂大街了。但无奈,一些客户将近期的Google Fonts导致 WordPress 打开速度慢的现象归咎于我的...

33290
来自专栏SEO

SEO新手必知50个SEO术语词解释

472120
来自专栏腾讯移动品质中心TMQ的专栏

TMQ第五期沙龙回顾|Selenium自动化测试框架

HTTP接口测试平台构建和运行 活动时间:2016年7月28日 QQ群视频交流 活动介绍: TMQ QQ群沙龙第四期分享 本次分享的主题是H...

245100
来自专栏刘勇刚的专栏

鸟瞰前端 , 再论性能优化

从事前端有 6 年+的时间了,我现在将自己这些年的一个心得体会来个系统性的梳理写成一篇关于性能优化的主题文章,希望对大家有点帮助,也欢迎大家提出各种意见和建议。

54810
来自专栏iOSDevLog

Unity 3D 开发《王者荣耀》:英雄攻击创建按钮源码:https://github.com/iOSDevLog/ArenaOfValor

53760
来自专栏移动开发之家

移动端跨平台开发的深度解析

 跨平台一直是老生常谈的话题,cordova、ionic、react-native、weex、kotlin-native、flutter等跨平台框架的百花齐放,...

14740
来自专栏腾讯移动品质中心TMQ的专栏

腾讯TMQ在线沙龙回顾|Appium:轻松玩转混合自动化测试

活动介绍 TMQ在线沙龙第三十九期分享活动圆满结束啦! 本次分享的主题:Appium-轻松玩转混合自动化测试。 共有184位测试小伙伴报名参加活动。 想知道活动...

33480
来自专栏极客猴

分享一个爬取网站的小技巧

有时候,我们很想爬取一个网站的数据。如果 PC 端的网页的反爬机制太强,我们可以换个思路。现在很多网站为了满足手机浏览器能正常访问的需求,都会推出手机版的网页。...

80220
来自专栏大前端开发

5个最优秀的微信小程序UI组件库

开发微信小程序的过程中,选择一款好用的组件库,可以达到事半功倍的效果。自从微信小程序面世以来,不断有一些开源组件库出来,下面5款就是排名比较靠前,用户使用量与关...

3.5K50
来自专栏花叔的专栏

惊喜,热心网友为Nodes小程序写的超详细使用指南

曾斌是一个在校学生,也是一名Nodes的爱好者,他为Nodes撰写了非常详细的使用指南,并且也很用心的制作了演示视频,以下内容已得到曾斌同学的授权。 Node...

41860

扫码关注云+社区

领取腾讯云代金券