ReactのSSR・SSG・Hydrationを理解する：Reactを理解して使う7日目
📅
はじめに 🔗
これまでは、Reactで動的なUIを作る方法へ注目してきました。
多くのReactアプリは、ブラウザーでJavaScriptを実行する
CSR
を使います。
豊かな操作を実現する一方、初回に空画面が出たり、SEOが難しかったりする場合があります。
それを補うのがSSR
とSSG
です。
今回は各方式の仕組みと特徴、密接に関係するHydration
を詳しく確認します。CSR：Client-Side Rendering 🔗
まず、慣れ親しんだCSRです。
仕組み 🔗
- ブラウザーが最小限のHTMLとJavaScriptをダウンロードする。
- JavaScriptを実行する。
- ReactがVirtual DOMを作り、実DOMを操作して表示する。
- 以後も操作に応じてUIを更新する。
長所 🔗
- 初回以降は全体を読み直さず、滑らかで速く遷移できる。
- サーバーは主にAPIだけを担い、負荷が少ない。
- 動的な操作を実装しやすい。
短所 🔗
- JavaScriptの取得・実行が必要で、最初の意味ある表示までが遅くなる場合がある。
- 最初のHTMLがほぼ空のため、クローラーが内容を収集しづらく、SEOへ影響する。
SSR：Server-Side Rendering 🔗
CSRの初回表示とSEOの問題を補う方式です。
内容を
サーバー側で事前に描画
し、完成HTMLをブラウザーへ渡します。仕組み 🔗
- ブラウザーからページを要求する。
- サーバーがAPIなどのデータを取得し、Reactで完全なHTML文字列を作る。
- HTMLをレスポンスとして送る。
- ブラウザーが直ちに表示し、ユーザーは早く内容を見られる。
- 同時に必要なJavaScriptをバックグラウンドで取得する。
- 読み込み後、ReactがHTMLへハンドラーなどを関連付け、操作可能にする。これがHydration。
CSRとの比較 🔗
- 初回の速度（TTFP・FCP）Time To First PaintとFirst Contentful Paintは、最初の表示までの時間を測ります。完成HTMLを送るSSRは、CSRよりFCPが早く、体感性能が高まります。
- SEO完成HTMLからクローラーが内容を容易に収集できます。
- サーバー負荷要求ごとに描画するため、CSRより高くなります。
- 最初のバイトまでの時間（TTFB）HTMLの生成時間が必要なので、Time To First ByteはCSRより遅い場合があります。
Next.jsとストリーミングSSR 🔗
従来は全HTMLの生成完了を待って送るため、複雑なページや遅いデータ取得ではTTFBも悪化しました。
それを改善するのが
ストリーミングSSR
です。
Next.js App Routerは標準で対応します。- 仕組み基本のシェルを先に送り、準備できたUIのchunkを順に配信します。 ブラウザーは届いたHTMLから描き、必要なJavaScriptを読み込んでHydrationします。
- 長所少なくとも一部を早く見せ、サーバー描画が応答全体を止めないため、TTFBと体験の改善に役立ちます。 React Suspenseと密接に連動します。
SSG：Static Site Generation 🔗
全ページを
ビルド時
にHTMLへ事前生成する方式です。仕組み 🔗
- 開発者がコードをビルドする。
- Next.jsやGatsbyが、必要なデータも取得し、定義されたパスを個別のHTMLへ描画する。
- HTML、CSS、JavaScriptを静的サーバーやCDNへ配信する。
- 要求時には、生成済みHTMLを即座に返す。
- 表示後にJavaScriptを読み込み、Hydrationで操作可能にする。
CSR・SSRとの比較 🔗
- 性能要求時のサーバー描画がなく非常に速く、CDNで世界中へ効率よく届けられます。
- サーバーへの依存と負荷ファイルを送るだけなので負荷はほぼなく、Jamstackのようなサーバーレス運用も可能です。
- 安全性サーバーロジックがほとんどなく、攻撃面を減らせます。
- ビルド時間ページや取得処理が多いと、長くなる場合があります。
- データの新しさ内容を変えたら再ビルド・再配信が必要です。ISRなどで補う方法もあります。
適した用途 🔗
更新が少なく、ビルド時に生成できる内容に効果的です。
- ブログ記事
- APIドキュメントやチュートリアル
- マーケティング・ランディングページ
- ポートフォリオ
Q：「SSRとSSGの違いと、使いどころは何ですか。」 A：「SSRは要求時、SSGはビルド時にHTMLを作ります。個別化した内容や頻繁に変わるデータにはSSR、静的な内容中心ならSSGが高い性能を提供します。」
Hydration：静的HTMLを操作可能にする 🔗
SSRやSSGのHTMLは、最初は見るだけの静的な文書です。
ボタンや入力を扱うには、ReactのJavaScriptが必要です。
Hydration
は、サーバー生成HTMLの上でReactを動かし、乾いた土地へ水を与えるように、動的なアプリへ変える過程です。なぜ必要なのか 🔗
次の重要な作業を行います。
- ハンドラーの関連付け
onClick、onChangeなどを実DOMへ結び付けます。 - 状態の初期化
useState、useReducerなどの内部状態を初期化し、必要ならサーバーからの初期値を使います。 - Virtual DOMの生成サーバーHTMLと一致するツリーをメモリーに作り、その後の更新へ備えます。
HTMLの骨組みに、JavaScriptという神経や筋肉を与え、動くアプリへ完成させます。
Hydrationエラーへの注意 🔗
Reactは、サーバーHTMLとクライアントのVirtual DOMが
正確に一致する
と期待します。
異なるとHydration Mismatchの警告が出て、場合によってはクライアントで全体を再描画し、SSR・SSGの利点を失います。
主な原因は次のとおりです。windowやタイムゾーンなど、両環境の違い。p内のdivなど、誤ったHTMLの入れ子。Math.random()や現在時刻など、生成時点によって内容が変わる処理。
両側の結果を一貫させることが重要です。
必要なら
useEffectで、クライアント専用の処理を分離します。進化する描画パターン 🔗
SSR・SSGの利点を残しながら、JavaScriptの取得・実行コストを減らす方法が注目されています。
Partial Hydration 🔗
全体ではなく、操作が必要な
一部のコンポーネントだけ
を選択してHydrationします。
静的部分はHTMLのまま、動的部分だけJavaScriptを動かし、初回表示やTime to Interactiveを短縮できます。Islands Architecture 🔗
静的HTMLの海に、操作できる複数の島を浮かべるように構成するパターンです。
各島は独立したウィジェットやコンポーネントで、自らスクリプトを取得し、Hydrationします。
長所 🔗
必要なJavaScriptだけを取得し、全体の量を減らします。
重要でない部分の読み込みが、重要な操作を妨げません。
段階的にHydrationでき、TTIも改善します。
実装 🔗
AstroやFreshが積極的に採用し、Next.jsのServer Componentsも似た目標を持っています。
まとめ 🔗
多様な描画方式を詳しく確認しました。
- CSRは豊かな操作に強い一方、初回表示とSEOが弱点になりうる。
- SSRは初回表示とSEOに有利だが、負荷が増える。ストリーミングSSRはTTFBを改善する進化形。
- SSGは事前生成で高い性能・安定性を提供するが、動的データには制約がある。
- Hydrationは、SSR・SSGのHTMLへReactを適用し、操作可能にする必須の過程。
- Partial HydrationとIslands Architectureは、必要部分だけJavaScriptを動かす最適化。
絶対に良い方式があるわけではありません。
特徴、内容の動的性、性能の要件、SEOを総合的に考え、選択・組み合わせることが大切です。
Next.jsなどは、そのための多くの機能を提供します。
次回はReactに関わるデータ構造を学びます。 配列、連結リスト、ツリーなどが内部動作や実装でどう使われるかを知り、基礎を固めます。
参考 🔗
- Google Developers：Rendering on the Web：https://developers.google.com/web/updates/2019/02/rendering-on-the-web↗
- Next.js公式：Rendering：https://nextjs.org/docs/basic-features/rendering↗
- web.dev：Hydration：https://web.dev/rendering-hydration/↗
- Patterns.dev：Islands Architecture：https://www.patterns.dev/posts/islands-architecture/↗
