背景

周末在网上冲浪，看到个音讯：NextJS 9.3 将动态站点生成性能引入了NextJS平台。

动态站点生成, 也就是所谓的 SSG : Static Site Generation。

喝了口水，顺便回顾了下当初的几种渲染模式：

SSR (Server Side Rendering)
SSG (Static Site Generation)
SSR With hydration
CSR with Pre-rendering
CSR (Client Side Rendering)
Trisomorphic Rendering

都不是什么陈腐玩意，就总结温习一下，顺便分享给大家，心愿能给各位带来一些启发。

注释

1. SSR (Server Side Rendering)

SSR，服务端渲染。

服务器出现响应于导航为服务器上的页面生成残缺的HTML。这样能够防止在客户端进行数据获取和模板化的其余往返过程，因为它是在浏览器取得响应之前进行解决的。

服务器渲染通常会产生疾速的 First Paint （FP）和 First Contentful Paint （FCP）。

在服务器上运行页面逻辑和出现能够防止向客户端发送大量JavaScript，这有助于实现疾速的交互工夫（TTI）。

这是有情理的，因为应用服务器渲染，实际上只是将文本和链接发送到用户的浏览器。

这种办法能够在很大范畴的设施和网络条件下很好地工作，并且能够带来乏味的浏览器优化，例如流文档解析。

流程：

浏览器 --> 服务器 --> 服务器执行渲染 --> index.html(实时渲染的内容)) --> Render --> bundle.js + images --> Render

长处

内容立刻可用 -因为将HTML发送给客户端，所以简直会立刻看到页面内容。
无需获取其余客户端 -现实状况下，服务器出现过程将进行所有必须的调用以获取数据，因而不会从客户端进行任何其余服务调用。
非常适合SEO

毛病

服务器上的速度较慢 -须要渲染两次页面：一次在服务器上，一次在客户端上。共事也可能正在从服务器进行服务调用以出现页面，所有这些都须要工夫，因而可能会提早HTML向客户端的初始发送。
与某些UI库不兼容 -如果你用的某些库应用了window，那你就要想方法来解决了。因为 Node 中没有window 或者 document。

2. SSG (Static Site Generation)

SSG：动态网站生成。

动态网站生成相似于服务器端渲染，不同之处在于您在构建时而不是在申请时渲染页面。

与服务器渲染不同，因为不用动静生成页面的HTML，因而它还能够实现始终如一的疾速到第一字节的工夫。

通常，动态出现意味着提前为每个URL生成独自的HTML文件。

借助事后生成的HTML响应，能够将动态渲染器部署到多个CDN，以利用边缘缓存的劣势。

长处

内容立刻可用 -因为将HTML发送给客户端，所以简直会立刻看到页面内容。
无需获取其余客户端 -现实状况下，服务器出现过程将进行所有必须的调用以获取数据，因而不会从客户端进行任何其余服务调用。
非常适合SEO
快-动态内容的出现速度速度十分快。
没有服务器 -不用运行服务器。

毛病

大型站点可能会很慢 -如果路由很多，速度可能会变慢。
与某些UI库不兼容 -如果你用的某些库应用了window，那你就要想方法来解决了。因为 Node 中没有window 或者 document。

3. SSR With hydration

hydration, 直译为水合。

让人一脸懵逼。

简略点讲，将性能放回到曾经在服务器端中出现的HTML中的整个过程，称为水合。

换句话说就是，对已经渲染过的HTML进行从新渲染的过程称为水合。

此办法试图通过同时进行客户端渲染和服务器渲染，达到一种均衡。

导航申请（例如整页加载或从新加载）由服务器解决，该服务器将应用程序出现为HTML，而后将JavaScript和用于出现的数据嵌入到生成的文档中。

现实状态下，就能够像服务器渲染一样实现疾速的First Contentful Paint，而后通过应用称为（re）hydration的技术在客户端上再次渲染来修补 。

这是一个新鲜的解决方案，然而它也可能具备一些相当大的性能缺点。

带水合的SSR的次要毛病是:

即便改良了First Paint，它也可能对可交互工夫产生重大负面影响。

SSR的页面通常看起来具备欺骗性，并且具备交互性，然而在执行客户端JS并附加事件处理程序之前，实际上无奈响应输出。

在挪动设施上可能要花费几秒钟甚至几分钟。

原理示意：

与JS导致的提早互动相比，这个模型造成的问题可能会更加重大：

