[转]谈谈前端渲染 VS 后端渲染

首先,预编译跟前后端没有关系,预编译一样可以用于后端渲染。

看看下面的测试时间,单位: ms

模板字符串:

var s = '{{#datas}}{{name}} abcdefg {{type}} {{date}}{{/datas}}';

数据对象: 放入100000行数据

var stack = [];
for (var i = 0; i < 100000; i++) {
    stack.push({
        name: 'name-' + i,
        type: 'type-' + i,
        date: (new Date()).toLocaleString()
    });
}
var datas = {datas: stack};

后端渲染:
生成HTML

var start = Date.now();
require('hogan').compile(s).render(datas);
var end = Date.now();
console.log(end - start);  // 166 ms 我的机器时间

前端渲染:
我在这里做了最简单的设定,只把datas转化成字符串

var start = Date.now();
JSON.stringify(datas);
var end = Date.now();
console.log(end - start);  // 450 ms 我的机器时间

结果对比一目了然,你可以把这个测试用其他模板引擎测试一下。

服务器为了前端渲染,对对象的字符串化所消耗的时间,
远远大于 
服务器直接渲染模板生成HTML所花费的时间。

我的建议是前后端模板同时使用.

  • 后端模板+Bigpipe处理页面加载, 加上预编译, 这要比直接转换对象=>字符串快, 而且减少前端模板文件的加载量
    res.write(require('hogan').compile(s).render(datas)) 要比

    res.write(JSON.stringify(datas))快

  • 前端模板, 主要是部分需要ajax加载的部件
  • 剩下一个最难对付的就是SEO,对于不支持js的机器人,还是需要额外的一套非模板的代码.

这个问题的焦点并不在“放在哪里渲染快”,如果你要考虑这个效率问题,那是不是也得同时思考下:

  • 后端渲染完了之后,需要进行网络传输的体积大了,带来的网络损耗和网络传输时间问题

很多场景,尤其是在移动端,我们通常不会把渲染工作交给后端,一方面后端渲染需要时间,一方面庞大的渲染数据传输也有时延,所以就会出现白屏问题。Bigpipe可以一定程度上处理这个问题,不够构架成本略高,用的人偏少。
若把数据交给前端渲染,也存在一定的弊端,比如需求发生变化之后,接口需要调整,前端模板的解析也要跟着一起变化,这样隔着一层接口开发,办事效率就低了很多,因为我们至少要跟开发同学交涉。

nodejs 的出现让模板复用方便了不少,很多时候,让后端渲染一部分(比如首屏部分),后面的工作就交给前端异步去处理。两者结合起来效果才是最佳的。

SEO问题嘛,看产品需求,很多产品优化了 SEO 也没多大作用,如果实在要考虑:

  1. 可以使用 pjax / quickling / hash bang 等技术
  2. 服务器端根据 UA 输出内容


不能简单这么比吧,你这个测试只说明V8在你服务器环境上单次执行这个渲染的速度比PC快,但要知道服务器可是每个请求都执行渲染,影响的是全部用户,而前端渲染只影响单机。
所以“后端吐首屏+前端渲染剩下的”是比较合适的办法。



移动端,如果不是webapp,只需要发送数据就可以了.安卓和ios客户端自己管理渲染.

对于PC端HTML内容的渲染,我还是比较建议Bigpipe推.

如果是采用ajax拉,那么页面上每一个部件要多增加一个客户端请求.
而请求带来的请求体解析,本身是十分消耗服务器资源的.

比如一个网页有3个部分,来自3个数据库请求:

[用户账单] 
[用户消息]
[用户文章]

如果是Bigpipe, 过程是这样的:

客户端请求
服务器发送布局HTML
服务器发送渲染过的<script>用户账单</script>
服务器发送渲染过的<script>用户消息</script>
服务器发送渲染过的<script>用户文章</script>
服务器发送HTML结束标签</body></html>

只有1次服务器请求

如果是前端ajax渲染, 过程是这样的:

客户端请求
发送完整HTML布局页
客户端用户账单ajax请求
客户端用户消息ajax请求
客户端用户文章ajax请求
服务器发送用户账单数据
服务器发送用户消息数据
服务器发送用户文章数据

这个过程需要4次客户端请求.
就算是把后3个ajax合并为一个ajax,也需要2个客户端请求.



浏览器端渲染优点:

  • 分散服务端渲染时间到浏览器端
  • http response 大小也会减少
  • 对可维护性也有很大好处
    • 很容易搭建 前端独立的开发环境
    • 减少了模板修改跟后端同步的问题

缺点就是:

  • seo
  • 首屏会有白屏
  • 最头疼的一个问题可能是 业务逻辑的问题,因为很容易业务逻辑就跑到 js 来了

前端渲染的方式的话我觉得不一定是 bigpipe ,还要看场景;

对移动端上我觉得还是后端渲染好些,因为移动端上 cpu 还是要差些的,放到浏览器端渲染可能白屏时间更长一些

时间: 2024-10-29 12:39:04

[转]谈谈前端渲染 VS 后端渲染的相关文章

前端渲染和后端渲染

一.前端渲染 定义:前端预定义好HTML,然后向后端请求数据,得到数据(XML.JSON等)后,通过JS去加载数据. 优点:节省网络流量,利于SEO,节省部分服务器资源. 缺点:前端处理数据费时,可能造成假死等. 举例:EasyUI 二.后端渲染 定义:在后端就渲染好HTML页面,直接发送给浏览器显示. 优点:前端页面加载迅速,无数据处理过程. 缺点:占用服务器资源.网络数据耗费大. 举例:FreeMaker,Velocity,JSP PS:之前在学习JSP等模板引擎的时候听到纯前端朋友提到了通

