随手笔记 3D建模的六种渲染方式(2)
2023-04-08 来源:文库网
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
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
