服务器端渲染SSR

什么是服务器端渲染

渲染：就是将数据和模版组装成html

后端渲染（服务器端渲染）

多年前，Web是一群由HTML和CSS构建的静态页面，没有太多的交互性。每一个用户行为要求服务器来建立和提供一个完整的页面。后端渲染HTML的状况下，浏览器会直接接收到通过服务器计算以后的呈现给用户的最终的HTML字符串，这里的计算就是服务器通过解析存放在服务器端的模板文件来完成的，在这种状况下，浏览器只进行了HTML的解析，以及经过操做系统提供的操纵显示器显示内容的系统调用在显示器上把HTML所表明的图像显示给用户。

        国企的网站所有是使用的后端渲染，也就是说，你点击一下，他就会刷新一个，而后从后台请求新的页面数据。

好处：前端耗时少（前端只负责将html进行展现），利于SEO

坏处：网络传输数据量大，占用（部分、少部分）服务器运算资源，response 出的数据量会（稍）大点，模板改了前端的交互和样式什么的同样得跟着联动修改

 

前端渲染（客户端渲染）

前端渲染的方式起源于JavaScript的兴起，ajax的大热更是让前端渲染更加成熟，前端渲染真正意义上的实现了先后端分离，前端只专一于UI的开发，后端只专一于逻辑的开发，先后端交互只经过约定好的API来交互，后端提供json数据，前端循环json生成DOM插入到页面中去。

好处：网络传输数据量小（减小了服务器压力）

坏处：前端耗时较多，不利于SEO

 

        其实先后端的渲染本质是同样的，都是字符串的拼接，将数据渲染进一些固定格式的html代码中造成最终的html展现在用户页面上。  由于字符串的拼接必然会损耗一些性能资源。 因此……

        若是在 服务器端渲染，那么消耗的就是server端的性能。因此用户量达到必定程度后，后端会考虑缓存部分数据，避免消耗过多资源重复渲染一些对及时性要求并不高的地方以节约资源。例如常见的排行榜，能够将渲染后的模块缓存起来，十分钟更新一次。

        若是是在客户端渲染，常见的手段，好比是直接生成DOM插入到html 中，或者是使用一些前端的模板引擎等。他们初次渲染的原理大可能是将原html中的数据标记（例如{{text}}）替换。通常来讲只要不做死无脑用了document.write，浏览器端初次渲染的性能消耗都是能够接受的。

浏览器端渲染的难点在于数据变动后，页面响应式变动时如何节省资源？要知道DOM直接读写的速度是很慢的，并且不当心还会触发重绘，在复杂的SPA下直接读写DOM带来的影响会很明显。拿React、Vue来举例子，在数据变动后，他会帮你diff，没有改变能够复用的部分是不会从新渲染一遍的。

 

SEO
browser端渲染是对搜索引擎不太友好的，虽然SPA怎么作SEO已经有过无数讨论和实践，可是browser端很大程度是不如server端渲染容易作SEO。

后端渲染html 叫 吐或者 喷，爬虫能够看到完整的呈现源码
前端模板渲染html叫 填，爬虫看不到完整的呈现源码

维护

server端渲染不少时候先后端是一块儿完成的。有的团队是前端开发人员直接写模板文件，可是也有的团队是前端写了静态html文件，后端改成模板。后一种团队在维护时是比较蛋疼的，改个css都要先后端在一块儿搞定（个人上一家公司就是这么作的）

 

如何选择

关于在server端仍是在browser端渲染的选择，更多的是要看业务场景。

 

例如一个注重SEO的新闻站点，非强交互的页面，作成SPA意义并不大，仍是建议server端渲染。
像后台管理页面，或者是QQ空间这类强交互的网页应用，能够尝试浏览器端渲染。后端开发人员也能更加专一于接口服务的提供，不用去考虑页面的渲染问题，分工合做更加愉快。

在浏览器端渲染时，若是数据量并不大，也没有什么大的改变，那么本身用原生的DOM API去操做绰绰有余了，即便有时候有些操做会浪费一些性能资源，影响也不会太大，反而引入了框架和库却只用了一部分功能是一种浪费。可是若是作一个复杂的页面应用，我仍是建议使用Vue这类库/框架来帮你完成。一方面来讲，他们会帮你把业务逻辑抽象，不让你去关注渲染这些操做，能够提高开发效率；另外一方面，恐怕大多数人本身实现渲染以及数据变动后的DOM变动未必会比库/框架作得好。若是他能作的更好，必定要请他为主流框架/库去提PR或者issues来帮助库/框架作的更好；或者激进点，他本身写一个框架造福你们吧。

 

既然已经走在前面，就不要频繁的日后看！

 

参考连接： 连接：https://www.zhihu.com/question/28725977/answer/116918471