16.1 CSR

ブラウザでJavaScriptを読み込み、クライアントで画面を生成する。

利点:

  • 静的ホスティングしやすい
  • 遷移後の操作性が高い
  • サーバー構成が単純

課題:

  • 初回JavaScript量
  • データ取得のウォーターフォール
  • SEO・共有メタデータ
  • 低性能端末

16.2 SSR

サーバーで初期HTMLを生成し、ブラウザでhydrateする。

renderToPipeableStream(<App />, options);

利点:

  • 初期コンテンツ表示
  • SEO
  • ストリーミング

課題:

  • サーバー運用
  • hydrationコスト
  • サーバー・クライアント出力不一致
  • キャッシュ設計

16.3 SSG

ビルド時にHTMLを生成する。更新頻度の低いページに向く。
React本体よりフレームワークの責任領域である。

16.4 Hydration

サーバーHTMLにイベント処理とReact stateを接続する。

hydrateRoot(
  document.getElementById("root")!,
  <App />
);

サーバーとクライアントの初回出力は一致させる。

不一致の原因:

  • Date.now()
  • Math.random()
  • ブラウザ専用API
  • ロケール差
  • サーバーとクライアントで異なるデータ
  • 不正なHTML構造

16.5 ストリーミングSSR

HTMLをすべて待ってから返すのではなく、準備できた部分から送る。Suspense境界がストリームの単位になる。

16.6 選択基準

要件 適する方式
社内ツール、ログイン後中心 CSR
公開コンテンツ、SEO SSR/SSG
更新頻度が低い記事 SSG
個別化しつつ初期表示重視 SSR
静的部分と動的部分の混在 PPR対応フレームワーク
サーバー側データ処理をUIへ統合 RSC対応フレームワーク

一つのアプリ内で複数方式を混在させることが一般的である。