CSRとSSRの違いと使い分け｜レンダリング方式を比較して実装で選ぶ

CSR（クライアントサイドレンダリング）とSSR（サーバーサイドレンダリング）は、Webページの見た目をどこで組み立てるかが違う。CSRはブラウザ上のJavaScriptが画面を作り、SSRはサーバーが完成したHTMLを返す。この差が初期表示の速さ、SEO、認証の設計、サーバー負荷に効いてくる。ただし現在のフレームワークでは片方だけを選ぶ必要はなく、ページやコンポーネントの性質に応じて混在させるのが実務の答えになっている。この記事では両者の違いを観点ごとに比較し、ページ別の使い分けと、SSGやISR・Next.jsとの関係までまとめる。

まとめ：CSRとSSRの結論

CSRは「ブラウザで描画」、SSRは「サーバーで描画」。SEOと初期表示を優先する公開ページはSSR（更新頻度が低ければSSG、準静的ならISR）、認証済みでSEO不要な管理画面やダッシュボードはCSR、というのが基本の分け方だ。SSRは初回のHTMLが速い代わりにサーバー負荷とTTFBが増え、CSRは初期表示が遅い代わりにサーバーが軽くページ遷移が速い。最も外しやすい誤解は「CSRはSEOに使えない」で、実際はGooglebotがJavaScriptを実行するためインデックス自体は可能だが、レンダリングの遅延やSNSのOGPプレビュー欠落という別の問題が残る。以降で各観点を具体的に見ていく。

CSRとSSRとは｜レンダリング方式の基本

レンダリングとは、データやコンポーネントから実際に画面へ表示するHTMLを組み立てる処理を指す。この処理をブラウザで行うのがCSR、サーバーで行うのがSSRで、どちらもSPA（シングルページアプリケーション）やReact・Vueといった同じ部品から構成できる。両者は排他ではなく、同じアプリの中でページごとに選べる。

CSR（クライアントサイドレンダリング）の描画フロー

CSRでは、サーバーは中身がほぼ空のHTMLとJavaScriptバンドルを返す。ブラウザがそのJavaScriptを実行し、APIからデータを取得してDOMを構築することで画面が表示される。ReactやVueで作る典型的なSPAがこの方式で、初回は白い画面のあとに一気に描画される挙動になりやすい。一度読み込んだあとの画面遷移は、差分だけを描き替えるため速い。SPAの全体像はSPAとは？フロントエンド技術の全体像・フレームワーク・将来性で整理している。

SSR（サーバーサイドレンダリング）の描画フロー

SSRでは、リクエストのたびにサーバーがデータを取得して完成したHTMLを生成し、ブラウザへ返す。ブラウザは受け取ったHTMLをそのまま描画できるため、初回表示にJavaScriptの実行を待たない。描画後にJavaScriptが読み込まれ、静的なHTMLへイベントリスナーを結び付けて操作可能にする。この後処理をハイドレーションと呼び、SSRの体感速度とINP（操作への応答性）を左右する。

CSRとSSRの違い｜観点別の比較

CSRとSSRは「どちらが優れているか」ではなく、負荷とタイミングをどこに寄せるかのトレードオフだ。主要な観点を並べると差がはっきりする。

要点は初動の性質が逆になることだ。CSRはサーバーが軽いHTMLをすぐ返すのでTTFBは速いが、そこから画面が見えるまでにJavaScriptのダウンロードと実行が挟まり、利用者が体感する初期表示は遅れる。SSRはサーバー側でHTMLを組み立てる分だけ最初の応答に時間がかかるが、返ってきた時点で画面が見えるため体感は速い。動的なやり取りが多い管理系ならCSR、初回の速さと検索露出が売上に直結する公開ページならSSRが基本線になる。

CSRとSSRの使い分け｜ページ性質別の判断基準

方式はサイト単位ではなくページ単位で決める。判断軸は「SEOが要るか」「認証済みか」「更新頻度」の3つで、この掛け合わせでほぼ決まる。SEOが要らず認証済みならCSR、SEOが要るなら更新頻度で静的寄り（SSG／ISR）かSSRかを選ぶ、という順に考えると迷いにくい。なお下表の推奨方式にはSSG・ISRも含めた（公開ページは静的寄りが第一候補、動的かつSEOが要るならSSR、SEO不要はCSR、という実務の基準に沿うため）。SSG・ISRの詳細は後半の委譲先で扱う。

