为什么现在又流行服务端渲染html?

题主有点搞错了,现在的服务端渲染跟以前的服务端渲染是完全不一样的.

首先介绍一下以前的传统模式:服务端渲染,代表是PHP这类,那时候前端只是写网页的,偶尔写点ajax,但是不多,大部分靠服务器查找数据然后渲染出来页面发送给浏览器展示,每次跳转都要从新执行一遍这个逻辑.因此挺消耗服务端的资源的.

后来H5出来后才有所改观,单页应用也逐渐兴起,Nodejs使前端可以脱离浏览器,进军服务器写后端代码.

非常多的人按捺不住内心的激动,终于不被人称为”切图仔”了,而且前端人群非常的多,此时我写这个回答的时候,NPM上的包就已经有654,218个了!

移动端开始兴起,网站的加载速度也开始变得重要,各个网站也开始考虑用户的感受,如果能降低用户的流量成本,就能使用户更快的进入页面,停留的时间也就更久,更能为公司带来经济效益,因此这变得越来越重要.

如果还是以前的传统方式,每次跳转都要重新加载页面下载数据,那么用户肯定受不了等待从而离开,损失是非常严重的,因此这时候的人瞄准了H5,使用H5构建的单页应用开始越来越多,只需要加载一次网页,后面就不需要再次下载,而且还可以做缓存,减少用户的流量费用.

但是前端很快发现了一个严重的问题,爬虫是不认js的,也就是说你无法给自己的网站做SEO.

SEO 搜索引擎优化是一种利用搜索引擎的搜索规则来提高目前网站在有关搜索引擎内的自然排名的方式.当百度或者其他搜索引擎的爬虫来到你的网站的时候,它发现这里面什么东西都没有,就只有一些css和js资源连接,但是它并不执行你的js,因此是无法获取到你的网站信息的,它就无法记录你的网站信息,用户使用搜索引擎的时候也就无法查询到关于你网站的数据信息,这是很严重的问题,你的网站流量会断崖式下跌.

因此针对这个问题,前端想到了一个预处理方案:服务器端渲染(SSR).

前端使用Nodejs搭建服务器,然后在用户访问的时候预先执行一些页面中js的逻辑,渲染成HTML,将它们直接发送到浏览器,很多流行的开源前端框架已经集成了这类方式,比如Vue.js,React.js,Angular.js等等.

与传统 SPA(Single-Page Application – 单页应用程序)相比,服务器端渲染(SSR)的优势主要在于:

1.更好的 SEO,由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。如果 SEO 对你的站点至关重要,而你的页面又是异步获取内容,则你可能需要服务器端渲染(SSR)解决此问题。

2.更快的内容到达时间,特别是对于缓慢的网络情况或运行缓慢的设备.无需等待所有的 JavaScript 都完成下载并执行,才显示服务器渲染的标记,所以你的用户将会更快速地看到完整渲染的页面.通常可以产生更好的用户体验,并且对于那些时间就是金钱的应用程序而言,服务器端渲染(SSR)至关重要。

使用服务器端渲染(SSR)时还需要有一些权衡之处:

1.涉及构建设置和部署的更多要求.与可以部署在任何静态文件服务器上的完全静态单页面应用程序(SPA)不同,服务器渲染应用程序,需要处于 Node.js server 运行环境.

2.在 Node.js 中渲染完整的应用程序,显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源,因此如果你预料在高流量环境下使用,请准备相应的服务器负载,并明智地采用缓存策略.

在对你的应用程序使用服务器端渲染(SSR)之前,你应该问第一个问题是否真的需要它.这主要取决于内容到达时间对应用程序的重要程度.例如,如果你正在写一个活动页,那么初始加载时的额外几百毫秒并不重要,这种情况下去使用服务器端渲染(SSR)肯定是一个小题大作之举.然而,内容到达时间(time-to-content)要求是绝对关键的指标,在这种情况下,服务器端渲染(SSR)可以帮助你实现最佳的初始加载性能.

不了解web的发展历史很难理解为什么现在又流行服务端渲染html了。现在的服务端渲染html和过去的渲染方式并不相同,所采用的技术、方式、方法也不相同,并不是旧瓶装旧酒,而是旧瓶装新酒。技术的更迭很大一部分原因在于出现了瓶颈无法满足当下的网络数据供应。

渲染一词起源于游戏领域、3D设计领域,渲染的意义在于并不是简单地画一张画呈现在其他人面前,而以数据的形式保存物体的位置,颜色、法线、纹理、光照等,当有人需要查看的时候,就会重新再次准确地重现,重现的过程就是渲染。

渲染流程会接受使用定点描述3D物体的原始数据作为输入用于处理,再计算它的片段(fragment),片段就是一个个像素的3D投射,片段包含了位置、颜色、法线、纹理、光照等等,渲染好的像素输出到显示屏上。

浏览器端渲染和服务器端渲染的区别

页面渲染的本质就是浏览器将HTML文本转换成页面的过程。页面渲染大致需要走过下面几个步骤:

1、用户输入网址后浏览器请求服务器端得到一个HTML文本。

2、接着就到了HTML文本解析的过程了,先构建DOM树。如果遇到了内联样式、样式脚本,就需要下载并构建样式规则。如果遇到JavaScript脚本就会下载并执行。

3、DOM树、样式规则构建完后渲染进程就会将他们两合并成渲染树,然后渲染进程就会对渲染树进行布局,生产布局树。渲染进程对布局树进行绘制并生成绘制记录。

4、渲染进程对布局树分成并栅格化每一层得到合成帧,再发给GPU进程显示到浏览器的页面中。

服务器端渲染(SSR)会在浏览器请求页面的URL的时候,就会把我们需要的HTML文本组装好,然后返回给浏览器,浏览器不需要再经过JavaScript执行就可以直接构建出DOM树并展示到页面中。客户端渲是当浏览器请求URL时服务器端直接返回一个空的静态HTML文件,服务器端不需要任何查数据库和模板组装的操作。浏览器拿到这个HTML文件后就开始样式表和脚本,脚本会请求服务器端提供的API来获取数据,获取完数据后JavaScript脚本就会动态地将数据渲染到页面中,完成页面的显示。

web的发展史

web1.0时代没有AJAX,几乎所有的应用都是服务器端渲染,浏览器请求页面URL之后,服务器端会将所有的东西准备好,包括了数据库查询到的数据、组件模板(PHP、ASP、JSP等)等,返回给浏览器,浏览器不需要任何的JavaScript参与。

但随着人们的期许值越来越大,web业务也变得越来越复杂了,再加上AJAX的出现,web1.0服务器端渲染暴露出了很多缺点,比如我们每次点击页面的一个小模块都需要重新请求一次页面,重新查询数据库,重新组装加载一次html。JavaScript、jsp、php、asp代码混在一起更是使得web应用很难进行维护。

nodejs出现之后网页开始被当成了SPA,即独立应用程序。前端接管了所有页面渲染的事情,而服务器端只负责数据查询和处理API。

SPA发展过程中也逐渐暴露出很多问题,比如不利于搜索引擎SEO,JavaScript日益臃肿导致首批渲染速度还不及web1.0时代的服务器端渲染,于是服务器端渲染再次被应用,当浏览器请求URL时,前端服务器会根据不同的URL向后端服务器请求数据,请求完前端服务器会组装一个携带具体数据的HTML文本返回给浏览器。浏览器会同时渲染页面、加载执行JavaScript脚本。当我们请求跳转到别的页面的时候,浏览器会执行JavaScript脚本,同时向后端服务器请求数据,获取完数据后再次执行JavaScript脚本动态渲染页面。

综上所述

服务器端渲染、客户端渲染的进化史其实也是前、后端工程师血泪发展史。早期后端总是鄙视前端js太简单,前端也无非是切切图、写写js特效,前端工程师根本算不上一个程序员。

如今前端翻身了彻底地摆脱了后端的指指点点。如今一份代码,既可以由服务端渲染,也可以由客户端渲染。


以上个人浅见,欢迎批评指正。

认同我的看法,请点个赞再走,感谢!

喜欢我的,请关注我,再次感谢!

我想说不论是前端还是后端,能不能别乱用渲染这个词,你说的是服务端是否生成html文件,而渲染从来都是浏览器干的事。

需要了解的一点是,时代在进步,现在的服务端渲染和过去的服务端渲染可以说是两码事,不能同日而语的啊!

以前的服务器的渲染,主打的是“文档”,以“文档”作为其核心的思想,就是把HTML,CSS,Javascript等当做是一个静态的定格的文件的形式,也不存在所谓的指令和数据的区别,对于“文档”的概念而言,万物皆是数据,比如说GET就是一个请求的文件,在比如像asp等都是把HTML文件放在占位符里,然后由服务端转化为实际的数据。

Web 2.0时代最大的一项变革就是把网页当作是一种独立的应用程序,而并不是进行所谓的前后端分离。

那现在的服务器渲染又是什么意思呢?

自然不会走老路的,要知道虽然你总能在历史故事中找到一些相似性的东西,但并不意味着这种东西是重复性的发展,其实它是在历史的巨轮中螺旋上升的。

现在的服务器渲染有一个目的,那就是为了加速和进行搜索引擎的一些优化而已,就像是给APP截图的感觉,更像是一种“快照”,毕竟孱弱的爬虫已经无法满足日益发展的前端的进化速度了!

题主这个问题真是有点,额。

什么是服务端渲染?以前的php、jsp、.net做web难道不都是服务端渲染好html再通过web server发送前端吗?

你说的服务端渲染难道是指由大前端而兴起的spa之类的吗?那也只是对seo有需求的才要通过服务端渲染好再发送给前端,没有seo需求的完全无所谓什么服务端渲染了。

我认为服务端渲染只是未来两年内的妥协。

