本文以 React、Vue 为例，介绍下支流的渲染模式以及在支流框架中如何实现上述的渲染模式。

前置常识介绍

看渲染模式之前咱们先看下几个支流框架所提供的相干能力，理解的可跳到下个章节。

挂载组件到 DOM 节点

这是支流框架最根本的能力，就是将组件渲染到指定的 DOM 节点上。在 React 中所应用的 API 是 render，在 Vue 中所应用的是 createApp 后的 mount。

水合

水合用来将组件渲染到已有的动态内容上，用于为动态页面复原其交互和动静能力。在 React 中所应用的 API 是 hydrate（React 18 前的版本） 和 createHydrate（React 18），在 Vue 中所应用的是 createSSRApp 后的 mount。

Vue 中的 API 语义稍显奇怪，因为应用 createSSRApp 的场景并不一定是 SSR。

输入渲染内容

支流框架除了能够将组件渲染到 DOM 节点上以外，还能将其要渲染的内容间接输入为如 HTML 字符串等模式。输入为字符串的 API 在 React 和 Vue 中所应用的 API 都叫做 renderToString。

_React 中还推出了很多其它的 API：如 renderToStaticMarkup、 renderToStaticNodeStream 等等。性能基本一致，不影响本文的内容所以此处不细说了。_上面的例子中仅以 renderToString 为例。

支流渲染模式

晓得了支流框架的这几种能力，咱们再来通过题目提到的几种支流渲染模式看下他们能用来组合出什么样的成果，

CSR - Client Side Rendering - 客户端渲染

CSR 就是咱们常见的 SPA 所应用的渲染形式，所有的支流框架都反对，或者说：只有是在客户端渲染过程中应用到了脚本都能够算作客户端渲染。

CSR 次要流程为：

  1. 浏览器加载页面
  2. 加载对应的脚本

  3. 脚本执行时向页面中渲染内容，此步骤个别蕴含两种形式：

    1. 向一个空节点中渲染内容，个别利用于纯正的 CSR 利用。这里应用的就是下面提到的挂载组件的性能。
    2. 向一个已有内容的节点中渲染内容，通常利用于 CSR 与其它渲染模式（SSR、SSG、ISR）联合的场景下

CSR 的应用场景定义也很简略，如果在客户端页面有动静需要或须要交互则必须应用。

SSR - Server Side Rendering - 服务端渲染

SSR 是另一个比拟常见的渲染模式，应用这种渲染模式能够从服务端间接返回要渲染的动态内容。

其常见流程为：

  1. 浏览器发动 HTTP 申请对应的页面
  2. 服务端接管到申请后筹备渲染页面所须要的数据
  3. 将所须要的数据传入须要渲染的页面组件中而后通过 renderToString 输入为动态内容
  4. 拼接页面模版、水合脚本等将生成的动态内容返回到浏览器，浏览器进行渲染
  5. 浏览器渲染内容，执行水合脚本复原页面交互和动静能力

纯正的 SSR 指代的接管到申请、输入动态内容、返回浏览器的模式。水合的相干局部是属于 CSR 的内容。

要留神水合并不是必须的，能够按需抉择。比方如果你的需要是要对不同的用户展现不同的页面，然而页面上并没有任何能够交互或动静的内容，那齐全能够疏忽水合的局部。

SSR 个别利用于以下场景：

  1. 出于首页关上速度、用户体验、SEO 等目标须要让用户更快的看到页面首屏内容
  2. 想要事后渲染的页面内容中存在动静的内容

SSG - Static Site Generation - 动态站点生成

SSG 当初也比拟常见，它所指代的是在构建阶段就将页面所须要的数据筹备好而后将须要的页面通过脚本构建为动态内容的模式。

其常见流程为：

  1. 在构建阶段构建脚本遍历所有须要动态构建的页面
  2. 获取渲染所须要的数据并通过 renderToString 输入为动态内容
  3. 将动态内容拼接页面模版和水合脚本等内容后保留到文件中
  4. 浏览器发动申请时从服务端返回动态页面（个别间接应用动态文件服务器即可）
  5. 浏览器渲染内容，执行水合脚本复原页面交互和动静能力

纯正的 SSG 指代的同样是不蕴含 CSR 局部的内容，即构建阶段生成动态页面并在申请时间接将动态页面返回的过程。水合过程同样不是必须的，视需要决定即可。

SSG 个别利用于以下场景：

  1. 出于首页关上速度、用户体验、SEO 等目标须要让用户更快的看到页面首屏内容
  2. 页面中根本都是动态内容，变动很少或变动的机会比拟固定

所以罕用于通过 CMS 生成内容、博客站点等动态内容较多的场景。

ISR - Incremental Static Regeneration - 增量动态再生

ISR 目前应用的不多，它算是 SSG 的一种增强版，指的是在 SSG 的根底上，服务端在收到页面申请时会对页面的时效性进行判断，如果认定生效则会对该页面进行增量构建的一种模式。

其常见的流程如下：

能够看出 ISR 在构建和客户端环节没有任何的变动，而是减少了 Server 端的逻辑：

  1. 在服务端收到对应页面申请时服务端会先返回以后内容而后对页面做生效验证
  2. 如果页面实现，服务端会对生效的页面进行后盾增量构建
  3. 当下次申请达到时如果新的页面曾经生成胜利则会返回新页面的内容，但在此之前还会持续应用旧页面的内容

当然上述的逻辑并不相对，先增量构建再返回也同样是 ISR，只是个别这样会影响到用户体验个别不举荐。

ISR 实用的场景是：

  1. 网站匹配 SSG 场景
  2. 但对页面有肯定的实时性要求

比如说天气预报页面，可能半小时更新一次即可，或者是新闻页面，在存在新数据时再进行增量构建也是一种解决方案。

如何抉择

在抉择渲染模式时咱们通过以下逻辑进行简略的判断：

  1. 客户端页面是否须要动静或交互能力，如果要则 CSR 为必选

  2. 如果页面有 SEO、首屏、性能等需要

    1. 如果页面中想要动态展现的内容对每次拜访都可能存在差别——比方每个用户看到的页面信息不同，则能够抉择 SSR

    2. 如果页面中动态展现的内容对每次拜访没有差异性即可抉择 SSG

      1. 如果页面中的动态内容变动较为频繁，则可抉择 ISR

其次还要留神 SSR 和 ISR 都须要服务端的反对，所以如果只有动态文件服务器那须要的改变就比拟大了。

最初

渲染模式其实远不止以上几种，很多场景下都能够进行相应的优化。以下是一些我能想到的场景：

  • 在录入或更新数据时通过 WebHook 等告诉构建零碎进行增量构建，算是 ISR 的一种变种
  • 在 SSR 场景下能够对动态组件和动静组件进行辨别，将动态组件应用 SSG 输入，而后将其拼接到页面中。

所以没有最好的只有最适宜的，按需抉择最适宜本人需要的渲染模式即可。

如果想要看 SSR、SSG、ISR 的具体实现请看我之前的文章。