SSR（またはSSG／ISR）を選ぶべきケース

検索流入が売上や集客に直結する公開ページは、迷ったらサーバー側で描く方式にする。商品詳細のように内容がリクエストごとに変わり、かつSEOも欲しいページはSSRが素直だ。内容が固定でアクセスが多いトップページや特集はSSG、記事一覧のように準静的で定期更新するページはISRが向く。判断に迷ったら「初回の1画面を確実に速く、検索エンジンにそのまま読ませたいか」を基準にすると外しにくい。

CSRを選ぶべきケース

ログイン後の管理画面・ダッシュボード・社内ツールは、CSRで割り切ってよい。認証済みのためSEOは不要で、フィルタやドラッグ操作など状態を持つUIが中心になるからだ。ここを無理にSSRにすると、リクエストごとにサーバーで認証と描画を繰り返してコストだけが増える。逆に「公開ページなのでとりあえずCSR」は避けるべき失敗パターンで、初期表示の遅さと後述のSEO上の不確実さをそのまま抱え込むことになる。

レンダリング方式とSEOの正確な関係

「CSRはSEOに弱い」は広く言われるが、実態を正確に切り分けないと判断を誤る。ここは意見が割れやすいので、事実ベースで言い切っておく。CSRのページも検索結果に出せる。ただし出るまでの確実性とプレビュー表示が犠牲になる、というのが正しい理解だ。

CSRのインデックスの実態

Googlebotはページを2段階で処理する。まずHTMLをクロールし、そのあとレンダリングキューでJavaScriptを実行してから最終的なコンテンツを評価する。したがってCSRのページもインデックスされ得るが、レンダリングは後回しになるため反映が遅れやすく、JavaScriptの実行エラーやクロールバジェットの制約でコンテンツが正しく取得されないリスクが残る。更新の即時性や大量ページの網羅性が重要なサイトほど、この不確実性が効いてくる。

OGP・SNSプレビューの制約

見落とされがちなのがSNS側の挙動だ。X（旧Twitter）やFacebook、Slackなどのクローラは、Googlebotと違ってJavaScriptを実行しない。CSRでタイトルやOGP画像をJavaScriptから差し込む設計だと、シェア時のプレビューが空になる。SNS流入を重視するなら、この一点だけでもSSRやプリレンダリングを選ぶ理由になる。検索エンジンだけでなく、メタ情報を読む機械の存在まで含めて設計する必要がある。

パフォーマンスとCore Web Vitals｜初期表示とハイドレーション

体感速度はGoogleのCore Web Vitalsで評価され、指標はLCP（最大コンテンツの表示）、INP（操作への応答性）、CLS（レイアウトのずれ）の3つだ。INPは2024年3月にFIDに代わって正式指標になった。CSRとSSRはこれらの指標に対して異なる弱点を持つ。

初期表示（LCP・TTFB）の違い

SSRは完成HTMLを返すためLCPで有利だが、サーバー処理が重いとTTFBが伸び、結果的にLCPを押し下げることがある。CSRはTTFBこそ速いが、JavaScriptのダウンロードと実行を待つためLCPが遅れやすい。SSRを選んでも、サーバー側のデータ取得が遅ければ速さの利点は消える。方式選定と同じくらい、データ取得やキャッシュの設計がLCPを左右する。

ハイドレーションのコストと対策

SSRの隠れたコストがハイドレーションだ。サーバーが返したHTMLは見た目こそ完成しているが、JavaScriptがイベントを結び付けるまでボタンやフォームは反応しない。バンドルが大きいほどこの待ち時間が伸び、INPの悪化として現れる。対策として、React Server Components（サーバーで完結しクライアントへJavaScriptを送らないコンポーネント）やストリーミングSSR、必要な部分だけをハイドレートするアイランド構成が使われる。SSRを採用するなら、HTMLを速く返すだけでなく、送り込むJavaScriptを減らす設計までがセットになる。

認証・トークン管理での違い｜Cookieセッションとトークン

描画場所が違えば、認証情報をどこに持たせるかも変わる。ここは方式選定と一緒に決めておかないと、後からセキュリティ設計がねじれる。

