
CSR(Client-Side Rendering)は、サーバが返すのは最小限の空HTMLとJavaScriptバンドルだけで、実際の画面はブラウザ側でJavaScriptが実行されてDOMが構築される描画方式です。AngularJS(2010年Google)、Backbone.js(同年Jeremy Ashkenas氏)、Ember.js(2011年)あたりから本格化し、ReactやVue.jsが定着させたモダンSPAの標準的な動作モデルでもあります。サーバを軽くできる反面、初回表示の遅さとSEO面の難しさが付きまといます。
この記事の目次
- ブラウザがDOMを組み立てる仕組み
- CSRが向く画面の特徴
- SEOと初回表示の課題
- CSRに有効な設計指針
- まとめ
ブラウザがDOMを組み立てる仕組み

CSRの典型的な動作は4ステップで説明できます。まずブラウザがサーバから受け取るのは、rootとなる空のdivと、main.jsのようなJavaScriptバンドルへのscriptタグだけです。この時点でHTMLには本文も画像URLも含まれていないため、画面はほぼ真っ白の状態です。そこからブラウザはJavaScriptファイルをダウンロードし、ReactやVueなどのフレームワークを起動します。
次にフレームワークがfetchやaxiosでバックエンドAPIを呼び、商品一覧や記事本文のJSONを取得します。受け取ったデータをコンポーネント関数に渡してVirtual DOMを構築し、最終的に実DOMへ差分パッチを当てて画面が現れます。ユーザーから見ると「真っ白→ローディング→画面表示」という流れになり、ネットワークが遅いと体感速度が悪化しやすい一方、サーバはJSONを返すだけなので構成が単純で水平スケールしやすいという利点があります。
CSRが向く画面の特徴

CSRは管理画面・ダッシュボード・SaaSのコンソール画面のように、ログイン後で検索エンジンに見られる必要がなく、画面遷移が頻繁な用途に向いています。一度JavaScriptを読み込めば、その後のページ移動はAPI呼び出しと差分描画だけで完結するため、フルリロードを伴うMPAより応答が滑らかで、PWA的なアプリ体験を構築しやすくなります。GoogleドライブやTrelloのようなツール群は、まさにCSRの代表的なショーケースです。
もう一つの強みは、リッチな双方向UIを実装しやすい点です。チャットの即時送受信、ホワイトボードの共同編集、グラフのインタラクティブ操作などは、サーバ往復なしで状態を更新できるCSRと相性が良く、Reduxやpiniaのようなクライアント状態管理ライブラリが豊富に整備されています。一方で初回ロードのバンドルサイズが膨らみやすく、コード分割や遅延ロードを丁寧に設計しないと、「ログイン後の最初のページが10秒待っても出ない」といった事態が起きるため注意が要ります。
SEOと初回表示の課題

CSRの代表的な弱点はSEOです。Googlebotは2019年以降Chromiumベースで常時最新のJavaScriptを評価できるようになりましたが、それでもインデックス更新には遅延があり、TwitterやFacebookのSNSクローラはほぼJavaScriptを実行しません。サーバから返るHTMLが空に近いCSRサイトでは、検索結果のスニペットやSNS共有時のOGPサムネイルが思った通りに出ない問題が起きます。対策として動的レンダリング(ボット時のみPrerenderingを挟む)やSSR/SSGへの切替が選ばれます。
もう一つは初回表示の遅さです。受け取った時点でHTMLが空なため、JSが評価されAPIが返るまでユーザーは何も見られず、Core Web VitalsのLCPやINPが悪化しやすくなります。対策としてはローディングスケルトンの表示、Critical CSSの先行読み込み、HTTP/2 push代替としてのrel=preload、ルート単位のコード分割などが定番です。それでも体感速度を改善しきれない場合は、初回だけSSRし以降をCSRに任せる「ハイブリッド」構成へ移行するのが現実的な解になります。
CSRに有効な設計指針

CSRで快適な体験を提供するための基本指針は3点に集約されます。1つ目はバンドル分割で、React.lazyやVueのdefineAsyncComponentを使ってルートごと・モーダルごとに遅延ロードを行い、初回読込にユーザーがすぐ使わないコードを含めないようにします。2つ目はサーバ状態とUI状態を切り分けることで、ReactならReact Query/TanStack Query、VueならPiniaのプラグインを使い、APIキャッシュとローカル状態を別レイヤーで管理すると無駄な再フェッチが減ります。
3つ目は計測です。Core Web VitalsのうちLCP(最大コンテンツ描画)、INP(入力応答性)、CLS(レイアウトずれ)の3指標を本番環境で継続的に取り、回帰が起きたら即気付ける体制を整えるとCSRの弱点を顕在化させずに済みます。web-vitalsライブラリでRUM(実ユーザー計測)を取り、Sentryやnew Relicに送る構成が一般的です。こうした分割・分離・計測の3原則を守れば、CSRでも十分実用的な品質に到達できます。
まとめ
CSRはブラウザがJavaScriptを実行してDOMを組み立てる描画方式で、管理画面やSaaSのように検索エンジン非対象でインタラクションが多い場面に強みを発揮します。初回表示の遅さとSEOの難しさは構造的な弱点なので、コード分割と計測を徹底し、必要に応じてSSRを併用したハイブリッド構成に進むのが現実的な選択肢です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。

コメント