服务器响应导航申请返回了应用程序UI的数据形容。同时，但它还返回了用于组成该UI的源数据以及该UI的实现的残缺脚本，该脚本随后在客户端启动。

仅在bundle.js实现加载和执行后，该UI才会变为可交互。

举个例子：

蓝色局部蕴含了初始的3个checkbox, 以及须要加载的bundle.js,

一开始，你会立刻看到UI，等bundle加载并执行实现之后，页面才会更新，进入可交互状态。

从实在网站中收集的成果指标表明，应用SSR水合模式成果并不好，强烈建议不要应用它。

起因归结为用户体验：最终很容易使用户陷入怪异的山谷。

4. CSR with Pre-rendering

Pre-render 原理是：在构建阶段就将html页面渲染结束，不会进行二次渲染。

也就是说，当初打包时页面是怎么样，那么预渲染就是什么样。

等到JS下载并实现执行，如果页面上有数据更新，那么页面会再次渲染。这时会造成一种数据提早的错觉。

Pre-render 利用 Chrome 官网出品的 Puppeteer 工具，对页面进行爬取。

它提供了一系列的 API, 能够在无 UI 的状况下调用 Chrome 的性能, 实用于爬虫、自动化解决等各种场景。

它很弱小，所以很简略就能将运行时的 HTML 打包到文件中。

原理是：在 Webpack 构建阶段的最初，在本地启动一个 Puppeteer 的服务，拜访配置了预渲染的路由，而后将 Puppeteer 中渲染的页面输入到 HTML 文件中，并建设路由对应的目录。

以此，达到预渲染的目标。

流程：浏览器 --> 服务器 --> index.html(预渲染的内容) --> Render --> bundle.js + images --> Render

5. CSR (Client Side Rendering)

CSR, 顾名思义，客户端渲染。

客户端渲染，意味着: 间接应用JavaScript在浏览器中渲染页面。

所有逻辑，数据获取，模板和路由均在客户端而不是服务器上解决。

CSR 示意图：

流程：浏览器 --> 服务器 --> index.html(白屏) --> bundle.js --> images --> Render

长处

在服务器上疾速 -因为仅出现空白页，所以出现速度十分快。
反对动态 -空白页能够通过S3之类的服务动态生成和提供，从而使速度更快。
反对单页应用程序 -客户端渲染是惟一反对单页应用程序或SPA的模型。
老本绝对较低 - CSR 绝对于SSR/SSG，更容易开发/保护。

毛病

没有初始渲染 -如果利用很大，或者客户的连贯速度很慢，加载工夫过长，用户体验就不太好。

6. 三态渲染

如果你能够联合Service-Worker, 则三态渲染模式也可能派上用场。

在三态渲染模型中，能够应用服务器流式渲染进行初始导航，而后让service worker 在 html加载实现后，持续进行导航html的渲染。

这样能够使缓存的组件和模板放弃最新状态，并启用SPA款式的导航，以在同一会话中出现新视图。

如果能够在服务器，客户端页面和service worker之间共享雷同的模板和路由代码时，这种办法非常无效。

三态渲染模型：

7. 服务端渲染 VS 客户端渲染

服务器渲染会为每个URL按需生成HTML，比仅提供动态渲染内容要慢。

同时，也有一些优化空间：服务器渲染+ HTML缓存能够大大减少服务器渲染工夫。

服务器渲染的劣势在于：与动态渲染相比，它可能提取更多"实时"数据并响应更残缺的申请集。

总结

从 SSR -> CSR，以及两头不同的渲染模式，都在图里：

本文中介绍的6种渲染模式，至于如何抉择，这里也给出一些不成熟的倡议：

对seo要求不高，同时对操作需要比拟多的我的项目，比方一些治理后盾零碎，倡议应用 CSR。因为只有在执行完bundle之后，页面能力交互，单纯能看到元素，却不能交互，意义不大，而且SSR 会带来额定的开发和保护老本。
如果页面无数据，或者是纯动态页面，倡议应用pre-render。因为这是一种通过预览打包的形式构建页面，也不会减少服务器累赘。
对seo和加载速度有比拟大需要的，同时页面数据申请多的状况，倡议应用 SSR。

结尾

好了，天都黑了，大略就是这么多。

满腹经纶，如有谬误，欢送留言斧正。

周末在钻研 Reciol.js, 感觉挺有意思，前面大略会出一篇剖析的文章，敬请期待哦。

参考资料

https://umijs.org/zh-CN/docs/...
https://juejin.im/post/684490...
https://juejin.im/post/684490...