前端渲染和后端渲染的区别10bet

来源:http://www.chinese-glasses.com 作者:Web前端 人气:102 发布时间:2020-04-15
摘要:时间: 2019-10-05阅读: 151标签: 渲染 在网上查找了很久的前端渲染和后端渲染的区别,最后总算在知乎上看到了一个比较清楚的解释,感谢万分! 可能大家在看到这个标题的时候,会觉得

时间: 2019-10-05阅读: 151标签: 渲染

在网上查找了很久的前端渲染和后端渲染的区别,最后总算在知乎上看到了一个比较清楚的解释,感谢万分!

可能大家在看到这个标题的时候,会觉得,只不过又是一篇烂大街的 SSR 从零入门的教程而已。别急,往下看,相信你或多或少会有一些不一样的收获呢。

作者:iakul
链接:https://www.zhihu.com/question/28725977/answer/42077482
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

在落地一种技术的时候,我们首先要想一想:

后端渲染(SSR、服务端渲染)

后端渲染HTML的情况下,浏览器会直接接收到经过服务器计算之后的呈现给用户的最终的HTML字符串,这里的计算就是服务器经过解析存放在服务器端的模板文件来完成的,在这种情况下,浏览器只进行了HTML的解析,以及通过操作系统提供的操纵显示器显示内容的系统调用在显示器上把HTML所代表的图像显示给用户。

是否一定需要引入这种技术呢?他能解决什么问题,或者能带来什么收益?为什么要采用这种技术选型而不是其他的?引入了这种技术后,会带来什么问题吗(比如额外的开发成本等)?

前端渲染(SPA、单页面应用)

前端渲染就是指浏览器会从后端得到一些信息,这些信息或许是适用于题主所说的angularjs的模板文件,亦或是JSON等各种数据交换格式所包装的数据,甚至是直接的合法的HTML字符串。这些形式都不重要,重要的是,将这些信息组织排列形成最终可读的HTML字符串是由浏览器来完成的,在形成了HTML字符串之后,再进行显示。

题主所提到的几个技术,我认为模板这个词语并不能用来区分这些技术的本质,模板只是一种提供给程序来解析的一种语法,换句话说,模板是用于从数据(变量)到实际的视觉表现(HTML代码)这项工作的一种实现手段,而这种手段不论在前端还是后端都有应用。

以下为本人自己的想法:在性能上,我认为后端渲染最终会被前端渲染,因为后端渲染将所有的HTML生成集中在了一个服务器上,而前端渲染将这部分工作分发到各个终端上。另外,对于开发而言,这样能够避免后端开发人员过多的编写HTML代码,后端开发人员只需和前端开发事先商定好数据格式,后端就只需将数据生成,用数据交换格式包装,再发送出去就可以了,这样能够使开发人员之间的分工更加明确。

上面三个问题思考清楚之后,才能真正地去落地。上面三个问题思考清楚之后,才能真正地去落地。而有赞教育接入服务端渲染,正是为了优化 H5 页面的首屏内容到达时间,带来更好的用户体验(顺便利于 SEO)。

再附上稀土掘金上的一段理解:

说了这么多,以下开始正文。

SEO

很重要,所以要普及。

SEO: 搜索引擎优化(Search Engine Optimization),它是指通过站内优化,如:网站结构调整、网站内容建设、网站代码优化以及站外优化等方法,来进行搜索引擎优化。

简单说: 通过各种技术(手段)来确保,你的Web内容被搜素引擎最大化收录,最大化提高权重,带来更多流量。

常见关键词:白帽、黑帽、SEM、Backlink、Linkbait、PageRank、Keyword Stuffing...,总之都围绕着一个核心:SEO;流量是变现的快车道,SEO是低成本获取流量的最佳方法。

一、后端模版引擎时代

SPA

SPA:单页Web应用(single page web application,SPA),就是只有一张Web页面的应用,是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。

简单说: Web不再是一张张页面,而是一个整体的应用,一个由路由系统、数据系统、页面(组件)系统...组成的应用程序,其中路由系统是非必须的。

大部分的Vue项目,本质是SPA应用,Angular.js、Angular、Vue、React...还有最早的"Pjax"均如此。

SPA时代,主要是在Web端使用了history或hash(主要是为了低版本浏览器的兼容)API,在首次请求经服务端路由输出整个应用程序后,接下来的路由都由前端掌控了,前端通过路由作为中心枢纽控制一系列页面(组件)的渲染加载和数据交互。

而上面所述的各类框架则是将以:路由、数据、视图为基本结构进行的规范化的封装。

最早的SPA应用,由Gmail、Google Docs、Twitter等大厂产品实践布道,广泛用于对SEO要求不高的场景中。

