浅谈服务端渲染(SSR) 与使用场景

什么是SSR(服务端渲染)MUA？

SSR是Server Side Render的缩写，简单来讲：服务端渲染 就是网页上面呈现的内容在服务器端就已经生成好了，当用户浏览网页时，服务器把这个在服务端生成好的完整的html结构内容响应给浏览器，而浏览器拿到这个完整的html结构内容后直接显示(渲染)在页面上的过程。

SSR(服务端渲染)是如何出现的？

其是 SSR服务端渲染 早就有了，或者是说，在CSR(客户端渲染) 没有出现之前，以前的Web网页都是服务端渲染，如：JSP，ASP，.NET，SMARTY等等是JAVA、C#、PHP等开发人员用的服务器渲染模板，所以之前传统的web开发方式基本都是服务端渲染。

为什么会出现CSR(客户端渲染)?

由于传统的SSR(服务端渲染)开发方式，在项目不断壮大、更新和迭代，各种各样复杂的业务需求和业务逻辑全部都由后台处理，用户体验、性能等自然就会下降，而且之前的Web开发是没有前端这个说法的，从项目需求分析、整体规化、数据库架设、各种逻辑处理、页面切图、编写样式、业务交互、兼容性处理等等，都是后端开发人员去完成的，再加上用户体验要求是越来越高，让后端开发为员力不从心。
由于局部刷新技术ajax的普及，在客户端可以用js发起网络请求来异步获取数据，而且在不刷新整个页面的情况下动态生成HTML，并以某种方式将数据组织成为页面或者页面的某部分，最终呈现出完整用户界面，这样的效率更高，性能也更好，可维护性也大大提高后来慢慢的出现了项目前后端分离，后端只负责提供数据API接口，前端只负责数据渲染和交互，前后端各自做自的活。

SSR(服务端渲染) 与 CSR(客户端渲染) 的利弊

SSR的优势：

• 有利于SEO:
  不同爬虫工作原理类似，只会爬取源码，不会执行网站的任何脚本（Google除外，据说Googlebot可以运行javaScript）。使用了React或者其它MVVM框架之后，页面大多数DOM元素都是在客户端根据js动态生成，可供爬虫抓取分析的内容大大减少(如图一)。另外，浏览器爬虫不会等待我们的数据完成之后再去抓取我们的页面数据。服务端渲染返回给客户端的是已经获取了异步数据并执行JavaScript脚本的最终HTML，网络爬中就可以抓取到完整页面的信息。

• 有利于首屏渲染
  首屏的渲染是node发送过来的html字符串，并不依赖于js文件了，这就会使用户更快的看到页面的内容。尤其是针对大型单页应用，打包后文件体积比较大，普通客户端渲染加载所有所需文件时间较长，首页就会有一个很长的白屏等待时间。

SSR的局限：

• 服务端压力较大
  本来是通过客户端完成渲染，现在统一到服务端node服务去做。尤其是高并发访问的情况，会大量占用服务端CPU资源；

• 开发条件受限
  在服务端渲染中，只会执行到componentDidMount之前的生命周期钩子，因此项目引用的第三方的库也不可用其它生命周期钩子，这对引用库的选择产生了很大的限制；

• 学习成本相对较高
  除了对webpack、React要熟悉，还需要掌握node、Koa2等相关技术。相对于客户端渲染，项目构建、部署过程更加复杂。

---

CSR的优势：

• 前后端分离，前端专注于 UI，服务端专注于逻辑。
• 可以实现局部刷新，无需每次都请求完整页面，用户体验好。
• 给服务器减负，部署简单。
• 交互性好，方便实现各种效果。

CSR的局限：

• 不利于SEO，爬虫难以爬取内容。
• 首屏渲染慢，渲染前需要加载一堆 js 和 css 文件。
• 客户端负担重。

SSR与CSR两者本质上的区别:

客户端渲染和服务器端渲染的最重要的区别就是究竟是谁来完成html文件的完整拼接，如果是在服务器端完成的，然后返回给客户端，就是服务器端渲染，而如果是前端做了更多的工作完成了html的拼接，则就是客户端渲染。

SSR(服务端渲染)的使用场景

个人认为，要根据项目应用场景而定，而不是一定要用SSR(服务端渲染) 或 一定要用CSR(客户端渲染)，就现在目前的前端开发而言，项目开发都是用的SPA(单页应用)框架居多，自然也是CSR用得多一点，所以如果项目很在乎在搜索引擎的排名等，可以考虑使用SSR，因为SSR最大的优势在于SEO与首屏加载速度快，当企业更在乎在搜索引擎的排名，使得用户尽可能看到与多访问自身网站时，可以考虑使用SSR；根绝业务需求来决定首屏加载速度的重要程度。