SSG・SSR・ISR・CSR の違い

入門 | 10分 で読める | 2026.07.09

公式ドキュメント
Web開発

まず結論

SSG、SSR、ISR、CSRの違いは、HTMLをいつ、どこで作るかです。

この記事は4方式の全体比較です。SSRを採用する判断はSSRが必要になるページ、不要なページ、静的・動的という用語は静的サイトと動的サイトの違いで扱います。

方式HTMLを作るタイミング
SSGビルド時
SSRリクエスト時
ISRビルド後、必要に応じて再生成
CSRブラウザ上でJavaScriptが描画

名前だけ覚えるより、「いつHTMLができるのか」を見ると理解しやすくなります。

SSG

SSGはStatic Site Generationの略です。ビルド時にHTMLを作ります。

npm run build
  -> index.html
  -> about/index.html

向いているもの:

  • ブログ
  • ドキュメント
  • 会社サイト
  • 更新頻度が高すぎないページ

事前にHTMLがあるため、CDNで配信しやすく、表示も速くなりやすいです。

SSR

SSRはServer Side Renderingの略です。ユーザーのリクエストを受けてから、サーバがHTMLを作ります。

request
  -> server
  -> DB/API
  -> HTML response

向いているもの:

  • ログイン後のページ
  • ユーザーごとに内容が変わるページ
  • 常に最新データが必要なページ
  • 検索条件に応じて内容が変わるページ

柔軟ですが、サーバ処理が必要なので構成はやや複雑になります。

ISR

ISRはIncremental Static Regenerationの略です。静的生成と再生成を組み合わせる考え方です。

最初は静的に配信し、一定時間後や必要なタイミングでページを再生成します。

向いているもの:

  • 商品ページ
  • 記事ページ
  • 一覧ページ
  • ある程度新しさが必要だが毎回SSRしなくてよいページ

Next.jsなどでよく聞く言葉です。

CSR

CSRはClient Side Renderingの略です。最初にHTMLの土台とJavaScriptを配り、ブラウザ側で画面を作ります。

browser
  -> JS download
  -> API fetch
  -> render UI

向いているもの:

  • 管理画面
  • ダッシュボード
  • 操作が多いアプリ
  • ログイン後の複雑なUI

ただし、初回表示がJavaScript量に影響されやすく、SEOや初期表示の設計に注意が必要です。

比較

SSGはbuild時、SSRはrequest時のserver、ISRはcacheと再生成、CSRはbrowserが中心となってHTMLやUIを作り、pageごとに混在できることを比較する図

方式強み注意点
SSG速い、構成がシンプル頻繁な更新には工夫が必要
SSR常に動的に返せるサーバ負荷や応答速度
ISR速さと更新性のバランスキャッシュ設計が必要
CSRアプリ的な操作に強い初回JSが重くなりやすい

誰が、いつHTMLを作るのか

四方式の違いはフレームワーク名ではなく、要求されたURLのHTMLをどの時点で、どの計算資源を使って作るかです。SSGはビルド担当が公開前に作り、SSRはサーバが要求ごとに作り、ISRは以前の生成物を配りながら期限や通知を契機に作り直します。CSRは最初のHTMLを受け取った後、利用者のブラウザがJavaScriptとAPI応答から画面を組み立てます。同じサイトでもページ単位、さらにページ内の領域単位で生成場所を組み合わせられます。

問いSSGSSRISRCSR
公開前に内容が分かる得意可能だが過剰得意可能
要求ごとの個別化不向き得意共有内容向け得意
更新反映再ビルド次の要求再検証後API取得後
配信元CDNの静的ファイル実行サーバCDNと再生成処理静的殻とAPI
障害時の影響既存HTMLを配れる生成失敗が直撃古い版を配れる設計も可能API障害が画面へ影響

ページ別の判断例

学校紹介、料金、講師プロフィールは全員に同じで更新頻度も低いためSSGが自然です。記事一覧は更新のたび全サイトをビルドすると時間がかかるならISRを検討します。ログイン後の請求画面は利用者固有でキャッシュ共有が危険なため、SSRまたはCSRで認証済みAPIを使います。リアルタイム共同編集は最初の骨格より操作後の更新が中心なのでCSRが重要です。

SEOが必要だから必ずSSR、という判断はしません。公開時に内容が決まるページはSSGでも完全なHTMLを返せます。反対に、SSRを選んでも見出しや本文をクライアント取得へ任せれば初期HTMLに情報がありません。検索要件、更新頻度、個別化、応答時間、運用コストを別々に評価します。

よくある誤解

「CSRはHTMLを使わない」は誤りです。ブラウザはHTMLを入口にJavaScriptを読み、その後DOMを更新します。「ISRなら常に最新」でもありません。再検証の間は以前の内容が配られる設計があり、価格や在庫の厳密な最新性には別の取得が必要です。「SSRなら安全」でもなく、利用者固有HTMLを共有キャッシュへ保存すると情報漏えいになります。生成方式と認証・キャッシュ方針は別々に設計します。

動作確認：HTML、通信、更新時刻を見る

JavaScriptを無効にした状態またはcurlで初期HTMLを取得し、必要な見出しと本文が含まれるか確認します。NetworkでDocumentの応答時間、その後のAPI、キャッシュ関連ヘッダーを見ます。内容を更新し、ビルドなしでいつ反映されるかを時刻付きで記録すればSSGとISRの挙動を区別できます。

ログイン利用者を二人用意し、キャッシュを介して互いの名前やデータが見えないことも確認します。SSRでは生成処理が落ちた時の表示、ISRでは再生成失敗時に古い内容を維持するか、CSRではAPI待機中と失敗時の状態を試します。方式名ではなく、返ったHTML、追加通信、更新反映、キャッシュ分離を観測して判定します。

まとめ

SSGはビルド時、SSRはリクエスト時、ISRは必要に応じた再生成、CSRはブラウザ側描画です。

レンダリング方式は、表示速度、SEO、サーバ構成、更新頻度に影響します。まずはHTMLがいつ作られるかを押さえると、各フレームワークの説明も読みやすくなります。

参考リソース

次に読む記事

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR