使用 React 进行服务器端渲染

已发表: 2021-05-27

一点关于 React

React 是一个开源前端 JavaScript 库，由 Facebook 开发者社区创建和维护。 它用于构建用户界面或 UI 组件。

然而，这个定义对于新手来说可能并不完全理解。 我们有一篇完美的博客文章，它会引导您完成对 React 的简要说明，一直到非常详细的技术描述，您可以在此处找到。

网页之旅 | 从服务器到浏览器

要了解什么是服务器端渲染，首先要了解网页在屏幕上的显示方式，如下图所示：

ssr-with-react-webpage-server-to-browser
  1. 每当您输入网站的 URL 或单击该网站的链接时，您的浏览器都会向由 URL 标识的相应服务器发送对某些文件的请求。
  2. 服务器将一些文件（例如 HTML 和 JavaScript 文件等）发送到您的浏览器。
  3. 您的浏览器下载并“呈现”或处理这些文件，您可以查看您请求的网页并与之交互。

这是对网页旅程的过度简化，但对于解释完成此任务的不同子步骤和不同方式（包括服务器端渲染）来说，这是一个足够好的前言。

“正常”客户端渲染网页的旅程

深入研究上一节中提到的过程，我们有一种称为客户端渲染或 CSR 的技术，该技术已经使用了很长时间，可以在用户的​​屏幕上显示网站。 下图中对此进行了解释：

ssr-with-react-csr-网页渲染
  1. 在输入网站的 URL 或单击该网站的链接时，您的浏览器会向由 URL 标识的相应服务器发送对某些文件的请求。
  2. 服务器发送 HTML 文件，其中包含对其他资产（如图像文件、CSS 文件和 JavaScript 文件）的引用。
  3. 浏览器再次向服务器发送请求并下载所有文件，包括 HTML 文件中引用的 CSS 和 JavaScript 文件。
    1. 如果用户连接不良并且 JavaScript 文件很大，这可能是增加网站加载时间的一个因素。
  4. 一旦浏览器下载了这些文件，浏览器就会执行框架或库（例如 React）并解析 JavaScript 文件，这些文件负责使网页具有交互性。
    1. 从速度优化的角度来看，这一点取决于客户端机器，如果客户端是低功耗硬件，这可能会花费大量时间。
    2. 执行这些步骤时，用户仍会看到加载屏幕
  5. 网页最终完全加载，用户可以看到网页并与之交互。

正如上面提到的步骤很清楚，从用户的角度来看，他们只能在客户端机器下载和呈现所有必要的文件之后，在最后一步看到网站并与网站交互。

这可能会花费大量时间，因为它取决于客户端机器在执行框架和解析 JavaScript 文件时的性能。

服务器端渲染网页的历程

用一行来解释它，服务器端渲染或 SSR 是获取客户端 JavaScript 框架网站并将其呈现为服务器而不是客户端上的静态 HTML 和 CSS 的过程，就像 CSR 中的情况一样。

下面提到的是一个网页使用服务器端渲染和 React 所经历的旅程的图形表示：

ssr-with-react-ssr-webpage-rendering-with-react
  1. 在输入网站的 URL 或单击该网站的链接时，您的浏览器会向由 URL 标识的相应服务器发送对某些文件的请求。
  2. 服务器，而不是像在 CSR 中那样仅发送普通 HTML 文件，而是使用从react-dom/server导入的renderToString函数将应用程序呈现为字符串
    1. 然后将其注入 index.html 文件并发送到浏览器。
    2. 从功能上讲，这就是 SSR 的关键所在，因为这是服务器呈现页面的地方，而不是客户端机器。
  3. 浏览器呈现此 HTML 文件，从而在浏览器中填充视图。
    1. 然而，这还不是交互式的，但用户可以看到网页的最终视图。
  4. 浏览器再次向服务器发送请求并下载 HTML 文件中引用的所有文件，包括 JavaScript 文件。
  5. 一旦下载了所有脚本，React 组件就会再次呈现在客户端上。 然而，这一次，它补充了现有的视图，而不是覆盖它。
    1. “水合”视图意味着它将任何事件处理程序附加到呈现的 DOM（文档对象模型）元素，但保持呈现的 DOM 元素完整。 这样，DOM 元素的状态被保留，并且不会发生视图重置。
  6. 网页最终完全加载，用户现在可以与他们在第 3 步中看到的页面进行交互。

