SPA / SSR / SSG（レンダリング戦略）
HTMLを「どこで・いつ」組み立てるかの選択。ブラウザで作るか(SPA)、サーバで毎回作るか(SSR)、ビルド時に作り置きするか(SSG)で、表示速度・SEO・鮮度のバランスが変わる。
- 1.違いは「HTMLをどこで・いつ作るか」。CSR=ブラウザ / SSR=リクエストごとにサーバ / SSG=ビルド時に作り置き / ISR=作り置きを定期更新。
- 2.速い初期表示とSEOが欲しいならサーバ側(SSR/SSG)で完成HTMLを返す。リッチな操作性は結局JSが要る＝ハイドレーションのコストがつきまとう。
- 3.万能な正解はない。ページ単位で「内容が動的か」「SEOが要るか」「鮮度はどのくらいか」で使い分けるのが今の主流。
そもそも何を分けているのか
Webページが表示されるまでには、大きく2つの仕事があります。
- HTMLを生成する: データを当てはめて、最終的なHTML文字列を作る
- JSで動かす: ボタンや入力など、ページを操作可能（インタラクティブ）にする
この「HTML生成」を 誰が・どのタイミングで やるかが、レンダリング戦略の正体です。JSの実行はどの方式でもブラウザで起きますが、HTMLを ブラウザに任せるほど初期表示が遅く・SEOに不利 になり、サーバ側で先に完成させるほど速く・SEOに有利 になります。
4つの方式
| 方式 | HTMLを作る場所/タイミング | 初期表示 | 向くもの |
|---|---|---|---|
| CSR（SPA） | ブラウザ（JS実行後） | 遅め（空のHTML→JSで描画） | ログイン後の管理画面・ダッシュボード |
| SSR | サーバ（リクエストごと） | 速い（完成HTMLが届く） | 都度変わる動的ページ・要SEO |
| SSG | ビルド時（事前に作り置き） | 最速（静的ファイルを配るだけ） | ブログ・ドキュメント・LP |
| ISR | ビルド時＋一定間隔で再生成 | 最速（静的）かつ準リアルタイム | 更新頻度がほどほどの大量ページ |
CSR（Client-Side Rendering）＝ SPA
サーバは ほぼ空のHTML とJSバンドルだけを返し、ブラウザがJSを実行して画面を描きます。以降の画面遷移もページ全体を再読み込みせず、必要なデータだけ取得してJSで差し替える。これが SPA（Single Page Application） の体験です。
<!-- CSRで返ってくるHTMLは、だいたいこれだけ -->
<body>
<div id="root"></div>
<script src="/app.js"></script>
</body>
SPA はアーキテクチャ（1枚のページ内で遷移する作り）、CSR はレンダリング方式（HTMLをブラウザで作る）。両者は相性が良いだけで別概念です。実際、最近のフレームワークは SPA でありながら初回だけ SSR/SSG する ハイブリッドが主流。「SPA だから必ず CSR」ではありません。
SSR（Server-Side Rendering）
リクエストが来るたびにサーバがデータを取得し、完成したHTML を生成して返します。ブラウザは届いた時点で中身を表示できるので初期表示が速く、検索エンジンも内容を読めます。代償として、リクエストごとにサーバで処理が走るため サーバ負荷とTTFB（最初のバイトが届くまでの時間） に注意が要ります。
SSG（Static Site Generation）
ビルド時にすべてのHTMLを作り置き し、あとはその静的ファイルを配るだけ。CDNから配信でき、最速かつ最も安定。半面、内容を変えるには 再ビルドが必要 で、ユーザーごとに違う動的な内容には向きません。このサイトのような技術記事はSSGの典型です。
ISR（Incremental Static Regeneration）
SSGの弱点（鮮度）を補う方式。作り置きの静的ページを、一定間隔やアクセスを契機にバックグラウンドで再生成 します。「静的の速さ」を保ちつつ「ある程度の鮮度」も得られる中間解で、ページ数が多くフル再ビルドが重いサイトで効きます。
いつHTMLを作るか の一本軸で並ぶと整理できます。
ビルド時＝SSG → ビルド時＋定期更新＝ISR → リクエスト時＝SSR → ブラウザで＝CSR。
左ほど速く・鮮度が固定的、右ほど柔軟だが初期表示にコストがかかる、という連続したスペクトラムです。
ハイドレーション（落とし穴の本丸）
SSR/SSGで完成HTMLを返しても、それは 見えるだけの静止画 です。ボタンを押せる・入力できるようにするには、ブラウザがJSを読み込み、サーバが描いたHTMLにイベントや状態を“後付け” する必要があります。この処理が ハイドレーション（hydration / 水分補給） です。
SSR/SSG の典型的な流れ
1. サーバが完成HTMLを返す → 速く「見える」（が、まだ押せない）
2. ブラウザがJSバンドルを読む
3. ハイドレーション実行 → ここで初めて「操作できる」
つまり「速く表示される」と「速く操作できる」は別物。HTMLが見えてから実際に操作可能になるまでのラグ（TTI: Time to Interactive の遅れ）が、大きなJSを抱えるサイトの典型的な不満点です。
サーバが生成したHTMLと、ブラウザがJSで再構築した結果が 一致しない と、警告や表示崩れ（ハイドレーションミスマッチ）が起きます。よくある原因は「サーバとクライアントで結果が変わるもの」をそのままレンダリングすること。たとえば new Date() の現在時刻、Math.random()、window/localStorage 依存、ブラウザ拡張によるDOM書き換えなど。サーバとクライアントで同じ入力からは同じHTMLが出る ように保つのが鉄則です。
トレードオフを一枚で
| 観点 | CSR(SPA) | SSR | SSG |
|---|---|---|---|
| 初期表示 | △ 遅い（JS待ち） | ○ 速い | ◎ 最速 |
| SEO/OGP | △ 不利（JS実行前は空） | ◎ 有利 | ◎ 有利 |
| データ鮮度 | ◎ 常に最新を取得 | ◎ リクエスト毎に最新 | △ ビルド時点で固定 |
| サーバ負荷/コスト | ◎ 低い（配るだけ） | △ 高い（毎回生成） | ◎ 低い（配るだけ） |
| 操作の俊敏さ | ◎ 遷移が速い | ○ 良い | ○ 良い |
クローラはJSを実行することもありますが、実行は遅延・不確実 で、SNSの OGP（リンクプレビュー）取得botの多くはJSを実行しません。空のHTMLが返ると、タイトルや説明が拾われない事故が起きます。SEOやシェアが重要なページは、サーバ側で <title> やメタ情報を含む完成HTMLを返す（SSR/SSG）のが堅実です。
どう選ぶか
迷ったら、ページ単位で 次の3問に答えます。
- SEO / リンクプレビューが要るか？ → 要るなら SSR か SSG（公開ページ・記事・LP）
- 内容はユーザーやリクエストで変わるか？ → 変わるなら SSR、固定ならSSG
- 鮮度はどのくらい必要か？ → 数分の遅れが許せるなら ISR、常に最新ならSSR
たとえば、ログイン後の管理画面はSEO不要・常に最新が欲しいので CSR(SPA)、トップや記事は SSG、ユーザーごとに出し分けるページは SSR、ニュース一覧のように大量＆ほどほどの鮮度なら ISR ——というように 1サイト内で混在 させるのが現実的な最適解です。
あるページがどの方式かは、ブラウザで 「ページのソースを表示」（View Source） を見れば見当がつきます。ここはJS実行 前 の生HTMLなので、本文がぎっしり入っていればSSR/SSG、<div id="root"> がほぼ空ならCSR。DevToolsの「Elements（要素）」はJS実行 後 のDOMなので、両者を見比べると理解が深まります。描画の仕組み自体は ブラウザのレンダリング を参照。
まとめ
- CSR(SPA): ブラウザで描く。アプリ的な操作性が強み、初期表示とSEOは弱点。
- SSR: リクエストごとにサーバで描く。速い初期表示とSEO、代わりにサーバ負荷。
- SSG: ビルド時に作り置き。最速・最安・最も安定、代わりに鮮度は固定。
- ISR: 作り置きを定期更新。静的の速さと準リアルタイムの折衷。
- 完成HTMLを返す方式には ハイドレーション が必ず付いてくる。「見える」と「操作できる」は別物。
レンダリング方式はクライアント・サーバ間の通信に乗って成立します。土台となる HTTP/HTTPS、データ取得の REST API、別オリジン取得でつまずく CORS も合わせて押さえると、全体像がつながります。
Web/フロントエンド Article
SPA / SSR / SSG（レンダリング戦略）を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
レンダリング
比較で見る軸
難易度: intermediate / カテゴリ: Web/フロントエンド / タグ数: 4
導入後に効く点
速い初期表示とSEOが欲しいならサーバ側(SSR/SSG)で完成HTMLを返す。リッチな操作性は結局JSが要る＝ハイドレーションのコストがつきまとう。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- intermediate
- カテゴリ
- Web/フロントエンド
- タグ数
- 4
判断チェックリスト
- 自社の用途が「レンダリング / SPA」に近いか確認する。
- 強みである「違いは「HTMLをどこで・いつ作るか」。CSR=ブラウザ / SSR=リクエストごとにサーバ / SSG=ビルド時に作り置き / ISR=作り置きを定期更新。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。