在较早时期,前后端的配合模式为:后端负责服务层、业务逻辑层和模版渲染层(表现层);前端只是实现页面的交互逻辑以及发送 AJAX。比较典型的例子就是 JSP 或 FreeMarker 模板引擎负责渲染出 html 字符串模版,字符串模版里的 js 静态资源才是真正前端负责的东西。

SSR

SSR: 服务端渲染(Server Side Render),即:网页是通过服务端渲染生成后输出给客户端。

在SPA之前的时代,我们的Web架构大都是SSR,如:Wordpress(PHP)、JSP技术、JavaWeb...或者DEDECMS、Discuz!等这些程序都是传统典型的SSR架构,
即:服务端取出数据和模板组合生成html输出给前端,前端发生请求时,重新向服务端请求html资源,路由也由服务端来控制。

其次,有个概念叫预渲染(Prerendering)。

如果你只是用服务端渲染来改善一个少数的营销页面(如 首页,关于,联系 等等)的SEO,那你可以用预渲染来实现。
预渲染不像服务器渲染那样即时编译HTML,它只在构建时为了特定的路由生成特定的几个静态页面,等于我们可以通过webpack插件将一些特定页面组件build时就编译为html文件,直接以静态资源的形式输出给搜索引擎。

但实际的商业应用中,大部分时候我们需要的是即时渲染,这也是我们今天讨论的主题。

而这种形式,就是天然的服务端渲染模式:用户请求页面 - 请求发送到应用服务器 - 后端根据用户和请求信息获取底层服务 - 根据服务返回的数据进行组装,同时 JSP 或 FreeMarker 模版引擎根据组装的数据渲染为 html 字符串 - 应用服务器讲 html 字符串返回给浏览器 - 浏览器解析 html 字符串渲染 UI 及加载静态资源 - js 静态资源加载完毕界面可交互。

Why

为什么要SSR,为了体验,还有SEO

首先,用户可能在网络比较慢的情况下从远处访问网站 - 或者通过比较差的带宽。 这些情况下,尽量减少页面请求数量,来保证用户尽快看到基本的内容。
可以用Webpack的代码拆分避免强制用户下载整个单页面应用,但是,这样也远没有下载个单独的预先渲染过的HTML文件性能高。

对于世界上的一些地区人,可能只能用1998年产的电脑访问互联网的方式使用计算机。
而Vue只能运行在IE9以上的浏览器,你可能也想为那些老式浏览器提供基础内容 - 或者是在命令行中使用 Lynx的时髦的黑客。

在大部分的商业应用中,我们有SEO的需求,我们需要搜索引擎更多地抓取到我们的内容,更详细地认识到我们的网页结构,而不是仅对首页或特定静态页进行索引,这是SSR最重要的意义。

简单说就是,我们需要搜素引擎看到这样的代码:

10bet 1

这里写图片描述

而不是这样的代码:

10bet 2

这里写图片描述

且,我们还需要在SSR的基础上实现SPA,即:首屏渲染。

基本流程是:

在浏览器第一次访问某个URI资源的时候(首屏),Web服务器根据路由拿到对应数据渲染并输出,且输出的数据中包含两部分:

  • 路由页对应的页面及已渲染好的数据
  • 完整的SPA程序代码

在客户端首屏渲染完成之后,此时我们看到的其实已经是一个和之前的SPA相差无几的应用程序了,接下来我们进行的任何操作都只是客户端的应用进行交互,
页面/组件由Web端渲染,路由也由浏览器控制,用户只需要和当前浏览器内的应用打交道就可以了。

之前在各大SPA框架还未正式官方支持SSR时,有一些第三方的解决方案,如:prerender.io
它们做的事情就是建立HTTP一个中间层,在判断到访问来源是蜘蛛时,输出已缓存好的html数据,此数据若不存在,则调用第三方服务对html进行缓存,往复进行。

另一方法是自行构建蜘蛛渲染逻辑,当识别UA为搜索引擎时,拿服务端已准备好的模板和数据进行渲染输出html数据,反之,则输出SPA应用代码;

我当时也考虑过此方法,但有很多弊端,如:

需要针对蜘蛛编写一套独立的渲染模板,因为大部分情况下SPA的代码是没法直接在服务端使用的
搜索引擎若检测到蜘蛛抓取数据和真实访问数据不一致,会做降权惩罚,也就意味着渲染模板还必须和SPA预期输出一模一样
所以,最好的方法是SPA能和服务端使用同一套模板,且使用同一个服务端逻辑分支,再简单说:最好Vue、Ng2...能直接在服务端跑起来。

