はじめに
フロントエンドを触っていると、避けては通れない三文字がある。CSR と SSR だ。
にもかかわらず、この二つは驚くほど雑に語られる。技術記事、勉強会、レビュー、設計相談――どこでもだ。
- CSR は SPA のこと
- SSR は とにかく速い
- SEO を考えるなら SSR 一択
正直に言おう。その理解のまま設計の話に入るのは危険だ。
なぜなら CSR / SSR は流行りのフレームワーク選定の話ではなく、計算資源と責務分割の設計論だからだ。ここを取り違えると、速度も保守性も両方失う。
この記事では「CSR とは？ SSR とは？」という初歩的な問いを扱うが、ゴールは用語暗記ではない。
- 何が起きているのか
- どこでコストが発生しているのか
- なぜ現代フロントエンドは複雑になったのか
これらを構造的に整理する。
まず前提：レンダリングとは何か
話を急ぐ前に、一度だけ足場を固める。
レンダリングとは、状態から UI を生成する処理である。
DOM を作るとか、HTML を吐くとか、それは全部「結果」であって本質ではない。重要なのは「どこで」「いつ」状態から UI を組み立てるかだ。
ここで初めて CSR / SSR の違いが意味を持つ。
CSR（Client Side Rendering）とは
一言で言うと
「UI を作る計算をブラウザに押し付ける設計」だ。
CSR はこう定義できる。
UI を生成する主たる責務がクライアントにあるレンダリング方式
サーバは基本的に空に近い HTML と JavaScript バンドルを返す。React, Vue, Svelte などがブラウザ上で起動し、
- JS をロードする
- 状態を初期化する
- 仮想 DOM なり何なりを評価する
- DOM を構築する
という一連の処理を クライアントで 行う。
CSR の特徴
- 初回表示までに JS 実行コストが必ず乗る
- インタラクション後の遷移は極めて速い
- クライアント状態を中心に設計しやすい
- サーバは薄く、スケールしやすい
よくある誤解
CSR は遅い
違う。初回表示が遅くなりやすい設計になりがちなだけだ。適切なコード分割、キャッシュ、HTTP/2 以降の前提を無視して「CSR は遅い」と言うのは、ブレーキを踏んだまま車が遅いと言っているのと同じ。
SSR（Server Side Rendering）とは
一言で言うと
「UI を作る計算をサーバで肩代わりする設計」だ。
SSR はこうだ。
UI を生成する主たる責務がサーバにあるレンダリング方式
リクエストを受けたサーバは、状態を解決し、その場で HTML を生成して返す。ブラウザはそれを「描画するだけ」の存在になる。
Next.js が代表例だが、Rails, Laravel, Django など、歴史的にはこちらが“普通”だった。
SSR の特徴
- 初回表示が速くなりやすい（HTML が即描画可能）
- SEO や OGP が扱いやすい
- サーバ負荷は上がる
- 状態管理が複雑になりやすい
よくある誤解
SSR は SEO に強い
これも半分正解で半分雑。「クローラが JS を実行しなくても意味のある HTML が取得できる」ことが本質だ。CSR でもプリレンダリングや動的レンダリングを噛ませれば解決する場合は多い。
ハイドレーションという地獄
SSR を語る上で避けて通れないのが Hydration だ。
SSR + モダンフレームワークでは、
- サーバで HTML を生成
- クライアントで同じ UI を再計算
- DOM とイベントハンドラを紐づける
という二度手間が発生する。
これが何を意味するか。
- SSR は「タダで速くなる魔法」ではない
- クライアントの JS 実行コストは消えない
- 不整合が起きると即バグる
SSR は設計力と理解力を要求する選択だ。
じゃあ結局どっちを選ぶのか
この問い自体が雑だ。正しくはこう。
どのレンダリング責務を、どこに、どの粒度で置くか
現代の答えは「混ぜる」だ。
- 初回表示は SSR / SSG
- その後の遷移は CSR
- 重要なページだけサーバで描画
Next.js, Nuxt, Remix がやっているのは、魔法ではなく責務分割の整理に過ぎない。
よくあるツッコミへの先回り回答
「それって SSG や ISR はどこに入るの？」
SSR / CSR はレンダリングの実行場所の分類だ。一方、SSG や ISR は実行タイミングの最適化である。
- SSG: ビルド時にサーバで HTML を生成
- ISR: キャッシュ更新を伴う SSG
どちらも「サーバで UI を生成している」点では SSR の親戚だが、リクエスト時に計算するかどうかが違う。
「最近はクローラも JS 実行できるよね？」
できる。だができることと、安定して期待できることは別だ。
- 実行時間制限
- リソース制約
- 未対応 API
これらを前提にすると「意味のある HTML を最初から返す」価値は今も残る。SSR の価値は SEO だけではなく、初期状態の確実性にある。
「SSR なら Core Web Vitals 良くなる？」
ならない場合も多い。特に LCP は改善しやすいが、
- Hydration 遅延
- JS バンドル肥大
- サーバレス cold start
が絡むと簡単に悪化する。SSR = 高スコアという短絡は危険だ。
「全部 SSR にすればよくない？」
その設計はだいたい次の三点で破綻する。
- サーバコスト
- キャッシュ戦略の複雑化
- 状態同期の地獄
SSR は強力だが、乱用すると設計負債になる。
まとめ
- CSR / SSR は速度論ではない
- 責務と実行場所の話である
- SSR はシルバーブレッドではない
- 正解はプロダクト要件ごとに異なる
レンダリング方式を語るとき、流行りやフレームワーク名から入るのはやめよう。計算はどこで走り、誰が責任を持つのか。そこから考えれば、自ずと答えは見える。
もし次に「とりあえず Next.js にしときましょう」と言うときがあったら、その前に、この記事を思い出してほしい。
以上。
もし良い記事と思ったらいいね、ストック、フォローお願いします🙇