CSRでは、ログイン後に受け取ったJWTなどのトークンをブラウザ側（メモリやストレージ）で保持し、API呼び出しのAuthorizationヘッダに載せて送るのが一般的だ。柔軟な反面、トークンをJavaScriptから読める場所に置くとXSS（クロスサイトスクリプティング）で盗まれる経路が生まれる。SSRでは、HttpOnly属性を付けたCookieにセッションIDやトークンを入れ、サーバーが検証する。JavaScriptから読めないためXSSでの窃取に強いが、Cookieが自動送信される性質上CSRF（クロスサイトリクエストフォージェリ）対策としてSameSite属性やCSRFトークンが必要になる。認証済み画面はCSR、機密性の高いセッションはSSR側のHttpOnly Cookieで持つ、という組み合わせが現実的な落としどころだ。具体的な実装はSpring Securityとは？認証・認可の仕組みと基本設定を参照してほしい。

二者択一ではない｜SSG・ISR・RSCを含む現在の選択肢

ここまで比較してきたが、現在のフロントエンドではCSRとSSRを対立軸で捉える枠組み自体が古くなっている。Next.jsのApp RouterはReact Server Componentsを既定とし、"use client"を付けた部分だけをCSR化する。つまり1つのページの中でサーバー描画とクライアント描画が混在する。静的部分を先に配信し動的部分を後からストリーミングするPPR（部分的プリレンダリング）も登場しているが、2025年時点では実験的機能で本番投入は慎重にすべき段階だ。NuxtもSSRを既定にしつつページ単位で切り替えられる。

方式の選択肢はSSRとCSRの2つにとどまらず、ビルド時に生成するSSGや、静的ページを一定間隔で再生成するISRを加えた複数から選ぶことになる。SSG・ISR・ISGまで含めた5方式の定義と速度・SEOの比較はSSR・CSR・SSG・ISG・ISRの違いと使い分けに、Next.jsでの具体的なレンダリング方法の実装はNext.jsにおける主要なレンダリング方法の種類と概要にまとめている。まず本記事で2者の軸を押さえ、実装段階でこれらを組み合わせるのが現実的な進め方だ。

よくある質問

CSRとSSRはどちらが速いですか？

速さの意味による。初回の初期表示はSSRが速く、一度読み込んだ後のページ遷移はCSRが速い。初回訪問での離脱を避けたい公開ページはSSR、操作を繰り返す画面はCSRが体感的に有利だ。

CSRはSEOに不利ですか？

インデックス自体は可能だが不利になりやすい。GooglebotはJavaScriptを実行するためCSRのページも検索結果に出せるが、レンダリングが後回しで反映が遅れ、SNSのOGPプレビューも空になりやすい。検索・シェア流入が重要ならSSRやプリレンダリングを選ぶ。

SSRとSSGの違いは何ですか？

HTMLを作るタイミングが違う。SSRはリクエストのたびにサーバーで生成し、SSGはビルド時にあらかじめ生成して静的配信する。更新頻度が低いページはSSG、内容がリクエストごとに変わるページはSSRが向く。SSGやISRを含む比較はSSR・CSR・SSG・ISG・ISRの違いと使い分けで詳しく扱っている。

SPAはCSRと同じですか？

同じではない。SPAは1つのページで画面遷移を完結させるアプリの構成を指し、CSRはその描画をブラウザで行う方式を指す。SPAをSSRで初回描画してからCSRに引き継ぐ構成も一般的で、両者は別の軸の概念だ。

Next.jsではCSRとSSRをどう使い分けますか？

App RouterではServer Componentsが既定で、インタラクティブな部分にだけ"use client"を付けてCSR化する。ページ単位・コンポーネント単位で混在させられるため、公開部分はサーバー描画、操作部分はクライアント描画と役割で分けるのが基本になる。

関連記事

• SSR・CSR・SSG・ISG・ISRの違いと使い分け｜定義・SEO・速度を比較
• Next.jsにおける主要なレンダリング方法の種類と概要
• SPAとは？フロントエンド技術の全体像・フレームワーク・将来性を解説【2026年版】
• Spring Securityとは？認証・認可の仕組みと基本設定をわかりやすく解説【2026年版】