阅读 88

ssr首屏渲染你懂了么?

被迫营业—人间不值得,时隔两天我又来了,主要是我太爱东搞搞西搞搞啦,太爱学习也是一种负担啊,(被迫营业),这么冷的天还要努力学习看东西(人间不值得),这两天真的是冷啊。冷的冻掉了鼻子,不知道是鼻子太大还是天气太冷总有一种传了多少的裤子还是没穿一样,走在路上心里恐慌得不行,生怕哪个草丛跳出来三个壮汉一个姓德名马一个姓德名邦 一个姓德名...不对不对。蛮王不姓德。回来讲正事,一直对首屏渲染得实施方案有些好奇,因为开发成本太高所以也没有实战过一下。今天就整理一下最近对ssr的理解吧,不喜勿喷纯做个人记录。

  1. 服务端渲染定义

    讲这个之前必不可少需要讲一下页面的渲染流程

    1. 浏览器通过请求得到一个HTML文本
    2. 渲染进程解析HTML文本,构建DOM树
    3. 解析HTML的同时,如果遇到内联样式或者样式脚本,则下载并构建样式规则(stytle rules),若遇到JavaScript脚本,则会下载执行脚本
    4. DOM树和样式规则构建完成之后,渲染进程将两者合并成渲染树(render tree)
    5. 渲染进程开始对渲染树进行布局,生成布局树(layout tree)
    6. 渲染进程对布局树进行绘制,生成绘制记录
    7. 渲染进程的对布局树进行分层,分别栅格化每一层,并得到合成帧
    8. 渲染进程将合成帧信息发送给GPU进程显示到页面中

    从图中我们可以发现,浏览器从接收到HTML到渲染成页面经历很多步骤。当前流行的前端框架都是使用了javascript进行页面渲染的也就是说在执行 JavaScript 脚本的时候,HTML页面已经开始解析并且构建DOM树了,JavaScript 脚本只是动态的改变 DOM 树的结构,使得页面成为希望成为的样子,这种渲染方式叫动态渲染,也可以叫客户端渲染。

    服务端渲染:顾名思义,服务端渲染就是在浏览器请求页面URL的时候,服务端将我们需要的HTML文本组装好,并返回给浏览器,这个HTML文本被浏览器解析之后,不需要经过 JavaScript 脚本的执行,即可直接构建出希望的 DOM 树并展示到页面中。这个服务端组装HTML的过程,叫做服务端渲染。以我的话来讲就是后端服务器返回html的字符串然后直接喂给浏览器,其实就是一个静态页面的感觉,这样浏览器干的工作是真滴少啊,这样浏览器那反应肯定哇哇快


    虽然很长的文字但要耐心读完收益匪浅

  2. ssr 发展的由来(远古时代一神统领到众神争霸)

    1. WEB1.0 的时代(远古圣王)

      远古时代我们可能没有经历过,但是asp 、jsp这些可能都听说过吧 ,所有的应用都是服务端渲染(这时候的服务端渲染和我们现在说的服务端渲染不一样),话说那个时候页面渲染完全由服务端承担,浏览器请求页面的url ,然后服务器接受到请求之后,到数据库查询。将数据丢到后端的模版(asp、jsp)渲染成html片段组装片段 最后返回给浏览器。这个时候返回的HTML已经是完整的了包含js什么的,渲染到页面的过程中没有Javascript的参与。如图讲述

      页面的F12 查看张这样

    2. 客户端渲染

      讲一点题外话:WEB1.0时代那样的服务器渲染缺点越来越严重,每次更新页面上的一个小的地方不管是文字还是其他的小模块,都需要重新请求一次页面,重新查一遍数据库,重新组成一个HTML。javascript 代码和后端的PHP代码混在一起。越来越难搞。当然在这个时候前端职位很低 ,前端的工作经常是后端人员一把梭哈,前端人员经常被后端人员支配,支配的恐惧来袭,前后端鄙视链开始了,因为前端程序猿只是再写写js 做做页面交互,不算事真正的程序猿。

      之后nodejs出现,前端看到了翻身的契机,为了摆脱后端的指指点点,前端开启了一场前后端分离的运动,希望可以脱离后端独立发展。前后端分离,表面上看上去是代码分离,实际上是为了前后端人员分离(到这里不得不说前端人员的心机真的是哈哈哈哈哈),也就是前后端分家,前端不再归属于后端团队。

      前后端分离之后,网页开始被当成了独立的应用程序(SPA,Single Page Application),前端团队接管了所有页面渲染的事,后端团队只负责提供所有数据查询与处理的API

      大体流程是这样的:首先浏览器请求URL,前端服务器直接返回一个空的静态HTML文件(不需要任何查数据库和模板组装),这个HTML文件中加载了很多渲染页面需要的 JavaScript 脚本和 CSS 样式表,浏览器拿到 HTML 文件后开始加载脚本和样式表,并且执行脚本,这个时候脚本请求后端服务提供的API,获取数据,获取完成后将数据通过JavaScript脚本动态的将数据渲染到页面中,完成页面显示。

      页面的F12 查看张这样

    3. 服务端渲染

      终于讲到我们的正题了,随着单页面应用的发展。人们渐渐发现了一个东西啊,诶SEO出现问题了啊,搜索引擎很难爬到东西啊。而且应用越来越复杂javaScript越来越臃肿啊,使得首屏渲染的时间要比WEB1.0慢了啊。这可是大问题啊 ,强调一下首屏并不是首页(划重点)

      这没得办法勒 ,总不能再回去受后台人员支配吧?支配的恐惧又来了哈哈哈哈,怎么办 自己选的路跪着也要走完,于是前端团队又开始了,我发现这前端真是能折腾啊(不过我喜欢哈哈哈)

      于是前端团队选择了使用 nodejs 在服务器进行页面的渲染,进而再次出现了服务端渲染。大体流程与客户端渲染有些相似,

      1. 首先是浏览器请求URL,前端服务器接收到URL请求之后,根据不同的URL,前端服务器向后端服务器请求数据,请求完成后,
      2. 前端服务器会组装一个携带了具体数据的HTML文本,并且返回给浏览器,浏览器得到HTML之后开始渲染页面
      3. 同时,浏览器加载并执行 JavaScript 脚本,给页面上的元素绑定事件,让页面变得可交互,当用户与浏览器页面进行交互,如跳转到下一个页面时,浏览器会执行 JavaScript 脚本,
      4. 向后端服务器请求数据,获取完数据之后再次执行 JavaScript 代码动态渲染页面。 你们知道的该上图了啊

  3. 服务端渲染的优缺点

    优点有二

    1. 利于SEO ,不言而喻 ,相比于一个空壳的div块来说,页面上显示更多内容更利于爬虫来爬你的页面,这样流量也就会越高搜索引擎收录也就会越多。
    2. 白屏时间更多,相比于客户端渲染,服务端渲染在浏览器请求URL之后已经得到了一个呆数据的的HTML文本,浏览器只需要解析HTML,直接构建DOM树就可以了。而客户端需要先得到一个空的HTML页面,这几个时候页面进入了白屏状态,之后还需要经过加载并执行javascript,请求后端获取数据、Javascript渲染页面的几个过程才能看到最后的页面,时间长体验差。

    缺点

    1. 为实现服务端渲染,代码复杂度增大,代码中的需要兼容服务端和客户端两种运行情况。
    2. 需要更多的负载均衡,服务器压力大
    3. 部署和构建的设置的要求更高需要懂Nodejs
  4. Vue 进行剖析实践 终于要上代码啦 ( 画图真的很难)

    下一篇地址

文章分类
前端
文章标签