SPA・SSR・SSGを理解して「使い分ける」までの話
どうも。初投稿です。
まだまだ駆け出しですの私ですが、積極的に記事を書きなさいという尊敬するエンジニア様より金言をいただきましたので投稿してみます。
さて、以前の自分は、Next.jsやReactでアプリを作りながらも、
「SPA・SSR・SSGの違い」はなんとなく知っている程度で、
正直なところ“どれが正解なのか”よく分かっていませんでした。
今作っているものと、依然作ったもので動きが違うのに、
そういう書き方もあるんやな、くらいの認識でした。
しかし、講座など含めてたまたまSPAで動くものとSSRで動くものを作っていたので、
その違いを比べることである程度理解が進みました。
この記事では、半分備忘録として「どう使い分けるのか」を整理します。
つまり「使い分ける」の実践はこれからです……頑張ります。
そもそも何が違うのか
3つの違いはシンプルに言うとこうです。
👉 「HTMLをいつ作るか」
- SPA：ブラウザで作る
- SSR：リクエストごとにサーバーで作る
- SSG：ビルド時に作っておく
SPA（Single Page Application）
最初に触れたのがこの形でした。
講座受けつつSNS風アプリを作ったときの構成がまさにこれです。
特徴
- 初回はローディングが出る
- データ取得はブラウザ側（useEffectなど）
- 画面遷移が滑らか（再読み込みなし）
実際の流れ
- ページ表示（ほぼ空 or Loading）
- ブラウザで認証チェック
- APIからデータ取得
- state更新 → UI描画
向いている用途
- ログイン後の画面
- SNS・管理画面
- インタラクティブなアプリ
SSR（Server Side Rendering）
次に触れて理解が変わったのがこれです。
Next.jsでセッションをサーバー側で取得したときに実感しました。
特徴
- 初回表示が速い（HTMLが完成して届く）
- SEOに強い
- リクエストごとに内容が変わる
実際の流れ
- リクエスト
- サーバーでデータ取得
- HTML生成
- ブラウザに返す
- その後JSでインタラクティブ化（ハイドレーション）
向いている用途
- 記事ページ
- 商品ページ
- 一般公開ページ
SSG（Static Site Generation）
これはさらに極端な形です。
ほぼ内容が固定のページで使うということみたいですね。
実際にこれを意識して作ったことがないので調べた内容のメモです。
特徴
- ビルド時（デプロイ）にHTMLを生成して保存
- 表示速度が最速
- サーバー処理ほぼ不要
向いている用途
- ブログ
- LP
- 更新頻度が低いページ
認識が変わったポイント
最初はこう考えていました。
❌ 「SPAかSSRかどちらかを選ぶもの」
というか、どっちを使うかあんまり意識してませんでした。
しかし実際は違いました。
👉 「ページごとに使い分けるもの」
実務的な使い分け
実際のアプリはこうなるべきのようです。
公開ページ
→ SSR / SSG
- SEOが必要
- 初回表示が重要
ログイン後
→ SPA
- UX重視
- データ更新が多い
👉 1つのアプリの中で共存するのが普通
Next.jsの本質
ここで理解が一段深まりました。
👉 Next.jsは“全部できるフレームワーク”
- サーバーコンポーネント → SSR的
- クライアントコンポーネント → SPA的
- ビルド時生成 → SSG
実装レベルでの違い
SPA
"use client";
useEffect(() => {
fetchData();
}, []);
ページの表示が終わってからuseEffectでＡＰＩ通信して中身を作る、
ということは理解できていたのでここが違うと説明されてやっと
ブラウザ側でデータ取得する、という意味を理解できました。
SSR（Next.js）
export default async function Page() {
const data = await fetch(...);
return <div>{data}</div>;
}
対してこちらはコンポーネントの中でデータ取得してきてHTMLを返すので、
データを取得するまでページが表示されないから、スケルトンを作ったりし
ＵＸを担保するのだ、ということが理解できました。
（ローディング対策でスケルトンで枠だけ表示したり対策していた）
👉 この違いは
「どこで実行されるか（ブラウザ or サーバー）」
今の自分の結論
👉 正解は「使い分けること」
判断基準（どんなページに使うか）
実際の開発では、「SPA / SSR / SSGのどれを使うか」は
ページの性質によって判断します。
■ SPAを使うべきケース（UX重視）
👉 操作性・リアルタイム性が重要なページ
具体例
- マイページ / ダッシュボード
- SNSのタイムライン
- 管理画面（投稿・編集・削除など）
- チャット画面
理由
- ユーザー操作が多い
- 画面更新が頻繁
- 再読み込みがあるとストレスになる
■ SSRを使うべきケース（初速・SEO重視）
👉 初回表示と検索流入が重要なページ
具体例
- 記事詳細ページ
- ECサイトの商品ページ
- サービス紹介ページ
- ユーザーごとに内容が変わる公開ページ
理由
- 最初から内容が表示される必要がある
- SEO対策が必要
- SNSシェア時に内容を表示したい
■ SSGを使うべきケース（速度・安定性重視）
👉 内容がほぼ固定で更新頻度が低いページ
具体例
- LP（ランディングページ）
- ブログ記事（頻繁に更新しないもの）
- 会社概要ページ
- 利用規約・プライバシーポリシー
理由
- 毎回生成する必要がない
- 高速に配信できる
- サーバー負荷がほぼない
■ 実務での使い分けイメージ
1つのサービスの中でも、こう使い分けます。
- トップページ → SSG
- 記事ページ → SSR
- ログイン後のダッシュボード → SPA
👉 ページごとに最適な方式を選ぶのが基本
■ 判断のシンプルな基準
迷ったときはこの3つで考えます。
- SEOが必要か？ → SSR / SSG
- 初回表示を速くしたいか？ → SSR / SSG
- 操作性・体験を重視するか？ → SPA
👉 最終的には
「ユーザーにとって一番良い体験になるか」で決めるのが重要です。
まとめ
- SPA：体験（UX）重視
- SSR：初速・SEO重視
- SSG：速度・安定性重視
そして一番重要なのは👇
👉 「どれを使うか」ではなく「どこに使うか」
おわりに
実際にSPAとSSRの両方を触ったことで、
「なんとなくの理解」から「設計として考える」段階に進めたと感じています。
さしあたっては今メインで制作中の個人製作プロダクトの、
レンダリングをページごとに使い分けて実装しなおしです。
まだ使い分けできてません(-_-;)
今後は、機能単位でレンダリング方法を選べるように、
さらに設計の精度を上げていきたいと思います。
おい、理解が間違っているぞ！ などご意見ありましたらよろしくお願いします。