CSR (Client-Side Rendering)

frontendwebrendering

HTML の組み立てをブラウザ上の JavaScript に委ねるレンダリング戦略。サーバー（や CDN）はほぼ空の HTML と JS バンドルを返すだけで、ユーザーが見るコンテンツは JS がダウンロード・実行され、API からデータを取得した後に初めて描画される。レンダリング戦略の一角で、SSR・SSG の対極。

仕組み

sequenceDiagram
    participant B as ブラウザ
    participant S as サーバー / CDN
    participant A as API
    B->>S: GET /
    S-->>B: 空の HTML + bundle.js への参照
    B->>S: GET bundle.js
    S-->>B: JS バンドル
    Note over B: JS パース・実行（ここまで画面は空白）
    B->>A: GET /api/data
    A-->>B: JSON
    Note over B: DOM 構築 → 表示 (FCP)・操作可能 (TTI)

サーバーが返す HTML は典型的にこれだけ:

<body>
  <div id="root"></div>
  <script src="/assets/bundle.js"></script>
</body>

表示までに 「HTML 取得 → JS 取得 → JS 実行 → データ取得 → 描画」の直列チェーンを全部待つ必要があり、これが CSR の遅さの構造的な理由。ネットワークだけでなく端末の CPU 性能にも比例するため、低スペック端末で特に悪化する。

なぜ生まれたか

動機説明
UI の滑らかさサーバー往復なしで画面を更新できる。フォーム・ドラッグ&ドロップ等のアプリ的操作
関心の分離フロントは静的ファイル、バックは JSON API。チーム・デプロイ・技術選定を分離できる
配信の安さビルド成果物は静的ファイルなので S3 + CDN に置くだけ。レンダリングサーバー不要
API の再利用同じ API をモバイルアプリと共有できる

弱点

向くケース

SEO が不要で、ログイン後の利用が前提のツール。管理画面・ダッシュボード・社内ツール・エディタ系アプリ。初回ロードのコストを一度払えば、あとはアプリ的な操作感が得られる。

逆にコンテンツサイト（ブログ・EC・メディア）には不向きで、そこは SSR / SSG の領分。

SPA との関係

SPA とは「画面づくりをブラウザに任せる」という同じ思想の仲間で、担当が違う — CSR は初回の HTML、SPA は 2 ページ目以降の遷移。だから「CSR + SPA」（Create React App, Vite + React Router）が古典形としてセットで広まった。ただし軸としては独立しているので、現代の主流は初回だけ SSR に差し替えた「SSR + SPA」（Next.js）という組み替え。

押さえどころ（カード化候補）

関連

Graph

Backlinks