介绍
如今，可以通过多种方式在 Web 上呈现内容。
如何以及在何处获取和呈现内容的决定是应用程序性能的关键。
可用的框架和库可用于实现不同的渲染模式，如客户端渲染、静态渲染、水化、渐进式渲染和服务器端渲染。
在我们决定哪种模式最适合我们的应用程序之前，了解每种模式的含义很重要。
Chrome 团队鼓励开发人员考虑静态渲染或服务器端渲染，而不是完全重新水化的方法。
随着时间的推移，默认情况下的渐进式加载和渲染技术可能有助于在使用现代框架时在性能和功能交付之间取得良好的平衡
以下部分将提供有关衡量应用程序在 Web 渲染方面的性能要求的指南，并建议最能满足这些要求的模式。
随后，我们将深入探讨每种模式并了解如何实施。
我们还将讨论可用于实现这些模式的 Next.js。
然而，在我们进入可用的模式或 Next.js 之前，让我们先看看我们是如何到达这里的，以及导致 React 框架和 Next.js 创建的驱动因素是什么。
Web 渲染简史
Web 技术一直在不断发展以支持不断变化的应用程序需求。
所有网站的构建块 HTML、CSS 和 JavaScript 也随着时间的推移而发展，以支持不断变化的需求并利用浏览器的进步。
在 2000 年代初期，我们有一些网站，其中 HTML 内容完全由服务器呈现。
开发人员依靠服务器端脚本语言（如 PHP 和 ASP）来呈现 HTML。
所有关键导航都需要重新加载页面，并且客户端最多使用 JavaScript 来隐藏/显示或启用/禁用 HTML 元素。
2006 年，Ajax 引入了单页应用程序 (SPA) 的可能性，Gmail 是最流行的例子。
Ajax 允许开发人员在不加载新页面的情况下向服务器发出动态请求。
因此，可以将 SPA 构建为类似于桌面应用程序。
很快，开发人员开始使用 JavaScript 来获取和呈现数据。创建了可用于在 MVC 框架中构建视图层功能的 JavaScript 库和框架。
JQuery、Backbone.js 和 AngularJS 等客户端框架使开发人员可以更轻松地使用 JavaScript 构建核心功能。
React 于 2013 年推出，作为构建用户界面和 UI 组件的灵活框架，并为开发单页 Web 和移动应用程序提供了基础。
从 2015 年到 2020 年，React 生态系统已经发展到包括支持数据流架构库（Redux）、CSS 框架（React-Bootstrap）、路由库和移动应用程序框架（React Native）。
但是，纯客户端渲染框架存在一些缺点。因此，开发人员开始探索新的方法来充分利用客户端和服务器端渲染世界。
渲染 - 关键性能指标
在讨论缺点之前，让我们了解如何衡量渲染机制的性能。
对以下术语的基本理解将有助于我们比较此处讨论的不同模式。
| 关键词 | 描述 |
|---|---|
| TTFB | Time to First Byte - 单击链接和第一个内容进入之间的时间 |
| FP | First Paint - 第一次绘制 - 用户第一次看到任何内容或在屏幕上绘制前几个像素的时间 |
| FCP | First Contentful Paint - 所有请求的内容变为可见的时间 |
| LCP | Largest Contentful Paint - 最大的内容绘制 - 主页内容变得可见的时间。 这是指在视口内可见的最大图像或文本块 |
| TTI | 可交互时间 - 页面变为可交互的时间，例如，事件已连接等 |
| TBT | 总阻塞时间 - FCP 和 TTI 之间的总时间量 |
关于这些性能参数的一些重要说明如下。
-
大型 JavaScript 包可能会增加页面到达 FCP 和 LCP 所需的时间。 用户将需要等待一段时间才能从大部分空白页面转到加载了内容的页面。
-
较大的 JavaScript 包也会影响 TTI 和 TBT，因为只有在加载了最少的 JavaScript 并连接了事件后，页面才能变得可交互。
-
内容的第一个字节到达浏览器 (TTFB) 所需的时间取决于服务器处理请求所用的时间。
-
preload、prefetch 和 script 属性等技术会影响上述参数，因为不同的浏览器对它们的解释不同。 在使用这些属性之前，了解浏览器为这些属性分配的加载和执行优先级会很有帮助。
我们现在可以使用这些参数来了解每种模式在渲染要求方面必须提供什么。
模式 - 快速浏览
客户端渲染 (CSR) 和服务器端渲染 (SSR) 形成了可用于渲染的选择范围的两个极端。
下图中列出的其他模式使用不同的方法来提供从 CSR 和 SSR 借用的某些功能组合。
杰森·米勒插图
我们将详细探讨这些模式中的每一个。
然而，在此之前，让我们谈谈 Next.js，它是一个基于 React 的框架。
Next.js 与我们的讨论相关，因为它可用于实现以下所有模式。
- SSR
- Static SSR (实验标志)
- SSR with Rehydration
带补水的 SSR - CSR with Prerendering also known as Automatic Static Optimization
带有预渲染的 CSR 也称为自动静态优化 - Full CSR
结论
我们现在已经介绍了四种本质上是 SSR 变体的模式。
这些变化使用技术组合来降低一个或多个性能参数，
如 TTFB（静态和增量静态生成）、TTI（渐进式水化）和 FCP/FP（流媒体）。
这些模式建立在现有的客户端框架（如 React）之上，并允许进行某种补充以实现 CSR 的交互级别。
因此，我们有多种选择来实现结合 SSR 和 CSR 利益的最大化。
概括
根据应用程序的类型或页面类型，某些模式可能比其他模式更合适。
下图重新审视、总结和比较了我们在前几节中讨论的每个模式的亮点，并为每个模式提供了用例。
知识点
- TTFB
- FP
- FCP
- LCP
- TTI
- TBT
- ajax
- next.js
- SSR
- Static SSR
- SSR with hydration
- CSR
- Full CSR