浅析前端渲染与服务端渲染

背景知识：

　　「后端渲染」指传统的 ASP、Java 或 PHP 的渲染机制；

　　「前端渲染」指使用 JS 来渲染页面大部分内容，代表是现在流行的 SPA 单页面应用；

　　「同构渲染」指前后端共用 JS，首次渲染时使用 Node.js 来直出 HTML。一般来说同构渲染是介于前后端中的共有部分。

　　客户端渲染路线：1. 请求一个html -> 2. 服务端返回一个html -> 3. 浏览器下载html里面的js/css文件 -> 4. 等待js文件下载完成 -> 5. 等待js加载并初始化完成 -> 6. js代码终于可以运行，由js代码向后端请求数据( ajax/fetch ) -> 7. 等待后端数据返回 -> 8. react-dom( 客户端 )从无到完整地，把数据渲染为响应页面

　　服务端渲染路线：2. 请求一个html -> 2. 服务端请求数据( 内网请求快 ) -> 3. 服务器初始渲染（服务端性能好，较快） -> 4. 服务端返回已经有正确内容的页面 -> 5. 客户端请求js/css文件 -> 6. 等待js文件下载完成 -> 7. 等待js加载并初始化完成 -> 8. react-dom( 客户端 )把剩下一部分渲染完成( 内容小，渲染快 )

　　说明：对同一个组件，服务端渲染“可视的”一部分( render/componentWillMount部分代码  )，为确保组件有完善的生命周期及事件处理，客户端需要再次渲染。即：服务端渲染，实际上也是需要客户端进行 再次地、但开销很小的二次渲染。

前端渲染的优势

• 局部刷新。无需每次都进行完整页面请求
• 懒加载。如在页面初始时只加载可视区域内的数据，滚动后rp加载其它数据，可以通过 react-lazyload 实现
• 富交互。使用 JS 实现各种酷炫效果
• 节约服务器成本。省电省钱，JS 支持 CDN 部署，且部署极其简单，只需要服务器支持静态文件即可
• 天生的关注分离设计。服务器来访问数据库提供接口，JS 只关注数据获取和展现
• JS 一次学习，到处使用。可以用来开发 Web、Serve、Mobile、Desktop 类型的应用

后端渲染的优势

• 服务端渲染不需要先下载一堆 js 和 css 后才能看到页面（首屏性能）
• SEO
• 服务端渲染不用关心浏览器兼容性问题（随意浏览器发展，这个优点逐渐消失）
• 对于电量不给力的手机或平板，减少在客户端的电量消耗很重要

以上服务端优势其实只有首屏性能和 SEO 两点比较突出。但现在这两点也慢慢变得微不足道了。React 这类支持同构的框架已经能解决这个问题，尤其是 Next.js 让同构开发变得非常容易。还有静态站点的渲染，但这类应用本身复杂度低，很多前端框架已经能完全囊括。

耗时对比：

　　时间耗时比较：

　　　　1. 数据请求：由服务端请求数据而不是客户端请求数据，这是“快”的一个主要原因。服务端在内网进行请求，数据响应速度快。客户端在不同网络环境进行数据请求，且外网http请求开销大，导致时间差（主要原因）。

　　　　2. 步骤：服务端是先请求数据然后渲染“可视”部分，而客户端是等待js代码下载、加载完成再请求数据、渲染。即：服务端渲染不用等待js代码下载完成再请求数据，并会返回一个已经有内容的页面。

　　　　3. 渲染性能：服务端性能比客户端高，渲染速度快( 猜测，该项数据不详 )。

　　　　4. 渲染内容：服务端渲染会把”可视“部分先渲染，然后交给客户端再作部分渲染。而客户端渲染，则是从无到有，需要经历完整的渲染步骤。

山外有山，看看别人这么说：

知乎大神这么说，

作者：徐飞 链接：https://www.zhihu.com/question/28207685/answer/39893889 来源：知乎

对于前后端分离，认识上有个误区，那就是很多人自称：我们老早就分离了，全AJAX，使用Angular或者什么什么就可以了。

这个说法是不合适的，打个比方，别人问的是“如何解决家禽把蛋生在水草边的问题？”，但实际上人家养的是鸭子，答题的却是养鸡的，所以回答“不让去水边就行了”，这显然不在点子上。

这两年业界说的前后端分离，是限于偏展示类的系统（用A代替），而不是应用、管控类Web项目（用B代替），在B类项目里，前后端是天然分离的，对此，除了少部分后端开发人员，基本所有人的认识都是一致的。上一段中这样回答的人一般都是只做B类项目，在B类项目里，前后端分离是共识，不需要讨论。

那么，剩下的问题就是讨论A类项目的前后端分离了。这个问题的核心在什么地方呢，在于模板的与数据结合的位置，以及，模板的控制权在谁手里。经过这两年的讨论，基本上我们可以达成的共识就是：模板应当由前端人员去控制，主要原因有两方面：

