SPA / SSR / SSG の違い
SPA・SSR・SSG の 3 つのレンダリング方式を比較。どのタイミングで HTML を生成するか、パフォーマンス・SEO・インフラ要件がどう変わるかを一覧で整理。
時系列比較: HTML はいつ完成するか
3 方式を時系列上に並べると違いが一目で分かる。列は左から User → Server / CDN → Browser (初回 Paint) → JS Engine → Browser (2 回目 Paint) → Interactive の流れ。
SPA
SSR
SSG
リクエスト送信
サーバー処理
空 HTML シェル
ビルド時処理
JS DL + 実行
初回描画
操作可能
負荷はどこで発生するか
処理コストは「ビルド時 / サーバー / クライアント」のどこかに必ず発生する。3 方式の違いはこの配分の違いと言える。
SPA
SSR
SSG
比較一覧
| 観点 | SPA | SSR | SSG |
|---|---|---|---|
| HTML 生成タイミング | 初回のみサーバー (ほぼ空) / その後はブラウザ | リクエストごとにサーバー | ビルド時に全ページ |
| 配信形態 | JS バンドル + 空 HTML シェル | 動的 HTML (毎回レンダリング) | 静的 HTML ファイル (CDN 配信可) |
| 初回表示 (TTFB) | 速い (シェルのみ) / ただし FCP は遅い | 中 (サーバー処理に依存) | 非常に速い (CDN からそのまま配信) |
| SEO | CSR-only なら弱い / SSR・SSG 併用で補える | 強い (完成 HTML を返す) | 強い (完成 HTML を返す) |
| コンテンツの鮮度 | API 経由で常に最新 | リクエスト時点の最新 | ビルド時点 (再ビルドで更新) |
| サーバー要件 | 静的配信 + API サーバー | Node.js 等のアプリサーバー常時稼働 | 静的ホスティングのみ (S3 / CDN) |
| 代表フレームワーク | React, Vue, Angular, Svelte | Next.js, Nuxt, SvelteKit, Remix | Astro, Hugo, Jekyll, 11ty |
どれを選ぶか
SPA が適している場面
- ログイン後のダッシュボード / 管理画面 (SEO 不要)
- 複雑なフォーム・インタラクションが中心
- バックエンドが明確に API として分離している
- 初回表示より操作時の応答性を優先
SSR が適している場面
- ユーザー固有の内容 (EC サイトのカートやおすすめ)
- ログイン状態に応じて HTML を分岐させたい
- 頻繁に更新されるが SEO も必要 (ニュース・ブログコメント等)
- サーバー側で認証・認可チェックを先に済ませたい
SSG が適している場面
- ドキュメントサイト・ブログ・ポートフォリオ
- マーケティングサイト / ランディングページ
- 更新頻度が低い (再ビルドが現実的)
- コストとパフォーマンスを最優先 (CDN のみで完結)
よくある疑問
3 方式を学ぶときに混乱しやすい論点をまとめて整理。
Q. モダンフレームワーク (Next.js / Astro / Nuxt) は全方式に対応しているけど、どう選べばいい?
「サイトの性質」ではなく「ページの性質」で選ぶ。同じサイト内で、マーケページは SSG、ブログは ISR、ログイン後ダッシュボードは SPA (CSR)、API 依存の動的ページは SSR、という風にページ単位で使い分けるのが推奨運用。Next.js や Nuxt は各ページに
export const dynamic = ... や export const revalidate = ... で指定できる。「サイト全体で 1 つ選ぶ」という考え方は古い。Q. 「最初に何を選べばいい?」という質問にデフォルトの答えはある?
「まず SSG で作り、必要になったら SSR / ISR / CSR を足していく」が現代のデフォルト。理由は (a) SSG が最もシンプルで障害耐性が高い、(b) ほとんどのページは実は静的で構わない、(c) 動的にしたくなったときに個別に変換できる。最初から SSR にすると、不要なサーバー複雑性を全ページに強いることになる。ただし「ログイン後のプロダクト」が主戦場なら最初から SPA or SSR で始めるのが自然。
Q. 「ハイドレーション」という言葉は SPA / SSR / SSG どこで出てくる?
SSR と SSG の両方。SPA には出てこない。ハイドレーションは「サーバー or ビルド時に生成された HTML を、クライアント JavaScript が再利用してインタラクティブにする」プロセスなので、完成 HTML を返す SSR / SSG で必要になる。SPA は空の HTML からブラウザが全てを描画するので、再利用する既存 HTML が無く、ハイドレーションも存在しない。
Q. ISR は SSG とも SSR とも違うの?
SSG の拡張。ベースは SSG (ビルド時生成 + CDN 配信) だが、「ページ単位で後から再生成できる」仕組みを足した形。再生成のトリガーは (a) 時間ベース (revalidate)、(b) オンデマンド (Webhook) の 2 つ。SSR のように毎リクエストで計算するわけではなく、再生成は「必要なときだけ」。Next.js / Vercel エコシステムの機能で、他フレームワークは類似機能を後追い実装している (Astro の
swr 戦略など)。Q. JAMstack って SSG のこと?
ほぼ同義で使われることが多いが、厳密には違う概念。JAMstack = JavaScript (クライアント) + API + Markup (事前ビルド) という「アーキテクチャのパターン」。SSG はそのうち「Markup の事前ビルド」を指す具体的な実装。「JAMstack」と言うときは「静的マークアップ + CDN 配信 + API で動的部分を補う設計思想」全体を指していることが多い。SSG + ISR + Edge Function の混成も広義の JAMstack。
Q. 結局、パフォーマンスが一番速いのはどれ?
「何の指標で見るか」による。TTFB と LCP (初回表示関連) は SSG が有利 — web.dev「Rendering on the Web」の Static rendering 節は「fast First Paint, First Contentful Paint and Time To Interactive」を提供すると説明している通り、CDN から静的 HTML を直接配信する構造ゆえ。TTI (操作可能までの時間) は SSR と SSG はハイドレーション時間分の差が出るが、ハイドレーション処理が同じなら同等。連続操作のレスポンス (リンクをクリックしてから次の画面が出るまで) は SPA がサーバー往復不要なため速い。つまり「初回表示 = SSG、操作 = SPA、両立 = SSR + ハイドレーション最適化」という整理。
実際には混在する
モダンなメタフレームワーク (Next.js・Astro・Nuxt など) は 1 つのプロジェクト内でページ単位に SPA / SSR / SSG を切り替えられる。「このサイトは SSG」と決めるより、「記事ページは SSG、ログイン後の管理画面は SPA、決済確認は SSR」のようにページ単位で使い分けるのが一般的。