はじめに

SSR、CSR、SSG。

Webフロントエンドを触っていると、よく目にする言葉です。

なんとなく、

SSRはサーバーで描画する
CSRはブラウザで描画する
SSGは静的なページを作る

くらいのイメージはあります。

しかし、いざ画面を作ろうとすると、

どれが速いのか
SEOにはどれがよいのか
どんなページに採用すべきなのか

を答えることができますか？

私は怪しかった。

だから、調べてまとめてみました。

先に結論を言います。「このサイトはSSRか、CSRか」で考えるのをやめると、大半の判断はつきます。 考える単位は、サイトでもページでもなく、データです。

この記事は、その結論にたどり着くまでを3部構成で進めます。

仕組み — 各方式がHTMLをいつ・どこで作るのか
実務の問い — 速度・SEOはどこで決まるのか
結論 — なぜ「データ単位」で考えると整理できるのか

第1部　仕組み：いつ・どこでHTMLを作るのか

1. 全体像

4方式の違いは、主にHTMLを生成する場所とタイミングにあります。

方式	HTMLを作る場所	作るタイミング
SSG	ビルド環境	ビルド時
SSR	サーバー	リクエスト時
CSR	ブラウザ	JavaScript実行時
ISR	サーバー	ビルド時＋再生成時

各方式の最後に「これはデータをいつ・どこで取得しているか」を一言添えておきます。第3部の伏線です。

2. SSG：ビルド時にHTMLを作る

SSGは、アプリケーションをビルドするときにHTMLを生成する方式です。

ユーザーがアクセスする時点では、すでにHTMLが完成しています。

向いているページ: ブログ、ドキュメント、LP、コーポレートサイトなど更新頻度の低いコンテンツ。

特徴: CDN配信しやすく表示が速い。サーバー負荷が小さい。一方、データ更新には再ビルドが必要。

データの取得タイミング: ビルド時に一度だけ。全ユーザーに同じHTMLを返す。

3. SSR：リクエスト時にHTMLを作る

SSRは、アクセスされるたびにサーバーでHTMLを生成する方式です。

SSGが「作り置き」なら、SSRはリクエストを受けてから生成します。

向いているページ: 検索結果、ユーザーごとに表示が異なるページ、CookieやHeaderに応じて変化するページ。

特徴: リクエスト時点のデータを表示でき、ユーザーごとにHTMLを変えられる。一方、リクエストごとにサーバー処理が走り、データ取得が遅いと返却も遅れる。

データの取得タイミング: リクエストごとにサーバーで。ユーザーや時点で内容を変えられる。

4. CSR：ブラウザで画面を作る

CSRは、ブラウザ上でJavaScriptを実行し、APIからデータを取得して画面を生成する方式です。

最初に届くHTMLには、コンテンツがほとんど含まれていない場合があります。

向いているページ: 管理画面、ダッシュボード、チャット、Webエディタなど、操作が主目的の画面。インタラクティブ性のために積極的に選ぶ方式であって、消去法の選択肢ではありません。

特徴: インタラクティブなUIやスムーズなページ遷移を作りやすい。一方、JavaScript実行までコンテンツが表示されず、初回表示時に通信が複数回発生しやすい。

データの取得タイミング: 表示後にブラウザから。操作に応じて何度でも取り直せる。

5. ISR：静的HTMLを後から更新する

ISRは、SSGで生成したHTMLを、一定時間や指定した条件で再生成する方式です。

静的配信の速さを維持しつつ、再ビルドなしで更新できます。

向いているページ: 商品詳細、求人詳細、店舗情報、ニュース記事など、数分程度の更新遅延を許容できるページ。

特徴: SSGの速さを保ちつつ更新できる。一方、再生成までは一時的に古い情報が表示されうる。

データの取得タイミング: ビルド時 + 条件付きで再取得。SSGとSSRの中間。

第2部　実務でつまずく2つの問い

各方式を並べただけでは、冒頭の「速いのは？SEOは？」には答えられません。ここで回収します。

6. どの方式が速いのか

「SSGが速く、CSRが遅い」と単純には決められません。重要なのは、ユーザーが何を待つかです。

SSG・ISR: 完成済みHTMLを返せるので初回表示を速くしやすい。
SSR: HTMLは完成状態で返るが、サーバーのデータ取得と生成を待つ。
CSR: HTML受信後にJavaScript実行とAPI通信が続く。

速さは方式の優劣ではなく、「待つ場所」がどこにあるかで決まります。

7. SEOでは何が違うのか

SSG・SSR・ISRは最初に返すHTMLに本文が含まれます。CSRは、JavaScript実行前のHTMLに十分なコンテンツが含まれないことがあります。

ただし「CSRならSEOできない」わけではありません。検索エンジンがJavaScriptを実行する場合もあります。とはいえCSRでは、初期HTML・表示速度・OGP・クローラーの実行コストなど、考慮事項が増えます。

8. Hydrationとは何か

SSRやSSGで生成されたHTMLは、表示されただけではReactのイベント処理が動かないことがあります。ブラウザでJavaScriptを読み込み、HTMLにイベント処理を接続する必要があります。

この処理を Hydration と呼びます。Hydrationは、SSR・CSR・SSGと同列のレンダリング方式ではなく、サーバー生成HTMLを「動く状態」にするための補完ステップです。

第3部　結論：データ単位で考える

ここまでの道具立てを、ひとつの軸で束ねます。

9. 同じ商品ページで比較する

商品詳細ページを例に、方式ごとの違いを見ます。

同じページでも、価格変更が反映されるタイミングは方式で変わります。

方式	価格変更が反映されるタイミング
SSG	次回ビルド後
SSR	次のリクエスト時
CSR	次のAPI取得時
ISR	次の再生成後

ここで気づきます。「商品ページに最適な方式」は一つに決まりません。ページの中に、性質の違うデータが同居しているからです。

10. ページ単位で使い分ける

まず、サイト全体を一つの方式で統一する必要はありません。ECサイトなら、ページごとに分けられます。

ここまでで粒度は「サイト → ページ」に下がりました。もう一段下げます。

11. データ単位で使い分ける

現代のNext.jsなどでは、ページ全体を一つの方式で固定しない構成が一般的です。商品詳細ページは、こう分割できます。

ここが着地点です。

「このサイトはSSRか、CSRか」ではなく、
「このデータを、いつ、どこで取得するか」

商品名はめったに変わらないからビルド時。価格・在庫はアクセス時点の値が要るからリクエスト時。お気に入りはユーザー操作で変わるからブラウザ。データの性質が、取得タイミングを決め、取得タイミングが方式を決めます。

第1部で各方式に添えた「データの取得タイミング」が、ここで効いてきます。方式を覚えるのではなく、データを見れば方式は逆算できる、というのがこの記事の主張です。

まとめ

4方式の違いは、HTMLを作る場所とタイミングにあります。

方式	一言で表すと
SSG	ビルド時に作り置きする
SSR	リクエストごとにサーバーで作る
CSR	ブラウザで作る
ISR	作り置きしたHTMLを後から更新する

選定は、データの性質から逆算します。

どの方式が最も優れているかではなく、データの性質に合っているか。それが判断の軸です。