--- title: "レンダリングとは？ブラウザ描画の仕組みとCSR/SSR/SSGの違い・選定基準を解説" url: "https://www.issoh.co.jp/tech/details/13578/" published: 2026-07-12 updated: 2026-08-12 categories: ["アーキテクチャ"] publisher: "株式会社一創" --- # レンダリングとは？ブラウザ描画の仕組みとCSR/SSR/SSGの違い・選定基準を解説 レンダリングとは、HTML・CSS・JavaScriptで書かれたコードを解釈し、画面上の目に見えるページとして描き出す処理を指します。この言葉は2つの層で使われます。1つはブラウザ内部でコードを画面のピクセルへ変換する仕組み、もう1つはそのHTMLを「どこで・いつ生成するか」という方式（CSR・SSR・SSGなど）の選択です。この記事では両者を切り分けたうえで、方式ごとの初回表示速度・SEO・サーバー負荷の違い、案件条件に応じた選定基準、そして受託開発で見積や要件定義にどう効くかまでを、実装者と発注者の双方が判断に使える形で整理します。 ## まとめ｜レンダリングの2つの意味と方式選定の要点 レンダリングには2つの意味があります。狭義はブラウザがHTML・CSSを解析し、DOMツリーの構築からレイアウト計算、ピクセルの描画までを行うブラウザ描画の処理です。広義は、そのHTMLを「クライアント（ブラウザ）で生成するか、サーバーで生成するか、あらかじめビルド時に生成しておくか」という方式の選択を指します。Web開発で判断が分かれるのは後者です。 方式は大きく、ブラウザ側で組み立てるCSR、サーバー側で組み立てて返すSSR、ビルド時に静的HTMLを作り置きするSSGの3系統に分かれます。初回表示の速さと検索エンジンへの読ませやすさではSSR・SSGが有利で、操作の多いアプリではCSRが向きます。ただし常にSSRが正解ではありません。更新頻度が低い公開サイトはSSGで足り、管理画面のように検索対象でない社内ツールはCSRで十分です。方式は表示速度・SEO要件・更新頻度・開発コストの4点で決めます。以降で仕組みと選定の判断基準を順に見ていきます。 ## レンダリングとは｜ブラウザがコードを解釈して画面に描画する仕組み まず狭義のレンダリング、つまりブラウザが受け取ったコードを画面に描くまでの流れを押さえます。ここを理解しておくと、後半の方式選定で「なぜ初回表示に差が出るのか」が腑に落ちます。 ### レンダリングの定義：HTML・CSSを画面のピクセルへ変換する処理 レンダリングの語源は「描画する」で、Webでは受け取ったHTML・CSS・JavaScriptを解釈し、文字や画像やボタンとして画面に映し出す一連の処理を指します。サーバーから届くのはあくまでテキストのコードです。それを人が読めるレイアウトへ組み立てる工程がレンダリングにあたります。動画編集や3DCGでも同じ言葉を使いますが、そちらが指すのは映像データの生成で、Web開発での用法とは対象が別物です。この記事で扱うのはWeb（ブラウザ）の文脈です。 ### ブラウザのレンダリングエンジンとCritical Rendering Pathの4工程 描画を担うのがレンダリングエンジンです。ChromeやEdgeはBlink、SafariはWebKit、FirefoxはGeckoを積んでいます。エンジンはまずHTMLを解析してDOMツリーを作り、CSSからCSSOMツリーを作り、両者を合成してレンダーツリーを構築します。続く工程は、各要素の位置と大きさを決めるレイアウト（リフロー）、色や文字を塗るペイント、重なりを合成するコンポジット。この一連の流れがCritical Rendering Pathです。JavaScriptがこの途中に割り込むと、レイアウトの再計算が起きて描画が引き延ばされます。表示が遅いページの多くは、この経路のどこかで処理が詰まっています。 ### 「レンダリング」という言葉が指す3つの対象とその切り分け方の要点 用語の混乱を避けるため、3つの用法を分けておきます。ひとつはいま述べたブラウザ描画の処理。ふたつめは次章で扱うCSR・SSR・SSGといったHTML生成方式。みっつめはUnityやBlenderなどでの3D・映像のレンダリングで、GPUで画像を生成する別分野です。検索で「レンダリングとは」を調べる文脈の多くはWeb開発の前者2つを指します。自社の話題がどれなのかは「HTMLの画面表示」か「動画・3Dの生成」かで判別できます。本記事は前者2つを扱い、後者には踏み込みません。 ## Webのレンダリング方式｜HTMLをどこで生成するかによる分類 ここからが広義のレンダリング、つまり設計判断が絡む方式の話です。分類の軸はシンプルで「完成したHTMLを、どこで、いつ組み立てるか」です。同じ画面でも、ブラウザで組むかサーバーで組むかで初回表示もSEOも変わります。CSRとSSRの違いは、この生成場所の違いに集約されます。 ### CSR（クライアントサイドレンダリング）の仕組みと適した画面例 CSRは、サーバーが最小限のHTMLの骨組みとJavaScriptをブラウザへ返し、ブラウザ側でJavaScriptを実行して画面を組み立てる方式です。初回はJavaScriptの読み込みと実行、API通信を経てから描画が始まるため、最初の表示までに時間がかかります。反面、いったん読み込めば画面遷移はサーバーへ問い合わせず手元で完結し、操作がなめらかです。管理画面、社内の業務ツール、ログイン後のダッシュボードのように、検索流入を狙わず操作量が多いアプリに向きます。ReactやVue.jsで作るシングルページアプリ（SPA）が代表例です。 ### SSR（サーバーサイドレンダリング）が適した画面と初回表示の速さ SSRは、ブラウザからのリクエストごとにサーバー側で完成済みのHTMLを組み立てて返す方式です。ブラウザは受け取った時点で中身のあるHTMLを表示できるため、初回表示が速く、検索エンジンにも内容が伝わりやすくなります。ただし、リクエストのたびにサーバーで生成するぶんサーバー負荷はCSRより高く、応答設計やキャッシュの工夫が前提になります。向くのは、ニュースサイト、ECの商品ページ、ユーザーごとに内容が変わる会員向けページなど、最新性とSEOの両立が要る画面。Next.jsやNuxtがSSRを扱えるフレームワークの代表です。NuxtでSSRを実際に動かしている層については[Nitroというサーバーエンジンの仕組み](https://www.issoh.co.jp/tech/details/16483/)を参照してください。 ### SSG・ISRなどビルド時にHTMLを作り置く方式の位置づけ SSG（静的サイト生成）は、リクエスト時ではなくビルド時にすべてのページをHTMLとして作り置きしておく方式です。配信時はできあがったファイルを返すだけなので、表示は速く、サーバー負荷も小さく、CDNとの相性も良好になります。更新のたびにビルドし直す前提のため、頻繁に内容が変わるページには不向きです。この弱点を補うのがISR（増分的静的再生成）で、静的生成を基本にしつつ、一定間隔や必要時にページ単位で再生成します。コーポレートサイト、ブログ、製品カタログのように更新頻度が中程度までのサイトは、SSG・ISRが有力な選択肢です。 ## CSRとSSRの違い｜初回表示速度とSEO・サーバー負荷の比較 方式選定でつまずきやすいのがCSRとSSRの使い分けです。両者は生成場所が違うだけに見えて、初回表示・SEO・サーバー負荷・開発難度に一貫した差が出ます。ここを表と論点で押さえると、案件ごとの判断がぶれません。 ### CSR・SSR・SSGを初回表示・SEO・負荷で比較する評価軸 4方式を、発注や設計で見る観点で並べます。数値は案件により動くため、傾向として捉えてください。 | 観点 | CSR | SSR | SSG／ISR | | -------------- | -------- | ---------- | -------------- | | HTML生成場所 | ブラウザ | サーバー（都度） | ビルド時（作り置き） | | 初回表示速度 | 遅め | 速い | 最も速い | | SEO（初期HTMLの中身） | 不利になりやすい | 有利 | 有利 | | サーバー負荷 | 小さい | 大きい | 小さい | | 最新性・動的な出し分け | 得意 | 得意 | 苦手（ISRで緩和） | | 向く画面 | 操作主体のアプリ | 都度更新の公開ページ | 更新が中程度までの公開サイト | 実務でまず押さえるのは、初回表示とSEOを重視するなら生成をサーバーかビルド時へ寄せ、操作性と動的更新を重視するならブラウザ側へ寄せる、という大枠です。ここを外さなければ細部は調整で吸収できます。 ### SEOへの影響：クローラのJavaScript実行とインデックスの実際 CSRがSEOで不利になりやすいのは、最初に返すHTMLが空に近く、中身がJavaScript実行後に初めて現れるからです。GoogleのクローラはJavaScriptを実行してインデックスできますが、実行は別工程として後回しになり、内容の反映が遅れたり取りこぼしたりする場合があります。SSR・SSGなら最初のHTMLに本文が入っているため、この不確実性を避けられます。検索流入を事業の柱にする公開ページでCSR単独を選ぶのは、避けるべき場面です。レンダリング方式はテクニカルSEOの土台に関わる判断で、キーワード設計やコンテンツ以前の前提になります。 ### 表示速度とCore Web Vitals（LCP）への方式別の影響 表示速度の体感は、GoogleのCore Web Vitalsという指標で数値化されます。なかでも主要コンテンツが表示されるまでの時間（LCP）は、初回にサーバーやビルド時点でHTMLが用意されているSSR・SSGで有利になりやすい項目です。一方のCSRは、JavaScriptの読み込みと実行を経てから描画するため、この初期指標で不利を抱えがちです。速度は離脱率にも検索評価にも響くため、公開サイトでは方式選定の段階で織り込んでおく論点になります。すでにCSRで構築済みのサイトでも、一部ページのSSR化やプリレンダリングで改善余地があります。 ## レンダリング方式の選定判断｜案件条件別の使い分けと避けるべき選択 方式は好みではなく、案件条件で決めます。判断軸は表示速度・SEO要件・更新頻度・開発と運用のコストの4つです。ここでは競合記事があまり言い切らない「どの場面でどれを選び、どれを避けるか」を条件付きで示します。 ### レンダリング方式を絞り込む選定フローと4つの判断基準の適用順 迷ったときは次の順で絞り込みます。 1. 検索流入が要るか。要るなら初期HTMLに本文が入るSSRかSSGを候補にする。 2. 内容の更新頻度はどれくらいか。低〜中ならSSG／ISR、高くユーザーごとに変わるならSSR。 3. 検索対象でなく操作が主か。管理画面や社内ツールならCSRで十分。 4. 運用体制で維持できるか。SSRはサーバー運用の負荷、SSGはビルド運用の手間を見込む。 この4問に答えれば、多くの案件は候補が1〜2方式に絞れます。1つの製品内で、公開ページはSSR、管理画面はCSRのように画面ごとに方式を混在させる設計も一般的です。方式は全画面で統一する必要はありません。 ### SSRが過剰投資になる場面とCSRを公開サイトで避けるべき場面 立場を明確にします。更新の少ないコーポレートサイトやブログにSSRを持ち込むのは、多くの場合で過剰です。都度サーバー生成の負荷と運用コストを負う割に、SSGでも初回表示とSEOは同等以上に得られます。この条件ならSSGかISRを選び、SSRは見送るのが妥当です。逆に、検索流入を事業の柱にする公開ページでCSR単独を選ぶのは避けるべき場面にあたります。インデックスの不確実性と初回表示の遅さが、そのまま集客の取りこぼしになりかねません。「新しいから」「なめらかだから」という理由だけでCSRのSPAを公開サイトに採るのは、SEOを捨てる判断になりがちです。 ### フレームワーク実装への橋渡し：Next.js・Reactでの具体化 概念として方式を決めたら、実装はフレームワークの機能に落とし込みます。Next.jsのApp Router世代（15系・2026年時点）なら、1つのアプリ内でSSR・SSG・ISRを画面単位で選べる構成が取れます。方式ごとの具体的な組み込みと使い分けは、[Next.jsにおける主要なレンダリング方法の種類と概要](https://www.issoh.co.jp/tech/details/3791/)で実装レベルまで掘り下げました。Reactでサーバー側とクライアント側の処理を分けるなら、[React Server Components（RSC）の違いと使い分け](https://www.issoh.co.jp/tech/details/4003/)が、コンポーネント単位でどこを描くかの判断材料になります。本記事の方式選定を、これらのフレームワーク実装につなげてください。 ## 受託開発でレンダリング方式が見積・要件定義・SEOに効く理由 レンダリング方式は技術的な選択に見えて、発注側の見積評価や要件定義に直結します。方式が決まれば必要な人材・サーバー構成・SEO施策の前提が決まるため、後工程の手戻りを大きく左右します。ここは実装者だけでなく、発注する側が押さえておくと効く論点です。 ### レンダリング方式の選定が開発コストと運用体制の見積に効く理由 方式はそのまま費用構造に反映されます。SSRを選べば、都度生成をさばくサーバーとキャッシュ設計、その運用を担う体制が要ります。SSGなら中心はビルドと配信の仕組みで、サーバー運用は軽い反面、要るのは更新フローの設計です。CSRはフロント側の作り込みが厚めです。見積を受け取ったとき、採用方式と費用・体制が噛み合っているかを見れば、内訳の妥当性を自分で吟味できます。方式を確認せず丸ごと任せると、後から「検索に載らない」「表示が遅い」といった要件のズレが表面化しがちです。フロントとサーバーの分担そのものの考え方は、[フロントエンドとバックエンドの違い](https://www.issoh.co.jp/column/details/13169/)で発注者目線に整理しています。 ### 検索流入を狙うサイトのSEO要件とレンダリング方式のすり合わせ 検索流入を狙うサイトでは、レンダリング方式はSEOの前提条件です。どれだけキーワードとコンテンツを設計しても、初期HTMLに中身が入らないCSR構成では評価が伸び悩みます。避けたいのは、公開後にそれが判明する事態です。要件定義の段階で「このページは検索対象か」を切り分け、対象ならサーバー生成か事前生成へ寄せる合意を取っておくと、後戻りを防げます。方式選定を含めたテクニカルSEOの設計から相談したい場合は、[一創のSEO内部施策・キーワード設計](https://www.issoh.co.jp/service/web/seo/)で、レンダリング方式の見直しと内部施策を一体で支援します。 ## レンダリング方式とCSR・SSRの違いに関するよくある質問と回答 検索されることの多い疑問に、仕組みと選定の両面から簡潔に答えます。 ### レンダリングとは簡単に言うと何ですか？ コードを画面に映る形へ描き出す処理のことです。Webでは、サーバーから届いたHTML・CSS・JavaScriptというテキストを、ブラウザが解釈して文字や画像やボタンとして表示します。この組み立て工程がレンダリングです。加えて、そのHTMLをどこで生成するか（ブラウザ・サーバー・ビルド時）という方式の選択も、広い意味でレンダリングと呼ばれます。 ### CSRとSSRの一番の違いは何ですか？ HTMLを組み立てる場所です。CSRはブラウザ側でJavaScriptを実行して画面を作り、SSRはサーバー側で完成したHTMLを作って返します。この差が初回表示とSEOに効きます。SSRは最初から中身のあるHTMLが届くため表示が速く検索にも有利で、CSRは初回に時間がかかる反面、読み込み後の操作がなめらかです。 ### SEOにはどのレンダリング方式が有利ですか？ 初期HTMLに本文が入るSSRとSSGが有利です。検索クローラはJavaScriptを実行できますが、CSRのように中身が実行後に現れる構成では反映が遅れたり取りこぼしたりする場合があります。検索流入を狙う公開ページは、サーバー生成か事前生成へ寄せるのが無難です。逆に検索対象でない管理画面はCSRでも支障ありません。 ### レンダリングが遅い原因は何ですか？ ブラウザ描画の観点では、JavaScriptの実行がCritical Rendering Pathに割り込んでレイアウトの再計算が起きる、画像やCSSの読み込みが重い、といった要因が典型です。方式の観点では、CSRで初回にJavaScriptの読み込みとAPI通信を待ってから描画するため初期表示が遅れます。改善はボトルネックの特定から始め、必要に応じて一部ページのサーバー生成やプリレンダリングを検討します。 ### SSGとSSRはどう使い分けますか？ 更新頻度で分けます。内容が頻繁に変わらず全ユーザーに同じページを見せるなら、ビルド時に作り置くSSGが速くて負荷も小さく有利です。ユーザーごとに内容が変わる、あるいは常に最新を出す必要があるならSSRを選びます。中間の要件はISRで、静的生成を基本にしつつ必要時にページ単位で作り直す折衷が使えます。 ## 関連記事 - [Next.jsにおける主要なレンダリング方法の種類と概要](https://www.issoh.co.jp/tech/details/3791/)：本記事の方式選定を、Next.jsでのSSR・SSG・ISR・SPAの実装レベルまで具体化した記事です。 - [React Server Components（RSC）とは？サーバー・クライアントの違いと使い分け](https://www.issoh.co.jp/tech/details/4003/)：Reactでどこをサーバー側で描くかを、コンポーネント単位で判断する視点を掘り下げています。 - [フロントエンドとバックエンドの違い](https://www.issoh.co.jp/column/details/13169/)：一体構成（サーバーサイドレンダリング）と分離構成の選択を、発注者目線の体制判断として整理しています。 --- 出典: [レンダリングとは？ブラウザ描画の仕組みとCSR/SSR/SSGの違い・選定基準を解説]()（株式会社一創）