まず結論
SSRは、アクセス時にサーバでHTMLを作る必要があるページで使います。
すべてのページをSSRにする必要はありません。会社概要、ブログ、ドキュメントのようなページはSSGで十分なことが多いです。
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は、ユーザーごとに変わる、認証状態で変わる、アクセス時点の最新データが必要なページに向いています。
事前にHTMLを作れるページは、SSGの方が速く、安く、運用しやすいことが多いです。
次に読む記事
← 一覧に戻るPR
PR
