CSR vs SSR vs SSG vs streaming: パフォーマンスのトレードオフは？

Question

IT Interview Practice · Accepted Answer

レンダリング戦略は、HTMLが*どこで、いつ*構築されるかを決め、それが読み込み指標を左右します。普遍的なベストはありません。コンテンツがどれだけ動的でパーソナライズされているかに合わせます。

## 各戦略

```text
CSR      Server sends near-empty HTML + JS ──▶ browser fetches data ──▶ renders   (slow first paint)
SSR      Server renders full HTML per request ──▶ browser shows it ──▶ hydrates   (fresh, TTFB cost)
SSG      HTML built ONCE at deploy ──▶ served from CDN ──▶ hydrates               (fastest, static)
Stream   Server flushes HTML in chunks as ready ──▶ shell first, data fills in    (fast TTFB + fresh)
```

- **CSR（クライアントサイド）** — 空のシェル + JSを送り、ブラウザがデータを取得して描画します。ホスティングは安価ですが、コンテンツがJSを待つため、LCPとSEOが貧弱です。
- **SSR（サーバーサイド）** — リクエストごとに完全なHTMLを描画します。速く、SEOに優しい初回描画で常に最新ですが、TTFB（リクエストごとのサーバー処理）が増え、依然としてハイドレーションが必要です。
- **SSG（静的）** — ビルド時に描画し、CDNから配信します。最良のTTFB/LCPですが、コンテンツは最後のビルド時点の鮮度しかありません。**ISR** は定期的/オンデマンドの再ビルドを加えます。
- **Streaming SSR** — HTMLのシェルを即座にフラッシュし、遅い部分をストリームします（React Suspense / `renderToPipeableStream`）。データ読み込み中もユーザーはコンテンツを見られます。

## 選び方

| コンテンツ | 最適 |
|---------|----------|
| マーケティング、ドキュメント、ブログ | SSG（+ ISR） |
| パーソナライズ、リクエストごと | SSR / streaming |
| 認証の背後の高度にインタラクティブなアプリ | CSR または SSR + islands |

## ハイドレーションのコスト（共通の落とし穴）

SSR/SSGは速く描画しますが、JSが**ハイドレート**するまでページはインタラクティブになりません。その隙間でINPが悪化します。部分的/漸進的ハイドレーションとReact Server Componentsは、より少ないクライアントJSを送り、その隙間を縮めるために存在します。

## なぜ重要なのか

シニアには、1つを教条的に選ぶのではなく、サーフェスごとにこのトレードオフを推論することが期待されます。鋭い洞察は、速い描画（SSR/SSG）が速いインタラクティブ性を意味しないことです。ハイドレーションが隠れた税であり、ストリーミング + サーバーコンポーネントが両方を得るための現代的な答えなのです。

コンテンツ	最適
マーケティング、ドキュメント、ブログ	SSG（+ ISR）
パーソナライズ、リクエストごと	SSR / streaming
認証の背後の高度にインタラクティブなアプリ	CSR または SSR + islands

各戦略

選び方

ハイドレーションのコスト（共通の落とし穴）

なぜ重要なのか

関連する質問