コンテンツにスキップ

【比較】SSR・CSR・SSG・ISRの違い

概要

SSR・CSR・SSG・ISR は、Web ページの HTML を「どこで」「いつ」生成するかという戦略（レンダリング戦略）の違いです。同じ React/Vue アプリでも、最終的にブラウザへ届く HTML の作られ方が変わると、初回表示速度（TTFB・FCP）・SEO・インタラクティブになるまでの時間が大きく変わります。

整理すると、CSR はブラウザで実行時に、SSR はサーバーでリクエストごとに、SSG はビルド時に一度だけ、HTML を生成します。ISR は SSG を土台にしつつ、デプロイ後も時間経過や明示的なトリガーでページを再生成する仕組みで、これは Web 標準の用語ではなく Next.js が導入したフレームワーク固有の概念です（他フレームワークにも類似機能はありますが、ISR という呼称は Next.js のもの）。混同しやすいのは、これらが排他的な選択肢ではなく、ページ単位で使い分けたりハイブリッドにできる点です。

例えるなら：料理を「いつ調理するか」

  • CSR … 注文を受けてから客自身が厨房（ブラウザ）で材料（JS）を受け取り自分で調理する。最初の一皿が出るまで遅いが、その後の操作は手元で速い。
  • SSR … 注文ごとに厨房（サーバー）が出来たてを作って出す。常に最新だが、注文が来てから作るので一皿目に少し待つ（TTFB 増）。
  • SSG … 開店前（ビルド時）に全メニューを作り置きしておき、注文が来たら即出す。最速だが、作り置きなので内容は固定。
  • ISR … 作り置き（SSG）を基本にしつつ、「一定時間ごと」または「指示が来たら」厨房が裏で作り直して差し替える。速さと鮮度を両立。

詳細比較

比較軸 CSR（クライアントサイドレンダリング） SSR（サーバーサイドレンダリング） SSG（静的サイト生成） ISR（増分的静的再生成・Next.js 用語）
HTML を生成する場所 ブラウザ サーバー ビルド環境 ビルド環境＋デプロイ後のサーバー
HTML を生成するタイミング ページ読み込み後（実行時） リクエストごと build 実行時に一度 build 時に生成し、その後再生成
初回 HTML の中身 ほぼ空（JS が後から描画） 完成した HTML 完成した HTML 完成した HTML（場合により stale）
TTFB（最初の1バイトまで） 速い（中身の薄い静的シェルを返すだけ。シェル配信方法に依存） リクエストごとの生成分だけ遅くなりうる 速く安定（生成済み） 速く安定（基本はキャッシュ配信）
SEO・クローラ対応 不利になりやすい（初期 HTML が空） 有利（完成 HTML を返す） 有利（完成 HTML を返す） 有利（完成 HTML を返す）
データの鮮度 実行時取得で常に最新にしやすい リクエストごとに最新 ビルド時点で固定 revalidate 間隔／明示トリガーで更新
ハイドレーション 必要（最初から JS で構築） 必要（サーバー HTML に対話性を付与） 必要（静的 HTML に対話性を付与） 必要（SSG と同様）
向くケース 管理画面・ログイン後アプリ 毎回変わる動的ページ ブログ・ドキュメント・LP 多数だが頻繁には変わらないページ

よくある誤解

  • 誤解1：「ISR は HTTP やブラウザの標準的なレンダリング方式の一つ」 — 誤りです。SSR/CSR/SSG はレンダリングの一般概念ですが、ISR（Incremental Static Regeneration）は Next.js が提供するフレームワーク機能の名称です。公式ドキュメントも「ISR はサイト全体を再ビルドせずに静的コンテンツを更新できる」機能として定義しています。他フレームワーク（Astro・Nuxt 等）にも類似の再生成機構はありますが、「ISR」という語を一般用語として SSR/CSR と同列に並べると不正確になります。
  • 誤解2：「ISR は revalidate 時間が来たらユーザーを待たせて再生成する」 — 誤りです。Next.js の時間ベース revalidation は stale-while-revalidate 型で、期限切れ後の最初のリクエストにもまずキャッシュ済み（古い）ページを即座に返し、裏側で新版をバックグラウンド生成して次回以降に差し替えます。公式ドキュメントも「the next request will still return the cached (now stale) page」「a new version of the page begins generating in the background」と明記しています。
  • 誤解3：「SSR にすれば必ず表示が速くなる」 — 一概には言えません。SSR は完成 HTML を返すため FCP や SEO に有利な一方、サーバーがリクエストごとに HTML を生成する分 TTFB が増えうると web.dev も指摘しています。SSG/ISR は生成済みを配るため TTFB が安定して速い、というトレードオフがあります。
  • 誤解4：「CSR は SEO に絶対不利」 — 「初期 HTML がほぼ空」なため不利になりやすいのは事実ですが、絶対ではありません。ログイン後の管理画面など、そもそも検索インデックス不要な領域では CSR の不利は問題になりません。問題は「公開ページなのに CSR で初期 HTML が空」というケースであり、用途を踏まえた評価が必要です。

実務での選び分け

レンダリング戦略は「アプリ全体で1つ」ではなく、ページ単位で選ぶのが現代の定石です。

  • 公開コンテンツで内容がほぼ変わらない（ブログ・ドキュメント・LP） → SSG。最速・最安・SEO 良好。
  • 公開コンテンツだが件数が多く、たまに更新される（EC の商品ページ・ニュース記事） → ISR（Next.js）等。SSG の速さを保ちつつ、revalidate 時間や CMS 更新時の on-demand トリガー（revalidatePath/revalidateTag）で鮮度を担保。
  • リクエストごとに内容が変わる／パーソナライズが必要（ダッシュボード初期表示、認証依存ページ） → SSR。完成 HTML を返しつつ常に最新。TTFB 増は許容範囲か検証する。
  • 検索インデックス不要で操作中心のアプリ（社内管理画面、SaaS のログイン後画面） → CSR でも十分。初期 HTML が空でも実害が少なく、実装がシンプル。
  • 判断軸：①そのページは検索に乗せたいか（SEO） ②データの鮮度要件（ビルド時固定で良いか／毎回最新か／その中間か） ③トラフィックと生成コスト。これらをページごとに当てはめると自然に戦略が決まります。

ひとことまとめ

CSR＝ブラウザで実行時、SSR＝サーバーでリクエストごと、SSG＝ビルド時に一度、ISR＝SSG＋デプロイ後の定期/明示再生成（Next.js 固有用語）。排他選択ではなくページ単位で使い分けるのが実務の基本です。

出典・参考

  • web.dev「Rendering on the Web」（SSR＝サーバーで HTML を生成して返す／CSR＝ブラウザで JS が DOM を構築／static rendering はビルド時／hydration の定義、SSR は TTFB が増えうる等のトレードオフ）: https://web.dev/rendering-on-the-web/
  • Next.js 公式「How to implement Incremental Static Regeneration (ISR)」（ISR はサイト全体を再ビルドせず静的コンテンツを更新する機能。時間ベースは stale-while-revalidate＝古いページを返しつつ裏で再生成。on-demand は revalidatePath/revalidateTag。ISR は Node.js ランタイム必須、Static Export 非対応）: https://nextjs.org/docs/app/guides/incremental-static-regeneration
  • Next.js 公式「revalidatePath」（特定パスのキャッシュをオンデマンドで無効化する API リファレンス）: https://nextjs.org/docs/app/api-reference/functions/revalidatePath