因此，从用户的角度来看，最大的视觉变化之一是网页很快变得“可见”，因为从浏览器的角度来看，呈现 HTML 并不是那么资源密集型。

这本身并不会使页面加载速度比非 SSR 应用程序更快，但它确实为用户提供了网页的视图，因为 JavaScript 文件在后台下载和解析，之后网页变为交互式。 这意味着 TTI，即交互时间（这是从用户请求网页到网页完全交互所需的时间）比网页可见所需的时间多一点在浏览器中。

因此，在 SSR 场景中，为了更快的首次渲染时间，您的 HTML 和 CSS 需要对用户有意义，并且 JavaScript 可以作为 HTML 和 CSS 的增强，因为它的加载是延迟的。

关于 SSR 与 React 的工作方式的一个常见误解是，在每次更改之后，例如用户请求任何新数据，服务器再次完成所有步骤并将带有新 UI 的 HTML 文件发送到浏览器，但事实并非如此. 只完成了对页面的部分更新。 尽管渲染是由服务器完成的，但最终的输出通过“水合”它被插入到 DOM 中，如前所述。

ssr-with-react-pros-cons-of-ssr

服务器端渲染 | 何时以及何时不使用

  • 如果您需要强大的 SEO，请选择 SSR，因为它更容易让搜索引擎抓取。
  • 对于注重内容而不注重交互的网站，例如博客、新闻网站、静态网站和文本繁重的网站，SSR 可能是一个福音，因为它会加载您网站的关键，即内容超快。
  • 在服务器端渲染和生成要发送到浏览器的文件需要时间和精力。 因此，如果您的服务器和运营预算较低，最好不要实施 SSR，因为会有很多请求发送到您的服务器。
    • 但是，有了 Firebase 等提供商，我们可以通过云功能动态生成内容，服务器可以将其存储在 CDN 缓存中
    • 这将做的是，下次当用户请求时，服务器不会再次生成文件。 相反，它只是从本地 CDN 边缘提供服务，从用户的角度来看缩短了加载时间，同时还使用了更少的服务器资源。

React 对 SSR 有什么好处？

React 是实现 SSR 的绝佳选择，因为它结合了虚拟 DOM（文档对象模型）的概念。

这使开发人员能够创建 React 应用程序的虚拟版本，并将其安装在服务器本身中。

这使得使用前面讨论的 renderToString 函数更容易将其呈现为 HTML，将其发送到浏览器，以便浏览器可以非常快速地呈现它并在客户端计算机上创建虚拟版本。

因此，考虑到这个虚拟版本与我们从服务器发出的 HTML 相匹配的事实，React 不会重新渲染它，从而减少了交互时间 (TTI)，从而“更快”地加载网页。

SSR，一整天，每一天！

我们希望有一个万能的解决方案，但情况远非如此，尤其是在新技术的情况下。 尽管 SSR 有很多好处，但如前所述，在某些情况下，SSR 可能不是一个好的选择； 高度互动的网站处于领先地位。

这就是 Creole Studios 的用武之地。我们拥有众多技术专家，他们始终与科技界出现的几乎每一项新技术保持同步。 我们将了解您的业务需求并为您提供定制的解决方案，无论是 SSR 还是 CSR 应用程序，请放心，在我们为您完成繁重工作的同时，您无需担心任何事情。 联系我们，将您的想法从您的脑海中转化为应用程序！