后端渲染（旧服务器端渲染）
多年前，Web是一群由HTML和CSS构建的静态页面，没有太多的交互性。每个用户行为要求服务器来创建和提供一个完整的页面。后端接收前端发来的请求来渲染HTML的情况下，浏览器会直接接收到经过服务器计算之后的呈现给用户的最终的HTML字符串（post数据 + php/java = 静态html），这里的计算就是服务器经过解析存放在服务器端的模板文件来完成的，在这种情况下，浏览器只进行了HTML的解析，以及通过操作系统提供的操纵显示器显示内容的系统调用在显示器上把HTML所代表的图像显示给用户。
-
好处：前端耗时少（前端只负责将html进行展示），利于SEO
-
坏处：网络传输数据量大，占用服务器运算资源，response 出的数据量会大。
前端渲染（客户端渲染）
前端渲染的方式起源于JavaScript的兴起，ajax的大热更是让前端渲染更加成熟，前端渲染真正意义上的实现了前后端分离，前端只专注于UI的开发，后端只专注于逻辑的开发，前后端交互只通过约定好的API来交互，后端提供json数据，前端循环json生成DOM插入到页面中去。
好处：网络传输数据量小（减少了服务器压力）
坏处：首屏加载慢，不利于SEO
解决方式：
- SEO：SSR
- 首屏加载慢：交互优化（加载动画）
其实前后端的渲染本质是一样的，都是字符串的拼接，将数据渲染进一些固定格式的html代码中形成最终的html展示在用户页面上。 因为字符串的拼接必然会损耗一些性能资源。 所以：
-
如果在服务器端渲染，那么消耗的就是server端的性能。所以用户量达到一定程度后，后端会考虑缓存部分数据，避免消耗过多资源重复渲染一些对及时性要求并不高的地方以节约资源。例如常见的排行榜，可以将渲染后的模块缓存起来，十分钟更新一次。
-
如果是在客户端渲染，常见的手段，比如是直接生成DOM插入到html 中，或者是使用一些前端的模板引擎等。他们初次渲染的原理大多是将原html中的模板语法（{{xxx}}）替换。浏览器端初次渲染的性能消耗都是可以接受的。浏览器端渲染的难点在于数据变更后，页面响应式变更时如何节省资源？因为使用DOM直接读写的速度很慢，且易触发重绘，在复杂的SPA下直接读写DOM带来的影响会很明显。但是合理使用框架也可以在一定程度上提高SPA渲染的性能，React、Vue来举例子，在数据变更后，他会帮你diff，没有改变可以复用的部分是不会重新渲染一遍的。
服务器渲染SSR
待...
