CSR・SSR・SSG・ISR
このページで学ぶこと
Section titled “このページで学ぶこと”- レンダリングとは何か
- CSR・SSR・SSG・ISRでHTMLを作るタイミングがどう違うか
- 初期表示、SEO、CMS更新、ビルド、費用への影響
- 一つのサイトで複数方式を使い分けられること
- 「何を採用したか」ではなく「なぜ採用したか」を確認する方法
レンダリングとは、データや部品から利用者へ表示する内容を作ることです。主な違いは「HTMLをいつ・どこで作るか」です。
flowchart TD
DATA[CMS・API・ソース]
DATA --> CSR[CSR<br/>ブラウザで生成]
DATA --> SSR[SSR<br/>アクセス時にサーバーで生成]
DATA --> SSG[SSG<br/>ビルド時に生成]
DATA --> ISR[ISR等<br/>静的ページを後から再生成]
CSR --> U[利用者]
SSR --> U
SSG --> U
ISR --> U
方式名や実装はフレームワークにより異なります。この章ではPMの判断軸として一般化します。
CSR：ブラウザ側で画面を作る
Section titled “CSR：ブラウザ側で画面を作る”CSRでは、ブラウザがJavaScriptを実行し、APIからデータを取得して表示します。
sequenceDiagram
participant U as 利用者
participant H as 配信サーバー
participant B as ブラウザJS
participant A as API
U->>H: ページを要求
H-->>U: 基本HTMLとJavaScript
U->>B: JavaScriptを実行
B->>A: データを要求
A-->>B: データを返す
B-->>U: 画面を表示
- 操作の多い画面を作りやすい
- 画面遷移を滑らかにしやすい
- APIとフロントエンドを分離しやすい
- 管理画面・ログイン後画面と相性がよい
- JavaScript取得・実行・API応答を待つ
- 初期表示が遅くなる場合がある
- JavaScriptエラーの影響が大きい
- 検索・SNS共有用情報を考慮する
- ブラウザ性能や通信環境の影響を受ける
SSR：アクセスごとにサーバーでHTMLを作る
Section titled “SSR：アクセスごとにサーバーでHTMLを作る”SSRでは、アクセス時にサーバーがデータを取得し、HTMLを生成して返します。
sequenceDiagram
participant U as 利用者
participant S as 実行サーバー
participant A as CMS・API
U->>S: ページを要求
S->>A: データを要求
A-->>S: データを返す
S->>S: HTMLを生成
S-->>U: HTMLを返す
- 初回から主要内容をHTMLで返しやすい
- 最新データをアクセス時に反映しやすい
- 利用者ごとに内容を変えやすい
- アクセスごとにサーバー処理が必要
- CMS・APIが遅いと表示も遅くなる
- アクセス増加時の負荷・費用
- 実行環境、監視、キャッシュが必要
SSG：ビルド時にHTMLを作る
Section titled “SSG：ビルド時にHTMLを作る”SSGでは、公開前のビルドで各URLのHTMLを生成し、静的ファイルとして配信します。
sequenceDiagram
participant C as CMS・ソース
participant B as ビルド環境
participant H as 静的ホスティング
participant U as 利用者
C->>B: コンテンツを渡す
B->>B: 各ページのHTMLを生成
B->>H: ファイルを配置
U->>H: ページを要求
H-->>U: 生成済みHTMLを返す
- アクセス時にページ生成が不要
- CDNから高速に配信しやすい
- 実行サーバー障害の影響を減らせる
- コスト・攻撃対象を抑えやすい
- CMS更新後にビルド・デプロイが必要
- ページ数が多いとビルドが長くなる
- ビルド時にCMS・APIが停止すると公開できない場合がある
- プレビュー・予約公開を設計する必要
ISR・オンデマンド再生成
Section titled “ISR・オンデマンド再生成”ISRはNext.js等で使われる名称で、静的生成したページを、時間・アクセス・更新通知に応じて再生成する考え方です。
sequenceDiagram
participant U as 利用者
participant C as キャッシュ済みページ
participant R as 再生成処理
participant A as CMS・API
U->>C: ページを要求
C-->>U: 保存済みページを返す
C->>R: 条件に応じて再生成
R->>A: 最新データを取得
A-->>R: データを返す
R->>C: 新しいページへ更新
- 全サイトを毎回ビルドせずに更新できる
- 静的配信の速さを活かしやすい
- 大量ページの更新へ対応しやすい
- 一時的に古い内容を返す方式がある
- 再生成失敗時の動作を確認する
- キャッシュ・再検証の理解が必要
- フレームワーク・ホスティングに依存する
| 観点 | CSR | SSR | SSG | ISR・再生成 |
|---|---|---|---|---|
| HTML生成 | ブラウザ実行時 | アクセス時 | ビルド時 | 事前生成＋後から更新 |
| 初期表示 | JS・API待ちに注意 | サーバー応答に依存 | 高速にしやすい | 高速にしやすい |
| 最新性 | API次第 | 高い | 再ビルドまで古い | 更新条件次第 |
| SEO | 実装を確認 | HTMLを返しやすい | HTMLを返す | HTMLを返す |
| 実行サーバー | API等は必要 | 必要 | 配信だけなら不要 | 再生成環境が必要 |
| 主な障害点 | JS・API | サーバー・API | ビルド・CDN | キャッシュ・再生成 |
| 向く例 | 管理画面、検索UI | 個別表示、頻繁な更新 | 企業サイト、記事 | 大規模メディア |
SEOは方式名だけで決まりません。HTML、ステータス、URL、リンク、内容、速度を総合的に設計します。
ハイブリッドレンダリング
Section titled “ハイブリッドレンダリング”一つのサイトでページごとに方式を変える構成があります。
flowchart TD
SITE[一つのサイト]
SITE --> TOP[固定ページ<br/>SSG]
SITE --> NEWS[ニュース<br/>再生成]
SITE --> SEARCH[検索結果<br/>CSR・SSR]
SITE --> MEMBER[会員ページ<br/>SSR・CSR]
要件へ合わせやすい一方、テスト・キャッシュ・障害切り分け・運用は複雑になります。
CMS更新への影響
Section titled “CMS更新への影響”APIから取得するため比較的すぐ反映できます。ただしAPI・ブラウザ・検索キャッシュがある場合は遅れることがあります。
アクセス時にCMSから取得すれば最新化しやすい一方、CMS障害が表示へ直結します。サーバーキャッシュを使う場合は反映時間を決めます。
CMS公開後、Webhook、ビルド、デプロイ、CDN更新を経て反映します。
ISR・再生成
Section titled “ISR・再生成”全体ビルドを避けられますが、再生成条件、反映保証、失敗時の古い表示、手動更新方法を確認します。
プレビューへの影響
Section titled “プレビューへの影響”CMSの下書きを確認するプレビューは方式により異なります。
- プレビュー用APIをブラウザで読む
- サーバー側で下書きを取得する
- 一時的なプレビューURLを生成する
- 本番とは別の検証ビルドを作る
プレビューボタンの有無だけでなく、本番に近い表示、関連コンテンツ、リンク、端末で確認できるかを要件化します。
費用への影響
Section titled “費用への影響”- CSR：静的配信は安価でもAPI・検索・認証費用がある
- SSR：アクセスごとの実行時間・CPU・API呼び出しが費用になる
- SSG：配信費を抑えやすいが、ビルド時間・回数に費用がかかる場合がある
- ISR：配信・キャッシュ・再生成・実行費用が組み合わさる
同じフレームワークでも方式により月額費用は異なります。
実案件ではどう考えるか
Section titled “実案件ではどう考えるか”500ページのコーポレートサイト
Section titled “500ページのコーポレートサイト”更新が月数回で個別表示が少なければSSGが有力です。ビルド時間、プレビュー、ニュース反映時間を確認します。
5万記事のメディア
Section titled “5万記事のメディア”毎回全件ビルドすると長時間になる可能性があります。更新記事だけ再生成、頻出ページだけ事前生成、SSR等を比較します。
施設検索サイト
Section titled “施設検索サイト”施設詳細はSSG・再生成、検索結果はCSR、予約状況はAPI取得という組み合わせが考えられます。
会員マイページ
Section titled “会員マイページ”個人情報を共有キャッシュへ保存しない設計が重要です。認証・API・キャッシュ制御を確認します。
PMチェックリスト
Section titled “PMチェックリスト”- 各ページの生成方式を一覧化している
- 方式を選んだ理由を説明できる
- 主要内容がいつHTMLになるか把握している
- CMS更新から反映までの時間を定義している
- 本番ページ数でビルド時間を測定している
- プレビューの仕様を確認している
- キャッシュと手動更新方法を確認している
- API・CMS障害時の表示を決めている
- アクセス増加時の費用を確認している
- 個人情報ページを共有キャッシュしない
- SEOを方式名だけで判断していない
よくある誤解・失敗
Section titled “よくある誤解・失敗”「SSRならSEOは完璧」
Section titled “「SSRならSEOは完璧」”title、見出し、リンク、ステータス、canonical、速度等も必要です。
「SSGなら更新できない」
Section titled “「SSGなら更新できない」”ビルド・デプロイや再生成で更新できます。問題は更新経路と反映時間です。
「CSRは検索エンジンに一切読まれない」
Section titled “「CSRは検索エンジンに一切読まれない」”一律には言えませんが、遅延・エラー・リンク・メタ情報・利用者の初期表示を考慮します。
「ISRなら常に最新」
Section titled “「ISRなら常に最新」”更新条件によっては古い内容が一時表示されます。失敗時の挙動も確認します。
「一つのサイトは一方式で統一する」
Section titled “「一つのサイトは一方式で統一する」”ページごとに混在できます。ただし複雑さも増えます。
理解度チェック
Section titled “理解度チェック”Q1. CSR・SSR・SSGの違いをHTML生成のタイミングで説明してください。
Section titled “Q1. CSR・SSR・SSGの違いをHTML生成のタイミングで説明してください。”回答と解説
CSRは主にブラウザ実行時、SSRはアクセス時にサーバー、SSGは公開前のビルド時にHTMLを作ります。Q2. SSGサイトでCMS更新が反映されない場合、何を確認しますか。
Section titled “Q2. SSGサイトでCMS更新が反映されない場合、何を確認しますか。”回答と解説
CMS公開状態、Webhook、ビルド、デプロイ、CDNキャッシュ、ブラウザキャッシュを確認します。Q3. 大量記事サイトの全件ビルドが長い場合の選択肢は何ですか。
Section titled “Q3. 大量記事サイトの全件ビルドが長い場合の選択肢は何ですか。”回答と解説
差分・オンデマンド再生成、ISR、ページ単位キャッシュ、頻出ページのみ事前生成、SSR・CSRとの混在です。Q4. SSRページでCMSが停止すると何が起こり得ますか。
Section titled “Q4. SSRページでCMSが停止すると何が起こり得ますか。”回答と解説
表示遅延・エラーが起こり得ます。キャッシュ済み表示、タイムアウト、代替表示を設計します。Q5. 主な判断軸は何ですか。
Section titled “Q5. 主な判断軸は何ですか。”回答と解説
ページ数、更新頻度、動的機能、SEO、反映時間、プレビュー、ビルド、費用、保守体制です。- Next.js「Server-side Rendering」
https://nextjs.org/docs/pages/building-your-application/rendering/server-side-rendering - Next.js「Static Site Generation」
https://nextjs.org/docs/pages/building-your-application/rendering/static-site-generation - Next.js「Incremental Static Regeneration」
https://nextjs.org/docs/app/guides/incremental-static-regeneration - Nuxt「Rendering Modes」
https://nuxt.com/docs/guide/concepts/rendering - Astro「On-demand rendering」
https://docs.astro.build/en/guides/on-demand-rendering/