于是,陆续诞生了基于React的Next.js、基于Vue的Nuxt.js、Ng2诞生之日便支持。

没错,Nuxt.js就是今天的主角。

转载自https://juejin.im/post/58ff960ba22b9d0065b722cd

那么既然后端模版引擎时代带来的效果就是我们想要的,那为啥还有以后让前端发展服务端渲染呢?因为很明显,这种模式从开发角度来讲还有挺多的问题,比如:

10bet,后端需要写表现层的逻辑,但其实后端更应该注重服务层(和部分业务逻辑层)。当然,其实也可以让前端写 JSP 或 FreeMarker,但从体验上来说,肯定不如写 JS 来的爽;本地开发的时候,需要启动后端环境,比如 Tomcat,影响开发效率,对前端也不友好;所赋予前端的能力太少,使得前端需要的一些功能只能由后端提供,比如路由控制;前后端耦合。二、SPA 时代

后来,诞生了 SPA(Single Page Application),解决了上面说的部分问题:

后端不需要关心表现层的逻辑,只需要注重服务层和业务逻辑层就可以了,暴露出相应的接口供前端调用。这种模式也同时实现了前后端解耦。

本地开发的时候,前端只需要启动一个本地服务,如:dev-server 就可以开始开发了。赋予了前端更多的能力,比如前端的路由控制和鉴权,比如通过 SPA + 路由懒加载的模式可以带来更好的用户体验。

但同时,也带来了一些问题:

页面的 DOM 完全由 js 来渲染,使得大部分搜索引擎无法爬取渲染后真实的 DOM,不利于 SEO。页面的首屏内容到达时间强依赖于 js 静态资源的加载(因为 DOM 的渲染由 js 来执行),使得在网络越差的情况下,白屏时间大幅上升。三、服务端渲染

正因为 SPA 带来的一些问题(尤其是首屏白屏的问题),接入服务端渲染显得尤为必要。// 终于讲到服务端渲染这个重点了。

而正是 Node 的发展和基于 Virtual DOM 的前端框架的出现,使得用 js 实现服务端渲染成为可能。因此在 SPA 的优势基础上,我们顺便解决了因为 SPA 引入的问题:

服务端渲染的首屏直出,使得输出到浏览器的就是完备的 html 字符串模板,浏览器可以直接解析该字符串模版,因此首屏的内容不再依赖 js 的渲染。

正是因为服务端渲染输出到浏览器的是完备的 html 字符串,使得搜索引擎能抓取到真实的内容,利于 SEO。

同时,通过基于 Node 和前端 MVVM 框架结合的服务端渲染,有着比后端模版引擎的服务端渲染更明显的优势:可以优雅降级为客户端渲染(这个后续会讲,先占个坑)。

3.1 实现

既然服务端渲染能带来这么多好处,那具体怎么实现呢?从官网给出的原理图,我们可以清晰地看出:

Source 为我们的源代码区,即工程代码;

Universal Appliation Code 和我们平时的客户端渲染的代码组织形式完全一致,只是需要注意这些代码在 Node 端执行过程触发的生命周期钩子不要涉及 DOM 和 BOM 对象即可;

比客户端渲染多出来的 app.js、Server entry 、Client entry 的主要作用为:app.js 分别给 Server entry 、Client entry 暴露出 createApp() 方法,使得每个请求进来会生成新的 app 实例。而 Server entry 和 Client entry 分别会被 webpack 打包成 vue-ssr-server-bundle.json 和 vue-ssr-client-manifest.json(这两个 json 文件才是有用的,app.js、Server entry 、Client entry 可以抽离,开发者不感知);

Node 端会根据 webpack 打包好的 vue-ssr-server-bundle.json,通过调用 createBundleRenderer 生成 renderer 实例,再通过调用 renderer.renderToString 生成完备的 html 字符串;

Node 端将 render 好的 html 字符串返回给 Browser,同时 Node 端根据 vue-ssr-client-manifest.json 生成的 js 会和 html 字符串 hydrate,完成客户端激活 html,使得页面可交互。

3.2 优化

按照 Vue SSR 官方文档建立起一个服务端渲染的工程后,是否就可以直接上线了呢?别急,我们先看看是否有什么可以优化的地方。

3.2.1 路由和代码分割

一个大的 SPA,主文件 js 往往很大,通过代码分割可以将主文件 js 拆分为一个个单独的路由组件 js 文件,可以很大程度上减小首屏的资源加载体积,其他路由组件可以预加载。

本文由10bet发布于Web前端,转载请注明出处:前端渲染和后端渲染的区别10bet

关键词:

上一篇:vue的provide / inject 有什么用?【10bet】

下一篇:没有了

最火资讯