- 性能优化（尤其是外部资源的管理与发布，请求合并等等） - 协作的顺畅性（已形成模板的界面片段的返工等问题）

那么，模板到底应该在什么地方跟数据结合？

这个问题就比较折腾了，有部分人尝试像B类项目那样，使用js模板，然后在浏览器端执行，这是存在一些问题的，比如说seo不友好，首屏性能不够，尤其对于首页DOM量很大的电商类网站，差距很明显。

所以我们还是得把主要的模板放在服务端来执行。在这个过程中，阿里作了一些尝试，那就是引入Node层，在这一层把模板与数据进行合成，然后浏览器拿到的就是生成好的HTML了，但也不是所有HTML都是这么生成好的，还是会有一些内容等到了浏览器之后，再用js去加载和生成。

所以这一定会是一个混合方案，同一个系统中存在两种模板，一种在服务端执行，一种在浏览器中执行，互为补充。

至于说这个方案中，是否中间层一定要是node，我觉得无所谓，只要是能正常做web项目的东西都可以，这个还是要看所在企业的技术积累方向，当然node做这块是有一些优势的，比如对前端人员的语言友好性，前后端模板的通用性等等，但这些都是细节，重点还是整体方案和流程。

这时候回头看你问题中的这句：

> 前后端分离的意思是，前后端只通过 JSON 来交流，组件化、工程化不需要依赖后端去实现。

我相信你这里对前后端的限定是以浏览器为准的，但事实上，A类项目中，前后端的分界一定要延伸到服务器端的模板层，也就是在这一层里，把各种来源的数据整合到模板中，这个数据未必是JSON格式的，会存在有JSON，XML，特定的二进制等等。

组件化这个话题就更复杂了，在刚才组织形式中，很难说出究竟什么才是组件。是某个商品的模板吗？是数据吗？是数据和模板的结合体吗？没法回答。在此，我说一句自己的看法：像电商这种项目的前端部分，基本不存在组件的概念，甚至不存在组件化的价值，因为这里面可复用的东西太少了，也不易提取，大多数东西都是不带逻辑的界面模板。

最近因为ReactJS的流行，带来了一个Isomorphic的概念，这是一种很有意义的探索，但是否能解决这类问题，尚不得而知，根据我的理解，它对B类项目是较好的补充方案，但对A类项目暂时还缺乏可用性，因为A类项目中，运行期的DOM变更并不多，多是整片的改变，用这个方案去解决的话，有些牛刀杀鸡的感觉。

我的理解：

　　这里我补充一下，项目可以分为三类，a类是电商前台，b类就是电商后台，c类就是移动端项目，介于两者之间，有自己的特点。

　　对于交互性不强的页面，比如新闻，信息展示比较多的，服务器渲染优先，交互多的，比如QQ空间，建议浏览器渲染优先。所以不能为了前后端分离而前后端分离，要根据具体的业务场景来具体问题具体分析。

　　在浏览器端渲染时，如果数据量并不大，也没有什么大的改变，那么自己用原生的DOM API去操作绰绰有余了，即使有时候有些操作会浪费一些性能资源，影响也不会太大，反而引入了框架和库却只用了一部分功能是一种浪费。但是如果做一个复杂的页面应用，我还是建议使用Vue这类库/框架来完成。一方面来说，他们会把业务逻辑抽象，不用去关注渲染这些操作，可以提升开发效率；另一方面，恐怕大多数人自己实现渲染以及数据变更后的DOM变更未必会比库/框架做得好。

阅读上面内容发现，淘宝的解决方案我们是可以借鉴的，一句话就是利用node中间层。node拿需要的数据和html渲染好了，再送到浏览器，从而减少初始化页面时候带来的时间。

　　但是这种方案也并不完美， 　　一方面不是所有东西都可以通过模板渲染，也就存在一些在node渲染，一些通过js插入！跟传统方式一样，增加维护成本，降低体验 一方面，增加了node层也就增加了页面挂掉的风险，因为node服务也不能保证百分一百稳定。所以使用node层就又得考虑node服务不了用的兜底方案，比如读缓存服务器等 另一方面使用node层无疑是减轻了服务端的工作量，他们只操作提供数据提供接口！增加了前端的工作量，需要多维护node层。

解决方案：

　　一、前端和后端先行讨论对接，确定哪些是前端渲染哪些是后端渲染，确定字段，接口格式。

　　前端渲染的部分，又分为2种，

　　1、前端模板，vue、react去绑数据，实现方式为virtual Dom。

　　2、jq html append 接收json数据拼接后挂载到页面上，实现方式为拼字符串。

　　二、利用node中间层，这一块需要学习node方面知识，目前还不熟悉，下一步准备尝试一下。