后端渲染实践——看掘金社区是如何实践的

Vue.js.React.js 及 Angular.js 等等前端开发框架引入了 UI = framework(State) 的前端编程逻辑,大范围降低了前端业务开发的难度,尤其是面向复杂前端应用.而这些优质开源框架的普及.多端业务统一.前后端分离的需求让越来越多的架构设计将大部分业务逻辑写在了前端. 但是,纯前端产品也有着它的问题.上述的几个前端框架都支持了后端渲染的功能,从而融合了前后端的问题.如何有效地整合现有前端逻辑实现后端渲染.如何优化后端渲染性能.如何实现服务器流式吐内容更快地渲染页

前后端渲染

静态HTML指:使用单纯的HTML或者结合CSS制作的包括图片.文字等的只供用户浏览但不包含任何脚本.不含有任何交互功能的网页. 动态的HTML指:网页不仅提供给用户浏览,网页本身还有交互功能,存在着在脚本如JAVASCRIPT,并利用某种服务器端语言如PHP等实现如用户注册,用户登录,上传文件,下载文件等功能,动态页面可以人机互动,静态只能回服务器的数据库再回到页面 后端渲染(SSR.服务端渲染)后端渲染HTML的情况下,浏览器会直接接收到经过服务器计算之后的呈现给用户的最终的HTML字符串,

后端渲染

avalon2的后端渲染实践 avalon2为了提高性能,采用全新的架构,四层架构,其中一层为虚拟DOM. 虚拟DOM的一个好处是能大大提高性能,另一个好处是能过错整描述我们的页面结构.因此在非浏览器环境下,虚拟DOM也能正常运行.并且avalon2自一开始,就努力隔离DOM API.基于这两点,avalon2可以原封不动地运行于nodejs中,进行定义VM,渲染视图等操作. 客户端上,虚拟DOM通过vm.$render方法渲染到页面中 服务端上,虚拟DOM使用serveRender生成HTML

【大前端之前后分离】JS前端渲染VS服务器端渲染

前言 之前看了一篇文章:@Charlie.Zheng Web系统开发构架再思考-前后端的完全分离,文中论述了为何要前后分离,站在前端的角度来看,是很有必要的:但是如何说服团队使用前端渲染方案却是一个现实问题,因为如果我是一个服务器端,我便会觉得不是很有必要,为什么要前后分离,前后分离后遗留了什么问题,如何解决,都得说清楚,这样才能说服团队使用前端渲染的方案,而最近我刚好遇到了框架选型的抉择. 来到新公司开始新项目了,需要做前端框架选型,因为之前内部同事采用的fis框架,而这边又是使用的php,这

前后端渲染的区别

后端渲染:在服务器进行渲染,服务器进程从数据库获取数据后,利用后端模板引擎,甚至是在HTML模板中嵌入后端语言(例如JSP), 将数据加载进来生成HTML,通过网络传输到用户的浏览器中,再被浏览器解析成可见的页面. 1.对于搜索引擎很友好. 2.首页加载的时间短,后端渲染加载完成后就直接显示HTML,但是前端渲染在加载完成后还需要有段js渲染时间. 前端渲染:在浏览器里利用JS把数据和HTML模板进行组合. 1.业务分离,后端只需要提供数据接口,前端在开发时不需要部署对应的后端环境,通过一些代理

细说后端模板渲染、客户端渲染、node 中间层、服务器端渲染(ssr)

细说后端模板渲染.客户端渲染.node 中间层.服务器端渲染(ssr) 前端与后端渲染方式的发展大致经历了这样几个阶段:后端模板渲染.客户端渲染.node 中间层.服务器端渲染(ssr). 1. 后端模板渲染 前端与后端最初的渲染方式是后端模板渲染,就是由后端使用模板引擎渲染好 html 后,返回给前端,前端再用 js 去操作 dom 或者渲染其他动态的部分. 这个过程大致分成以下几个步骤: 前端请求一个地址 url 后端接收到这个请求,然后根据请求信息,从数据库或者其他地方获取相应的数据 使用

理解Web路由(浅谈前后端路由与前后端渲染)

1.什么是路由? 在Web开发过程中,经常会遇到『路由』的概念.那么,到底什么是路由?简单来说,路由就是URL到函数的映射. 2.router 和 route 的区别 route就是一条路由,它将一个URL路径和一个函数进行映射,例如: /users -> getAllUsers() /users/count -> getUsersCount() 这就是两条路由,当访问 /users 的时候,会执行 getAllUsers() 函数:当访问 /users/count 的时候,会执行 getUs

「前端进阶」高性能渲染十万条数据(虚拟列表) (自己修改版本)

前言 在工作中,有时会遇到需要一些不能使用分页方式来加载列表数据的业务情况,对于此,我们称这种列表叫做长列表.比如,在一些外汇交易系统中,前端会实时的展示用户的持仓情况(收益.亏损.手数等),此时对于用户的持仓列表一般是不能分页的. 在高性能渲染十万条数据(时间分片)一文中,提到了可以使用时间分片的方式来对长列表进行渲染,但这种方式更适用于列表项的DOM结构十分简单的情况.本文会介绍使用虚拟列表的方式,来同时加载大量数据. 为什么需要使用虚拟列表 在实际的工作中,列表项必然不会仅仅只由一个li标