Frontend 当前前端的三种渲染方式

1. CSR （Client Side Rendering）

Rendering an app in a browser, generally using the DOM.

• React(Angular / Vue)

前后端分离带来了CSR， 同时带来了各种问题。

• SEO， CSR 首次加载的HTML 文档没有内容， 而目前多数Search Engine 主要识别的内容还是HTML，对JS文件内容识别比较弱。
• JS代码量 & 首屏高性能。因为CSR的加载一般需要3个HTTP生命周期：加载HTML文档 --> 加载JS文件 -->API请求数据 -->根据数据渲染页面。
  也就是浏览器爬虫进来后得到的是空页面，无法index网站的页面。因此CSR不适合电商网站，而更适用于管理后台的网站。

2. SSR （Server Side Rendering）

Server rendering generates the full HTML for a page on the server in response to navigation.
1). JSP,PHP,在服务端生成完整的HTML页面。用户是可以在下载JS，运行JS， 绑定事件完成之前就能看到页面。
2). API 请求发生在服务端，理论上优于HTTP Call。

浏览器Call UI Server准备HTML，向API要数据,与此同时准备渲染页面返回给browser. 发现有.css和.js，再向Static Host要.css和js，然后由UI动态生成页面返回给Browser.
提升的表现是FCP (First Contentful Page)= FMP (First Meaningful Page).
TTI (Time to Intertact)远优于CSR，并解决SEO问题。
单纯的从技术角度出发，SSR带来的首屏渲染提升是巨大的，因为SSR的加载一般只需要一个声明周期，但是整体上的提升并没有发生质的改变。
芮苒API的内部调用性能优于HTTP请求，但是这个请求一样是存在的。与此同时，我们增加了UI Server处理渲染逻辑。考虑UI Server 服务量增大的时候，performance 是否由于CSR？

3. SSG(Static Site Generators)

静态渲染的页面显然是缓存的究极形态。我们将生成HTML页面的工作放到编译时，而不是再请求时动态完成。为每个URL预先单独成HTML文件。

通过代码把数据库的数据结合，打包的时候，就已拿到数据。再CI上把HTML编译好，放到S3服务器。也就是是只要从S3拿到HTML,就已经是完整的页面。

总结：