前后分离真的可以提高效率吗?
Q:传统的服务端渲染静态HTML返回,与现在流行的前后端分离相比,谁的效率更高?
提问者:AkagiInc
0x00 当我在说效率的时候, 我们在说什么?
既然我们说到效率, 今天就一次过满足你两个愿望.
- 开发效率
- 运行效率
讨论前后分离带来的效率变化, 为了更好地在团队里推(qiang)行(zhi)前后分离,
就需要从这两个角度去说服(dui)开发人员.
0x01 开发效率
我们先假设一种理想情况
1.前期的需求设计接口定义已经非常完善.
2.前后端对分离后的技术手段都已经非常熟练
在这个大背景下, 跟过去同样的工作量(假设工作量本质上是相同的),
那么 前后分离 可以让任务更加多地并行开发, 无疑这个时候开发效率是能得到显著的提高的. 同时, 前后分离可以让一套系统的不同部分可以分别迭代, 分别进化, 这对于敏捷开发要求的小步快跑,快速迭代是有与生俱来的好感的, 这无疑是不断优化系统的路上的强大推力.
但现实中的情况却不是这样.
通常来说团队更习惯于过去已经掌握的技巧, 前端写完静态页面, 再由后端套模板引擎标签, 最后一体化发布.
他们已经在这个体系下非常熟练地开发各种项目, 如果强行推行新的技术手段, 显然在当下是会牺牲掉一些开发效率.
那么结论到底是如何?
来自个人的一些见解:
着眼于长远考虑, 前后分离可以让开发效率有很大的提升, 并且开发质量也会因为更多的专业化,工程化而得到前所未有的提高.
2016年是前端工程化重要的一年,相信没有人会质疑工程化带来的优势.
回顾前文阐述的一种理想情况, 也并不是遥不可及, 想要蜕变就要付出阶段性代价. 争取早日达到"理想情况"才是一个技术团队的终极追求.
所以, 从开发效率的角度来考虑, 建议早日走上前后分离的道路.
0x02 运行效率
我们把 计算效率 和 传输效率 都归到这个环节里来讨论.
对于老一套的方法, 所有页面看到的都要通过后端程序根据模板渲染出一个html文档.
所谓的渲染, 就是字符串的查找,替换,拼接.
这种操作是非常消耗计算资源的, 那么同样的千万次请求, 是分发到客户端本地做渲染, 还是在服务器统一渲染, 相信大家已经能明白个中的差别.
同时, 后端只提供数据接口, 可以非常有效地减少网络传输量
过去: ----( <p class="tit xxx"><a href="/123">标题</a></p> ) --->
现在: ----( {id:123,title:"标题"} ) ---->
以上只是一个例子, 实际情况中渲染后的内容会比这个更多.
如果说前后分离还有一个缺点的话, 那就是首屏体验
所谓的首屏, 就是用户访问网站地址后, 不做任何操作的情况下看到的第一个界面的样子.
那么如果浏览器复杂渲染, 服务器负责给数据, 必然会引起一个问题:
网络不佳的情况下, 会出现白屏.
原因就是页面准备好了, 而数据未准备好, 又或者因为其他外部资源未就绪, 导致渲染迟迟未进行, 用户只能看着白屏干等.
这必然会让用户很不爽啊.
解决这个问题有两个思路
- 做一个加载中的动效盖过去
- 首屏交还给服务端渲染
很难受哪一种方案目前更受欢迎, 从观察的角度看, 内容为主的站点会倾向首屏服务端渲染, 而动效更多的站点更常见有一个加载中的动画, 比如一些web游戏.
所以, 来自个人一点见解:
选择一种合适的方案解决首屏体验问题
首屏之后的网络交互使用前后分离, 既能提高服务器效能, 又能提高前端体验, 也节省了用户的流量.