服务器端渲染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