Von PreReact zu React und Next.js Eine Reise durch Web-Rendering und Leistungsoptimierung

この記事では、React の起源、それが解決する問題、そして

について探っていきます。 Next.js が作成された理由。 Next.js が SSR (サーバーサイド レンダリング) を提供していることは広く知られていますが、SSR の本当の意味と SSR が CSR より優れている理由について詳しく説明します (client-サイドレンダリング)、場合によっては。

簡単な歴史: React.js 以前

React.js が CSR (クライアントサイド レンダリング) の概念を普及する前、ほとんどのアプリケーションは従来の MPA (マルチページ アプリケーション) モデルに従いました。 MPA では、サーバーが HTML のレンダリングを処理しましたが、このプロセスには利点と欠点の両方があることがわかります。

ご覧のとおり、ページのレンダリングは簡単でした。サーバーにリクエストを送信すると、必要な HTML のセットアップに時間がかかり、それを送り返すと、ページが読み込まれます。

それで、何が問題なのでしょうか?この段階では、それはありません。実際、このアプローチは、少なくとも最初は React.js がページの読み込みを処理する方法よりも効率的であるように見えます。ただし、ユーザーがページの操作を開始したときに問題が発生します。仮説的なシナリオを見てみましょう:

• ページに入ります。
• ログイン (クライアント -> サーバー (認証用) -> DB (ユーザーの確認)) してログインし直します。 ここでは問題ありません。
• たとえば、投稿ページ (クライアント -> サーバー -> DB (投稿の取得)) に移動し、投稿データに戻ります。 ここでは問題ありません。
• 新しい投稿を作成 (クライアント -> サーバー (新しい投稿) -> DB (新しい投稿の追加))、完全に新しい HTML で戻ります。 ここで問題が発生します。新しい投稿を追加するとき、またはページに変更を加えるとき、サーバーは HTML 全体を最初から再レンダリングする必要があります。これにより、全ページの再レンダリングが発生し、非効率となる可能性があります。この完全な再レンダリングは、ページ上の何かを更新または変更するたびに行われます。

それが、react が修正しようとしていたものです

次に React.js を入力します

React はどのように問題を解決しましたか?

React は、クライアントサイド レンダリング (CSR) という革新的な コンセプトを導入しました。 CSR は、HTML をサーバー上でレンダリングするのではなく、クライアントのブラウザ上でレンダリングします。
しかし、これはどのように機能するのでしょうか?、最初にページをロードするときにサーバーが HTML を提供する必要があるとすると、

これで何が起こります: サーバーは 初期 HTML スケルトン を送信しますが、実際のコンテンツは含まれていません。代わりに、