详解篇一：浅析前后端分离的效率优势

Posted 2021-04-30 老猿挂印

传统的服务端渲染静态html返回，与现在流行的前后端分离相比，谁的效率更高？

提问者：AkagiInc

00

当我在说效率的时候, 我们在说什么？

既然我们说到效率, 今天就一次过满足你两个愿望。

1.开发效率；

2.运行效率。

讨论前后分离带来的效率变化，为了更好地在团队里推(qiang)行(zhi)前后分离，就需要从这两个角度去说服(dui)开发人员。

01

开发效率

我们先假设一种理想情况

1.前期的需求设计接口定义已经非常完善；

2.前后端对分离后的技术手段都已经非常熟练。

在这个大背景下，跟过去同样的工作量(假设工作量本质上是相同的)。

那么 前后分离 可以让任务更加多地并行开发，无疑这个时候开发效率是能得到显著的提高的。

同时，前后分离可以让一套系统的不同部分，进行分别迭代、分别进化。这对于敏捷开发要求的小步快跑、快速迭代是有与生俱来的好感的， 这无疑是不断优化系统的路上的强大推力。

但现实中的情况却不是这样

通常来说团队更习惯于过去已经掌握的技巧，前端写完静态页面，再由后端套模板引擎标签，最后一体化发布。

他们已经在这个体系下非常熟练地开发各种项目，如果强行推行新的技术手段，显然在当下是会牺牲掉一些开发效率。

那么结论到底是如何？

来自个人的一些见解：

着眼于长远考虑，前后分离可以让开发效率有很大的提升，并且开发质量也会因为更多的专业化，工程化而得到前所未有的提高。

2016年是前端工程化重要的一年，相信没有人会质疑工程化带来的优势。

回顾前文阐述的一种理想情况，也并不是遥不可及，想要蜕变就要付出阶段性代价，争取早日达到“理想情况”才是一个技术团队的终极追求。

所以，从开发效率的角度来考虑，建议早日走上前后分离的道路。

03

运行效率

我们把 计算效率 和 传输效率 都归到这个环节里来讨论。

计算效率

对于老一套的方法，所有页面看到的东西，都要通过后端程序，根据模板渲染出一个html文档。

所谓的渲染，就是字符串的查找、替换和拼接。

这种操作是非常消耗计算资源的，那么同样的千万次请求，是分发到客户端本地做渲染，还是在服务器统一渲染？

相信大家已经能明白个中的差别。

传输效率

如果后端只提供数据接口，可以非常有效地减少网络传输量。

过去：

<p class="tit xxx">

    <a href="/123">标题</a>

</p>

现在：

{id:123,title:"标题"} 

以上只是一个例子，实际情况中渲染后的内容会比这个更多。

04

前后分离的缺点：首屏体验

前面我们讨论了前后分离的几个优势，这里我们来说一下前后分离的一个缺点：

如果说前后分离还有一个缺点的话，那就是首屏体验。

那么如果浏览器复杂渲染，服务器负责给数据，必然会引起一个问题：

网络不佳的情况下, 会出现白屏

原因就是页面准备好了，而数据未准备好，又或者因为其他外部资源未就绪，导致渲染迟迟未进行，用户只能看着白屏干等。

解决这个问题有两个思路

1.做一个加载中的动效盖过去

2.首屏交还给服务端渲染

很难受哪一种方案目前更受欢迎。

从观察的角度看，内容为主的站点会倾向首屏服务端渲染，而动效更多的站点更常见有一个加载中的动画，比如一些web游戏。

05

对于前后分离的小建议

考虑到前后分离的各种优势，以及其所带来的首屏体验问题，我有一些小建议送给各位：

1.选择一种合适的方案解决首屏体验问题；

2.首屏之后的网络交互使用前后分离。

既能提高服务器效能，又能提高前端体验，也节省了用户的流量。

更

多

精

彩

请猛戳右边二维码

长按关注

【FCC成都社区】