まず結論
SSRは、アクセス時にサーバでHTMLを作る必要があるページで使います。
すべてのページをSSRにする必要はありません。会社概要、ブログ、ドキュメントのようなページはSSGで十分なことが多いです。
この記事はSSRを採用するかの判断に絞ります。4方式の定義はSSG・SSR・ISR・CSRの違い、静的・動的という用語は静的サイトと動的サイトの違いを先に確認してください。
SSRが向いているページ
SSRが必要になりやすいのは、リクエストごとに内容が変わるページです。
例:
- ログイン後のマイページ
- ユーザーごとのダッシュボード
- 在庫や価格が頻繁に変わる商品ページ
- 検索条件に応じた一覧
- Cookieや認証状態で表示が変わるページ
このようなページは、ビルド時にHTMLを作り切れません。
SSGで十分なページ
SSGが向いているのは、事前にHTMLを作れるページです。
例:
- ブログ記事
- 用語解説
- 会社概要
- 料金ページ
- ドキュメント
- よくある質問
更新時にビルドし直せばよいページは、SSGでシンプルに配信できます。
判断基準
| 質問 | yesなら |
|---|---|
| ユーザーごとに内容が変わるか | SSR候補 |
| 認証が必要か | SSRまたはCSR候補 |
| 秒単位で最新性が必要か | SSR/API候補 |
| SEOにHTMLが必要か | SSRまたはSSG |
| 事前に全ページを作れるか | SSG候補 |
| CDNでキャッシュしやすいか | SSG候補 |
まずは、ページごとに考えます。
SSRのコスト
SSRには利点がありますが、コストもあります。
- サーバ実行環境が必要
- リクエストごとに処理が走る
- キャッシュ設計が必要
- サーバエラーの可能性がある
- デプロイ構成が複雑になる
静的サイトで済むページまでSSRにすると、運用が重くなることがあります。
CSRとの関係
ログイン後の管理画面などは、CSRでも作れます。
最初にHTMLの土台を配り、ブラウザ側でAPIを呼んで画面を作ります。
HTML shell
-> JS
-> API
-> render
SEOが重要でない管理画面では、CSRが現実的なこともあります。
よくある設計
| ページ | 向いている方式 |
|---|---|
| トップページ | SSG |
| ブログ記事 | SSG |
| 商品詳細 | SSG / ISR / SSR |
| 検索結果 | SSR / CSR |
| マイページ | SSR / CSR |
| 管理画面 | CSR |
ポイント: SSRは万能な高級機能ではなく、リクエスト時にHTMLを作る必要がある時の選択肢です。
SSRを選ぶ前に分ける四つの要件
最初に「初回応答で必要な内容」「利用者ごとに異なる内容」「何秒まで古くてよいか」「検索や共有リンクから読まれる内容」を分けます。ニュース本文が全員共通で数分の遅れを許すならSSGやISRが候補です。ログイン直後の氏名だけが個別なら、本文を静的にし、その小さな領域をCSRで取得できます。ページに動的な部分が一つあるだけで、ページ全体をSSRへ移す必要はありません。
| ページ | 主な要件 | 第一候補 | SSRを再検討する条件 |
|---|---|---|---|
| 会社概要 | 全員同じ、低頻度更新 | SSG | ほぼない |
| 記事詳細 | 公開本文、更新あり | SSG/ISR | 公開直後の厳密反映 |
| 検索結果 | URLごと、頻繁な条件変更 | SSR/CSR | 初期結果の検索流入 |
| 学習ダッシュボード | 個別データ | CSR | 初期表示速度やJS制約 |
| 招待リンク | トークンごとの判定 | SSR | 静的殻とAPIで十分ならCSR |
| 在庫表示 | 最新性が重要 | API併用 | HTML生成だけに頼らない |
よくある誤解
「SEOならSSR」は短絡です。全員共通の公開情報はSSGでもHTMLに含められます。「ログインがあるならSSR」も同様で、静的な画面骨格と認証済みAPIで実現できます。「常に最新ならSSR」でもなく、SSRが古いキャッシュや遅れたDBを読めば古いままです。SSRが保証するのは要求時に生成処理を走らせる機会であり、データの正しさや速さそのものではありません。
動作確認：必要性を測る
候補構成を同じページで比較し、初期HTMLに必要情報があるか、TTFB、操作可能までの時間、更新反映、障害時の表示を測ります。匿名、ログイン済み二人、期限切れセッションで応答とキャッシュヘッダーを確認し、個別情報が共有されないことを検証します。
SSRを採用したら、DB遅延、外部API停止、生成タイムアウトを再現します。静的方式なら、更新失敗時に以前のHTMLを配れるか、緊急訂正を何分で反映できるかを試します。方式の採否は流行ではなく、要件を満たす実測値と運用手順で決めます。
まとめ
SSRは、ユーザーごとに変わる、認証状態で変わる、アクセス時点の最新データが必要なページに向いています。
事前にHTMLを作れるページは、SSGの方が速く、安く、運用しやすいことが多いです。
