はじめに
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を後から更新する |
選定は、データの性質から逆算します。
どの方式が最も優れているかではなく、データの性質に合っているか。それが判断の軸です。