早期SSR
SSR，即Server Side Rendering。翻译过来的意思就是服务端渲染
早期指的是前后端不分离的开发模式,即前端代码写完后嵌入到后端的JSP/PHP中，由后端服务渲染完数据后直接返回一个完整的HTML页面，里面的数据都已经渲染好了。
SSR优点
SSR的首屏加载速度
SSR缺点
- 服务器压力大
- 前后端代码在一起，不利于后期维护
CSR
与
SSR相对的叫做CSR，即Client Side Rendering。翻译过来的意思就是客户端渲染，现在的开发模式，大多数都是CSR
为什么要有CSR
早期SSR模式下，几乎都是静态内容，即不用编写太多的JavaScript，仅用HTML+CSS编写页面，然后扔给后端开发人员就可以。而现在的页面需要大量的交互，它们都需要编写JavaScript来完成，而且整个前端项目也比以前要复杂的多，文件量和代码量都远远超过了早期。如果还是用早期的SSR模式，服务器压力会很大。
CSR的运行模式
CSR典型的代表是SPA，即单页应用Single Page Application。如今Vue/React都是这种类型的框架。
客户端通过访问域名，向前端服务器请求静态资源（HTML/CSS/JS），向后端服务器请求数据。
CSR模式下，因为前后端的分离，多了一个数据交互的步骤，前端需要通过Ajax/fetch向后端发送请求才能得到数据，然后再将数据渲染到页面上。
原理示意图如下：
既然是这样，那么我们在上面图片的步骤3得到的HTML就很有可能没有完全“渲染”出来。因为，浏览器收到html时候进行解析，解析到js的请求代码时候才会去访问后端服务器，详情参考# 输入url后浏览器做了什么，经过步骤5之后，才可能得到完整的渲染好的页面。这样的缺点是明显的，不利于爬虫抓取或者搜索引擎优化(Additional Search Optimization,简称 SEO)，首屏加载速度也更慢
CSR缺点
- 不利于爬虫抓取或者搜索引擎优化(Additional Search Optimization,简称 SEO)
- 首屏加载速度更慢
CSR优点
- 因为前端的静态资源与后端是分开的，可以对静态资源进行CDN缓存，提高页面的加载速度。
- 将渲染的资源消耗由服务端转为客户端的浏览器承担，减轻服务端的压力，后端可以专注于业务逻辑的处理。
- 局部刷新，这也是Ajax/fetch带来的好处，通过异步获取数据，修改HTML可以实现页面的局部刷新。
现在前端的SSR
由于SSR的首屏加载速度等优点。我们仍然需要它，因为直接返回渲染好的HTML在某些场景下很有用。
但是我们又不想回到过去那种古老的方式，于是，专属于前端的SSR诞生了。是的，前端也可以单独做SSR
原理示意图如下：
你可能听过Nuxt.js/Next.js等框架，它们都专注于基于流行的前端框架（Vue/React）做SSR。
可以看到，Front End Server接管了浏览器的初始渲染工作，所以浏览器可以直接得到渲染好的HTML。
这种方式，结合了早期的SSR的优点，又保留了SPA的优点。
现在前端的SSR缺点
前端的SSR需要在服务器上跑NodeJs，所以，我们需要一个NodeJs的服务器。这就意味着如果你想要使用SSR，你需要自己搭建一个NodeJs服务器。不能使用一些第三方的CDN服务托管你的前端资源
SSG
为什么我们需要从后端获取数据？
因为数据是动态的
那假如我们的数据是不变的呢？（个人博客等）
是不是就不需要从后端获取数据了？是不是可以把数据直接写入到HTML中？
SSG就这么诞生了，根据已有的SPA，在本地打包的时候，计算生成HTML页面，然后可以直接部署
原理示意图如下：
