这是我参与8月更文挑战的第11天，活动详情查看：8月更文挑战
名词解释
SSR
- SSR：服务器端渲染-将客户端或通用应用程序渲染到服务器上的HTML。
CSR
- CSR：客户端渲染-通常使用DOM在浏览器中渲染应用程序。
Rehydration
- Rehydration： “启动”客户端上的JavaScript视图，以便它们重用服务器渲染的HTML的DOM树和数据。
Prerendering
- Prerendering：在构建时运行客户端应用程序以将其初始状态捕获为静态HTML。
TTFB
- TTFB： 到第一个字节的时间-视为单击链接到输入内容的第一位之间的时间。
FP
- FP： First Paint-第一次获取任何像素对用户可见。
FCP
- FCP： 第一个内容丰富的油漆-所请求的内容（文章主体等）可见的时间。
TTI
- TTI： 互动时间-页面互动的时间（事件连线等）。
前端渲染介绍
CSR客户端渲染
今天介绍的是服务端渲染（Server-side Rendering）,简称为SSR。
首先介绍一下常见的web渲染模式，第一个是目前前后端分离的主要开发模式，也是大多数前端同学的开发方式，就是客户端渲染（Client-side Rendering）。目前的三大框架Angular,React,Vue都是基于CSR开发的框架，我们在开发时只需要和后端同学，提前约定好接口，接着前端页面由我们前端同学开发构建，在需要页面刷新的地方，可以使用Ajax技术进行局部刷新。
CSR (Client-Side Rendering) – rendering an app in a browser, generally using the DOM.
上图是Google大会上贴出的介绍CSR的一张原理图，net代表网络请求，请求js文件“bundle.js”,此时是FCP时间点，
FCP：First Contentful Paint - the time when requested content (article body, etc) becomes visible.
翻译过来就是：第一个内容丰富的渲染-所请求的内容（文章主体等）可见的时间。接下来由我们的js引擎以及浏览器渲染引擎渲染更多的页面内容。渲染完毕后又到了一个时间点：TTI。
TTI: Time To Interactive - the time at which a page becomes interactive (events wired up, etc)
翻译过来就是："互动时间-页面互动的时间（事件被整理等",也就是用户第一次可以与页面交互的时间点。而从FCP到TTI需要花费的时间则是由我们前端打包的js文件大小决定。这其中包含了我们的业务代码，同时又有第三方库的部分代码。对于性能较差的机器，也就花费时间更长。在google大会上提到的有利用HTTP/2 Server Push或者<link rel=preload>加载数据，可以提升性能，而在我们前端开发中还可以使用懒加载，webpack的treeshaking等等减少js文件大小来减少渲染时长。同时由于目前的前端框架大多开发的是单页面应用SPA（single page Application）,如果js文件较大，则首屏加载会变慢，影响用户体验。让我换个思路，改变渲染模式，想想会有什么效果。
SSR服务端渲染
服务器呈现响应于导航生成服务器上页面的完整HTML。这样可以避免客户端进行数据获取和模板化的其他往返过程，因为它是在浏览器获得响应之前进行处理的。服务器渲染通常会产生快速的First Paint （FP）和First Contentful Paint （FCP）。在服务器上运行页面逻辑和呈现可以避免向客户端发送大量JavaScript，这有助于实现快速的交互时间 （TTI）。这是有道理的，因为使用服务器渲染，您实际上只是将文本和链接发送到用户的浏览器。这种方法可以在很大范围的设备和网络条件下很好地工作，并且可以带来有趣的浏览器优化，例如流文档解析。SSR渲染过程大致如下图所示：
通过服务器渲染，用户不太可能会等待CPU绑定的JavaScript处理才能使用您的网站。即使 无法避免使用第三方JS，使用服务器渲染来减少自己的第一方JS成本也可以为您提供更多的“预算”。但是，此方法有一个主要缺点：在服务器上生成页面会花费时间，这通常会导致首字节时间 （TTFB）变慢。
服务器渲染的动态特性可能会带来可观的计算开销。许多服务器渲染解决方案不会提早刷新，可能会延迟TTFB或将发送的数据加倍（例如，客户端JS使用的内联状态）。在React中，renderToString()可能很慢，因为它是同步的并且是单线程的。要使服务器呈现“正确”状态，可能涉及寻找或构建组件缓存解决方案，管理内存消耗，应用备忘录技术以及许多其他问题。通常，您要多次处理/重建同一应用程序-一次在客户端，一次在服务器。仅仅因为服务器渲染可以使某些事情更快地出现，并不意味着您要做的工作更少。
服务器渲染会为每个URL按需生成HTML，但比仅提供静态渲染内容要慢。如果您可以进行其他工作，则服务器渲染+ HTML缓存可以大大减少服务器渲染时间。服务器渲染的优势在于，与静态渲染相比，它能够提取更多的“实时”数据并响应更完整的请求集。需要个性化的页面是请求类型的一个具体示例，无法与静态渲染一起很好地工作。
