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游戏.

所以, 来自个人一点见解:

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

首屏之后的网络交互使用前后分离, 既能提高服务器效能, 又能提高前端体验, 也节省了用户的流量.