从 PreReact 到 React 和 Next.js Web 渲染和性能优化之旅

在本文中，我们将探讨 React 的起源、它解决了什么问题以及

为什么创建 Next.js。虽然众所周知 Next.js 提供 SSR（服务器端渲染），但我们将深入探讨 SSR 真正是什么 以及 为什么它可能比 CSR（客户端）侧面渲染）在某些情况下。

简史：React.js 之前

在React.js普及CSR（客户端渲染）概念之前，大多数应用程序都遵循传统的MPA（多页面应用程序）模型。在 MPA 中，服务器处理 HTML 的渲染，我们将看到这个过程既有优点也有缺点。

正如我们所看到的，渲染页面很简单。您向服务器发送请求，需要一些时间来设置必要的 HTML，将其发送回来，然后页面已加载。

那么，问题出在哪里呢？在这个阶段，还没有一个。事实上，这种方法看起来比 React.js 处理页面加载的方式更有效——至少在最初是这样。然而，当用户开始与页面交互时就会出现问题。让我们看一下假设的场景：

• 您进入一个页面。
• 您登录（客户端 -> 服务器（用于身份验证） -> DB（检查用户））并返回。 这里没问题。
• 您导航到帖子页面（客户端 -> 服务器 -> 数据库（获取帖子））并返回帖子数据。 这里没问题。
• 创建一个新帖子（客户端 -> 服务器（包含新帖子）-> DB（添加新帖子））并返回全新的 HTML。 这就是问题出现的地方。当您添加新帖子或对页面进行任何更改时，服务器需要从头开始重新呈现整个 HTML。这会导致整页重新渲染，效率可能会很低。每当您更新或更改页面上的任何内容时，都会发生这种完全重新渲染。

这就是 React 试图解决的问题

现在输入 React.js

React 是如何解决这个问题的？

React 引入了客户端渲染（CSR）的革命性概念。 CSR 不是在服务器上呈现 HTML，而是在客户端浏览器上呈现 HTML。
但是这是如何工作的？，考虑到当您第一次加载页面时，服务器仍然必须提供 HTML 服务？

发生的情况是这样的：服务器发送一个初始 HTML 框架，但它不包含实际内容。相反，它包含一个 <script>链接到捆绑的 JavaScript 代码的标签。当 HTML 被加载时——<strong>发生得很快，因为它大部分是空的——React 接管，在客户端渲染实际内容。然而，内容并不能立即可用。 React 首先必须向服务器发出<strong>单独的请求以获取必要的数据。只有此过程完成后，您才能看到完整的页面。</script>

如您所见，它比多页面应用程序 (MPA) 中的传统服务器端渲染 (SSR) 稍微复杂一些。 事实上，一开始它可能看起来比较慢，因为它需要多次往返服务器 - 首先是 HTML 框架，然后是 JavaScript 文件，最后是数据。这是 React 为接下来的魔法所接受的权衡之一。

现在，让我们回到浏览器从 <script> 加载 JavaScript 的步骤。初始 HTML 中的标记。 React 实际上所做的是<strong>创建 DOM 的虚拟副本，称为 <strong>虚拟 DOM (VDOM)。 React 使用此 VDOM 来<strong>有效地跟踪更改。 React 使用一个名为 <strong> 协调 .</script>

和解：

React 会将 DOM 的当前状态 与其 虚拟副本 进行比较，以准确定位发生更改的位置。然后，它仅更新 DOM 中已更改的部分，而不是重新加载整个页面。

すごいですね！ React は、サーバーに何度もアクセスすることなく、DOM 内の変更を追跡し、すべてクライアント側で変更された部分のみを更新できるようにすることで、この問題を解決しました。

ただし、このソリューションにはいくつかのトレードオフが伴います:

1. クライアント側のリソース使用量: クライアントのコンピューターは、HTML のレンダリング、仮想 DOM の作成、および調整プロセスの処理を担当します。これには、特に大きなツリー構造の場合、時間がかかることがあります。

2. ボットとクローラーの可視性の制限: Facebook、X (旧 Twitter)、Instagram などのボットとクローラーは、純粋なクライアント側でレンダリングされたアプリケーションのコンテンツを解析するのが難しい場合があります。 。これは、これらのボットが通常 JavaScript を実行しないために発生します。つまり、サーバーが送信する最初の HTML (多くの場合、空白か最小限の入力) しか参照できないことを意味します。 コンテンツがクライアント側のレンダリングに大きく依存している場合、SEO やソーシャル メディア共有に影響を与える可能性があります。

ここでの重要な課題は、クライアント側の対話性とサーバー側の効率のバランスを取ることです。 React のリコンシリエーション機能と仮想 DOM 機能をクライアント側の更新に活用しながら、サーバーが最初の HTML (必要なデータを備えたもの) をレンダリングする状態に戻ることができるとします。その場合、両方の長所を活かすことができます。

フレームワークがあれば...

Next.js を入力します。

ここで、サーバーサイド レンダリング (SSR) や Next.js などのフレームワークが登場します。 Next.js を使用すると、開発者は最初にサーバー上でページをレンダリングできるため、最初の HTML にユーザーが必要とするすべてのデータが確実に含まれ、パフォーマンス と SEO が向上します。この最初のサーバーでレンダリングされたページがクライアントに送信された後、完全な HTML コンテンツを取得しますが、ページはまだインタラクティブではなく、React がロードされていません。 JavaScript がロードされると、React は ハイドレーション プロセスを実行します。

ハイドレーション は、React がクライアント側で事前にレンダリングされた HTML を引き継ぎ、React の 仮想 DOM および 調整 プロセスを通じてスムーズな対話と更新を可能にするものです。 .

以上是从 PreReact 到 React 和 Next.js Web 渲染和性能优化之旅的详细内容。更多信息请关注PHP中文网其他相关文章！