React、next.jsのレンダリング歴史。知りたくないですか?

初めに

現在、フロントとバックエンドともに主流に使われているreact、next.js。これらには深いレンダリングに関する歴史があるのをみなさんは知っていますか?

対象読者

react始めたて、始めようか迷っている人
react、next.jsに関して理解を深めたい人

CSR編(Client Side Rendering)

主に素のreactのレンダリング手法で、クライアントサイドに負荷がかかる状態です。
データの流れとしては

1. ブラウザがサーバーにリクエストをする
2. サーバーは空（最小限）の HTML を返却
3. サーバーは JS ファイルをブラウザに返却
4. ブラウザ側で HTML と JS を構築（レンダリング）
5. ページ完成
   
   このように CSR だと、ブラウザ側で JS のダウンロード、実行、DOM の構築などすべてを行うため、初期表示（First Contentful Paint）が遅くなってしまうというデメリットがあります。また、検索エンジンのクローラーがページ内容を認識しづらい（SEOに弱い）という課題もありました。

SSR編(Server Side Rendering)

これはCSRの問題であるブラウザに負荷がかかる問題を解決するために設計されたアプローチです。
次に挙げるのがSSR(Next.jsのPages router)です。こちらはサーバーに負担がかかる状態ですね。
こちらもイメージを使って解説していきたいと思います!

1. ブラウザにリクエスト
2. サーバーは必要なデータ(ユーザー情報など)を全部取得し、ブラウザへ返却する。
3. その後ブラウザ側でハイドレーション(HTMLにjsを読み込む)を行う。
4. ページ完成
   
   SSRでは初期ロードの時点である程度のコンテンツが表示されるため、バンドルされたjsがダウンロードされ実行されている間でも、ユーザーは真っ白なページを見続ける必要はありません。そのため、CSR と比べて初期速度が改善します。
   ただSSRにもまだ問題点が残っています。

・ページ単位という制限 SSR では、データ取得とレンダリングが基本的に「ページ単位」でしか機能しません。 そのため、ページ内のどこか1つのデータ取得が遅れると、ページ全体の表示がブロックされてしまいます。

・「すべて」をハイドレーションする必要がある SSR を使用しても、最終的にはクライアント上で JS を読み込み、ハイドレーションを行う必要があります。 「ただのテキスト表示」のような、本来 JS が不要な部分も含めてすべてのコンポーネントの JS がブラウザに送られるため、JS の転送量（バンドルサイズ）が大きくなりがちでした。

RSC RCC編

これらの問題を解決するために生み出されたのがRSCです。
この技術はReact コンポーネントのレンダリングプロセスにおけるアーキテクチャで、CSR や SSR といったレンダリング手法の問題点を解決するために生まれました。
RSC (React Server Components) とは？
従来の「サーバーかクライアントか（SSR vs CSR）」という二項対立ではなく、「コンポーネント単位」でサーバー実行とクライアント実行を使い分けるアーキテクチャです。

主に以下の2つのコンポーネントを組み合わせて開発します。

・Server Components (RSC):

サーバー側でのみ実行されるコンポーネント。

特徴: ここで使ったライブラリやコードはブラウザに送信されません（ゼロ・バンドルサイズ）。

データ取得（DBアクセス等）をコンポーネント内に直接書くことができます。

・Client Components (RCC):

従来の React コンポーネントと同様にブラウザで実行されます。

useState や useEffect、onClick などのインタラクティブな機能が必要な場合に使用します。

ファイルの先頭に 'use client' と記述します。

RSC が解決したこと
SSR の課題であった「不要な JS までブラウザに送られる」問題が解決しました。 静的なコンテンツ（ブログの本文など）は RSC として処理することで、HTML だけがブラウザに届き、JS は送信されません。 これにより、ブラウザが読み込む JS の量が劇的に減り、パフォーマンスが向上しました。

さらに、Streaming HTML と組み合わせることで、サーバーでの準備ができた部分から順次ブラウザに表示させることが可能になり、「ページ全体が完成するまで待つ」必要もなくなりました。

Streaming HTMLって何?

Streaming HTML とは、サーバーがウェブページ全体を一度に生成するのを待つのではなく、準備ができた部分から順次（ストリームとして）ブラウザに送信する技術です。

これは、SSRで残っていた「データ取得が遅いコンポーネントのせいで、ページ全体の表示がブロックされる」という問題を解決します。

仕組みのイメージ
従来の SSR では、サーバーは以下の手順で処理を行っていました。

・すべてのデータ取得（データベースクエリなど）が完了するまで待つ。

・すべてのデータを使って、完全な HTML ファイルを生成する。

・その完全な HTML をブラウザに送信する。

Streaming HTML を使用すると、処理は以下のように変わります。

すぐにシェル（骨格）を送信: サーバーはナビゲーションバーやフッターなど、データ取得が不要な**ページの骨格（シェル）**をすぐに生成し、ブラウザに送信します。

非同期でデータを取得: ページ内の遅いコンポーネント（例えば、重い API からのユーザーリストを取得する部分など）はバックグラウンドで処理を継続します。

順番にコンテンツを送信: 遅いコンポーネントのデータが取得でき次第、その部分の HTML のみを後からブラウザにストリーム（流し込み）ます。

これまでの歴史を可視化させると以下のような流れになっています！

2013年: CSR (Vanilla React)

2016年頃〜: SSR (Next.js Pages Router)

2023年〜: RSC 登場 (Next.js App Router Stable)

終わりに

いかがでしたか?このreact、next.jsがどのようにレンダリング手法を変えていったのかを知ることによってもっとフロントエンドの理解が深まると思います😊
以上です!