等5G来了,首屏加载速度区别不大,应该会缩短到1秒内。

未来百度迟早会支持JS解析后的SEO,这个谷歌早已实现。

服务端渲染是为了SEO和首屏秒出,为了这个妥协的太多了,组件生命周期变更、服务端负载上升、部署比静态麻烦、还需要一个nodejs做中间层。所以当社会环境允许的情况下,SPA开发起来会轻松很多。

这个问题的起点可以归结为大前端的崛起而兴起来的,其实也是有一定的需求场景导致的。

纯粹的前端渲染仅仅只是在原始状态下,我们使用新兴起来的mvvm设计模式框架来打造的站点结构,所有的编译,渲染时间几乎都是由浏览器来承担,所以相当于把很多的性能负担均摊给了用户,其实对于码农来说,这其实是一个比较好的方案。

但是由于前端的热门,大家在越来越多的应用,系统都渐渐使用前后端隔离,这种技术越来越多的使用起来。

那么摆在用户面前最直接的就是首屏,响应时间的感知,码农需要去解决不同浏览器上的渲染异常并且尽量让其更快,这个时候后端渲染就顺势而生了,它解决了这些比较头疼的问题,也更好的兼容了SEO。

不过现在各类前端框架都提供了自己的ssr支持,也有不少优秀的脚手架帮助大家一健部署ssr环境,所以按照应用需求的话适当转变业务为SSR也是不错的选择。

老妖想了半天,没发现现在又流行服务端渲染html啊?当然,不排除一些相对小众的语言或框架是服务器渲染html,但现在都是前后端分离的架构,前后端交流的只是json数据,根本不会传递html。细思一下,可能有一些站点比较在意在搜索引擎中的排名,所以会采用服务端直接生成html页面的方式。但这也不是主流啊。只是一种特殊应用而已。

关键在于老式网站可以转化成APP了,比如一个jsp网页之前没法做成APP,现在就可以,之前技术一直没用克服,需要做成html文件再通过js框架渲染页面。也看具体做什么类型网站,有的适合客服端渲染,有的适合服务端渲染。

其实前后端渲染的选择,并没有太多关系到服务器的效率。而是多数网站需要权衡内容的可见性与功能性两者。

一、内容可见性

指的是让有效内容更容易被获取,因为多数网站是展现有效内容给用户,帮助公司或品牌产品得到更多的流量,这类网站涉及到SEO尤为重要,非常有必要为了让自己的内容更容易被索引且获得更好的排名而付出一些努力。因此此类网站不喜欢使用过多JS生成的内容,既所谓的前端渲染。因为这类页面不利于搜索引擎索引自己的页面,这样就很难通过有效内容从搜索引擎得到有效的引流。

早期的网站,很多都是以呈现有效内容为主,很少用JS实现丰富的应用功能,因此比较多地关注关键字,内部链接,外部链接等等来提高网站的权值。

以提供有效内容为主的网站,主要有静态,动态之分。静态以标准HTML为主,动态多由服务器根据请求生成SEO友好的内容。两者对前端浏览来说没有太大的区别。主要是是服务器端的服务方式,如静态多以简单文件形式提供,动态诸如ASP,ASPX,CGI(不同的脚本),或者是高端语言的Web开发框架,实现是极其灵活丰富的。目的都是相同的,既提供更有效的内容给用户。

至于效率,可以有多重优化方式,从来都不是开发上首要考虑到问题。

二、服务功能性

此类网站通常使用一个比较现代也比较高端的名称,既WebApp。其主要目的并非提供用户感兴趣的内容为主。网站更希望与用户可以有更多的交互,同过为用户提供一系列更为实用的应用功能,并从中获取反馈或回报。

这类网站的流行得益于多重技术都发展,首先是计算机处理速度有了更好的提升,CPU、GPU以及内存等不再是限制JS执行复杂功能的瓶颈;其次是以WebKit为内核的浏览器逐渐发展强大,并在Google的努力之下,Chromium得到了极大的发展,大大地推动了基于浏览器的WebApp的可用和可行性。一大批成功的基于浏览器的富应用被开发出来并取得巨大成功,使得JS比以往任何时候都更流行,让JS名副其实地成为Web Language。

随后进一步发展的CSS3,HTML5,强化的JS组件,如WebSocket,Web Worker等等,让JS在浏览器端实现功能强大的富应用更得心应手。

总之,整个行业的发展使得网站不再是简单的靠内容提供而获取流量,提供有效的富应用功能可以让网站变得更加有价值。

因此到底是后端渲染还是前端渲染,实则是行业发展所需,并非简单的考虑效率(服务器效率可以很有很多方法优化,从来不是问题)。将更多的运算放到前端,正是由于WenApp的形态已经越来越成熟,成功的标杆应用已经越来越多了!

未经允许不得转载:科普Room » 为什么现在又流行服务端渲染html?

搞事情!那些不能说的秘密都在这里   关注公众号:科普Room  

         

赞 (0) 打赏

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