レンダリングとは？種類（CSR/SSR/SSG）と仕組みをわかりやすく解説

普段何気なく閲覧しているWebサイトは、裏側で「レンダリング」という重要な処理が行われています。このレンダリングの仕組みを理解することは、Webサイトのパフォーマンス改善やSEO対策において非常に重要です。

本記事では、Webレンダリングの基本的な仕組みから、CSR・SSR・SSG・ISRといったレンダリング方式の違い、SEOへの影響、実践的な最適化手法まで、初心者にもわかりやすく徹底解説します。

ウェブサイトのレンダリングとは？【基本の定義】

レンダリングの意味

Webサイトのレンダリングとは、HTML、CSS、JavaScriptなどのコードをブラウザが処理して、ユーザーが視覚的に閲覧できるWebページとして表示することです。

わかりやすく例えるなら、建築の設計図（コード）から実際の建物（Webページ）を建てる作業がレンダリングです。設計図だけでは家に住めないように、コードだけではWebサイトを閲覧できません。ブラウザがレンダリング処理を行うことで、初めて私たちが理解できる形で情報が表示されます。

なぜレンダリングが必要なのか

HTMLやCSSのコードをそのまま表示しても、人間には意味のない文字列の羅列にしか見えません。例えば、以下のようなHTMLコード。

Copy<div class="header"><h1>ようこそ</h1></div>

これをブラウザがレンダリングすることで、適切なフォント、サイズ、配置で「ようこそ」という見出しが美しく表示されるのです。

レンダリングは、コードを人間が理解できる視覚情報に翻訳する橋渡しの役割を果たしています。

レンダリングの2つの側面

Webレンダリングには大きく分けて2つの側面があります。

1. ブラウザレンダリング ブラウザ内部でHTMLやCSSを解析し、画面に表示するまでの技術的なプロセス。DOMツリー構築、レイアウト計算、ペイントなどの処理が含まれます。

2. レンダリング方式 「どこで」「いつ」HTMLを生成するかという戦略的な選択。CSR（クライアントサイド）、SSR（サーバーサイド）、SSG（静的生成）などの方式があります。

この2つの側面を理解することが、Webサイトのパフォーマンス最適化とSEO対策の第一歩となります。

ブラウザレンダリングの仕組み【技術的基礎】

ブラウザがWebページを表示するまでには、複雑なプロセスが瞬時に実行されています。このセクションでは、その舞台裏を詳しく解説します。

レンダリングエンジンとは

レンダリングエンジン（レイアウトエンジン、ブラウザエンジンとも呼ばれる）は、HTMLやCSSを解釈して画面上の視覚的表現に変換するブラウザの中核部分です。

主要なレンダリングエンジン：

ブラウザ

レンダリングエンジン

Google Chrome

Blink

Microsoft Edge

Blink

Safari

WebKit

Firefox

Gecko

Opera

Blink

ChromeとEdgeは同じBlinkエンジンを使用しているため、レンダリング結果がほぼ同じになります。

一方、SafariのWebKitやFirefoxのGeckoは独自の実装のため、同じコードでも微妙に表示が異なることがあります。

ブラウザレンダリングの5つのステップ

ブラウザがWebページを表示するまでの流れは、以下の5つの主要ステップに分けられます。

Step 1: HTMLのパース（解析）とDOM構築

ブラウザは最初にHTMLファイルを受け取り、これを解析（パース）します。

処理の流れ

  1. HTMLのバイトデータを受信
  2. 文字エンコーディング（UTF-8など）に基づいて文字列に変換
  3. トークン化（<div>、<p>などのタグを認識）
  4. DOMツリー（Document Object Model） を構築

DOMツリーは、HTMLの階層構造をツリー状のデータ構造として表現したものです。例えば：

Document
└── html
    ├── head
    │   └── title
    └── body
        ├── header
        │   └── h1
        └── main
            └── p

このツリー構造により、JavaScriptから要素にアクセスしたり、動的に変更したりできるようになります。

Step 2: CSSのパースとCSSOM構築

HTMLの解析と並行して、CSSファイルも解析されます。

処理の流れ

  1. CSSファイルを読み込み
  2. CSSルールを解析
  3. CSSOMツリー（CSS Object Model） を構築

CSSOMツリーは、どの要素にどのスタイルが適用されるかを表す構造です。セレクタの優先順位（詳細度）も計算されます。

Step 3: レンダーツリーの構築

DOMツリーとCSSOMツリーを組み合わせて、レンダーツリーを構築します。

レンダーツリーには、実際に画面に表示される要素のみが含まれます。例えば：

  • display: none のスタイルが適用された要素は除外
  • <head> タグ内の要素も除外
  • visibility: hidden の要素は含まれる（スペースを占有するため）

Step 4: レイアウト（Layout / Reflow）

レンダーツリーができたら、各要素の正確な位置とサイズを計算します。

レイアウト計算の内容：

  • ビューポート（表示領域）のサイズを基準に計算
  • ボックスモデル（margin、padding、border）の適用
  • 相対的な単位（%、em、remなど）を絶対値に変換
  • フレックスボックスやグリッドレイアウトの配置計算

この処理はリフロー（Reflow） とも呼ばれ、画面サイズ変更やDOM操作時に再実行されるため、パフォーマンスに大きく影響します。

Step 5: ペイント（Paint）とコンポジット

最後に、計算された情報を基に実際の画面に描画します。

ペイント処理

  • テキスト、色、画像、境界線、影などをピクセル単位で描画
  • 複数のレイヤーに分けて描画（レイヤー化）
  • 各レイヤーをGPUで合成（コンポジット）

モダンブラウザでは、アニメーションや透明度の変更などを効率化するために、要素を複数のレイヤーに分割して処理します。

JavaScriptの役割とレンダリングへの影響

JavaScriptはWebページに動的な機能を追加しますが、レンダリングプロセスに大きな影響を与えます。

パーサーブロッキング問題

ブラウザがHTMLを解析中に <script> タグに遭遇すると、JavaScriptの実行が完了するまでHTMLの解析を一時停止します。これを「パーサーブロッキング」と呼び、ページ表示が遅くなる主要な原因の一つです。

解決策

Copy<!-- 非同期読み込み：ダウンロードと実行を並行処理 -->
<script async src="script.js"></script>

<!-- 遅延読み込み：HTML解析完了後に実行 -->
<script defer src="script.js"></script>
  • async: スクリプトを非同期にダウンロードし、ダウンロード完了次第すぐに実行
  • defer: スクリプトを非同期にダウンロードし、HTML解析完了後に実行

一般的に、defer の方がレンダリングブロックを避けつつ、スクリプトの実行順序も保証されるため推奨されます。

クリティカルレンダリングパス

クリティカルレンダリングパスとは、ブラウザが最初の画面描画（First Paint）を行うまでの最短経路のことです。

この経路を最適化することで、ユーザーが「ページが表示された」と感じるまでの時間を短縮できます。

最適化のポイント

  1. クリティカルリソース（初回表示に必要なファイル）を最小化
  2. ファイルサイズを削減（minify、圧縮）
  3. レンダリングブロックするリソースを削減
  4. 重要なコンテンツを優先的に読み込む

Webレンダリングの種類【レンダリング方式を徹底比較】

ここまではブラウザ内部の処理を見てきましたが、次は「どこで」「いつ」HTMLを生成するかというレンダリング方式について解説します。

レンダリング方式とは

レンダリング方式とは、Webページの最終的なHTMLをどのタイミング・どの場所で生成するかの戦略です。

主な選択肢

  • クライアント（ブラウザ） で生成するか
  • サーバー で生成するか
  • ビルド時に事前 に生成するか

この選択によって、表示速度、SEO、サーバー負荷、開発の複雑さなどが大きく変わります。

CSR（クライアントサイドレンダリング）

CSR（Client-Side Rendering） は、ブラウザ側のJavaScriptでHTMLを動的に生成する方式です。

仕組み

  1. サーバーから最小限のHTML（ほぼ空）とJavaScriptファイルを取得
  2. ブラウザでJavaScriptを実行
  3. APIからデータを取得
  4. JavaScriptがDOMを構築してページを表示

メリット

  • リッチでインタラクティブなUIが実装しやすい
  • ページ遷移が高速（SPAでリロード不要）
  • サーバー負荷が低い（静的ファイル配信のみ）
  • ユーザーごとにカスタマイズされた体験を提供しやすい

デメリット

  • 初回表示が遅い（JavaScriptダウンロード・実行待ち）
  • SEOに不利（GooglebotはJavaScript実行に時間がかかる）
  • JavaScriptが無効な環境では動作しない
  • 初回のバンドルサイズが大きくなりがち

適した用途

  • 管理画面やダッシュボード
  • ログイン後の会員専用サイト
  • リアルタイム更新が多いアプリケーション

代表的なフレームワーク： React（create-react-app）、Vue.js、Angular

SSR（サーバーサイドレンダリング）

SSR（Server-Side Rendering） は、サーバー側で完全なHTMLを生成してブラウザに送信する方式です。

仕組み

  1. ユーザーがページをリクエスト
  2. サーバーがデータベースやAPIからデータを取得
  3. サーバーでReactやVueコンポーネントを実行してHTMLを生成
  4. 完成したHTMLをブラウザに送信
  5. ブラウザで即座に表示（その後JavaScriptで動的化：ハイドレーション）

メリット

  • 初回表示が高速（完成したHTMLがすぐ表示される）
  • SEOに非常に有利（クローラーが完全なHTMLを取得）
  • SNSシェア時のOGP（Open Graph Protocol）が確実に表示
  • JavaScriptオフ環境でも基本的な閲覧が可能

デメリット

  • サーバー負荷が高い（リクエストごとにHTML生成）
  • TTFB（Time to First Byte）が長くなる可能性
  • インフラコストが増加（サーバー性能が必要）
  • サーバー側の実行環境が必要（Node.jsなど）

適した用途

  • ニュースサイト、メディアサイト
  • ECサイトの商品ページ
  • ブログやコーポレートサイト（SEO重視）

代表的なフレームワーク： Next.js、Nuxt.js、Remix

SSG（静的サイト生成）

SSG（Static Site Generation） は、ビルド時にすべてのページのHTMLを事前生成する方式です。

仕組み

  1. デプロイ前のビルド時にすべてのページを生成
  2. 静的HTMLファイルとしてCDNにアップロード
  3. ユーザーのリクエストに対して事前生成したHTMLを配信
  4. 更新時は再ビルドが必要

メリット

  • 最速の表示速度（CDNからの静的配信）
  • サーバー負荷がゼロ（静的ファイル配信のみ）
  • セキュリティが高い（サーバー側の処理なし）
  • インフラコストが最小（CDNのみ）
  • SEOに最適（完全なHTML）

デメリット

  • ページ数が多いとビルド時間が長い
  • コンテンツ更新には再ビルドとデプロイが必要
  • リアルタイムなデータ表示には不向き
  • ユーザーごとにカスタマイズされた内容は難しい

適した用途

  • 企業サイト、ランディングページ
  • ドキュメントサイト、技術ブログ
  • 更新頻度の低いコンテンツサイト

代表的なフレームワーク： Next.js（SSGモード）、Gatsby、Astro、VitePress

ISR（インクリメンタル静的再生成）

ISR（Incremental Static Regeneration） は、SSGとSSRのハイブリッド方式です。

仕組み

  1. 初回ビルド時に主要ページを静的生成
  2. アクセスされたページは静的HTMLを即座に配信
  3. 設定した時間（例：10秒）が経過後、バックグラウンドで再生成
  4. 次回アクセス時から更新されたページを配信

メリット

  • SSGの速度とSSRの新鮮さを両立
  • 大規模サイトでもビルド時間が短縮
  • サーバー負荷が低い（リクエストごとに生成しない）
  • コンテンツの自動更新が可能

デメリット

  • 実装がやや複雑
  • 対応フレームワークが限定的
  • キャッシュ戦略の理解が必要

適した用途

  • 大規模ECサイト（商品ページ）
  • 定期的に更新されるニュースサイト
  • ユーザー生成コンテンツが多いサイト

代表的なフレームワーク： Next.js（revalidate機能）

レンダリング方式の比較表

各レンダリング方式の特徴を一覧で比較してみましょう。

項目

CSR

SSR

SSG

ISR

HTML生成場所

ブラウザ

サーバー

ビルド時

ビルド時+定期更新

初回表示速度

遅い

速い

最

最速

SEO対策

不利

有利

有利

有利

サーバー負荷

低い

高い

なし

低い

リアルタイム性

高い

高い

低い

中程度

インフラコスト

低い

高い

最低

低い

更新の容易さ

容易

容易

再ビルド必要

自動更新

初回バンドルサイズ

大きい

中程度

小さい

小さい

選択の基本指針

  • SEO重視 + 高速表示 → SSG または ISR
  • リアルタイム性重視 → CSR または SSR
  • 大規模サイト → ISR
  • 管理画面・会員サイト → CSR
  • 企業サイト・LP → SSG

レンダリングとSEOの関係

レンダリング方式の選択は、SEO（検索エンジン最適化）に直接的な影響を与えます。

Googleクローラーとレンダリング

Googleのクローラー（Googlebot）は、Webページをインデックスする際に以下のプロセスを実行します：

  1. クロール: ページのHTMLを取得
  2. レンダリング: JavaScriptを実行してページを描画
  3. インデックス: コンテンツをデータベースに登録

重要なポイント

  • GooglebotはJavaScriptを実行できますが、即座には実行しません
  • JavaScriptの実行は「レンダリングキュー」に入り、数時間〜数日後に処理されることがある
  • この遅延により、CSRサイトのインデックスが遅れる可能性がある

レンダリング方式がSEOに与える影響

CSRの課題：

  • クローラーがJavaScript実行を待つ必要がある
  • 実行前のHTMLが空に近いため、重要なコンテンツが即座に認識されない
  • メタタグや構造化データの読み込みが遅延する可能性
  • 内部リンクの発見が遅れる

SSR/SSG/ISRのメリット

  • 完全なHTMLがクローラーに即座に提供される
  • タイトル、メタディスクリプション、見出しなどが確実に読み取られる
  • 構造化データ（JSON-LD）が確実にインデックスされる
  • Core Web Vitals（後述）のスコアが向上しやすい

実例： ECサイトの商品ページでCSRを使用すると、商品名や価格がJavaScript実行後にしか表示されないため、検索結果に反映されるまで時間がかかります。SSRやSSGを使用すれば、即座に正確な情報がインデックスされます。

ダイナミックレンダリング

ダイナミックレンダリングとは、ユーザーには通常のCSRを、クローラーには事前レンダリングされたHTMLを配信する手法です。

実装方法：

  • ユーザーエージェントでクローラーを検知
  • クローラーには Headless Chrome でレンダリングしたHTMLを返す
  • 一般ユーザーには通常のCSRを配信

注意点： Googleは以前この手法を推奨していましたが、現在はSSRやSSGへの移行を推奨しています。ダイナミックレンダリングは一時的な対策と位置づけられています。

レンダリングとCore Web Vitals

Googleは2021年から、ユーザー体験を測定する指標「Core Web Vitals」を検索ランキングの要素に組み込んでいます。

Core Web Vitalsの3指標

1. LCP（Largest Contentful Paint）

  • 意味: 最大のコンテンツ要素が表示されるまでの時間
  • 目標値: 2.5秒以内
  • レンダリングとの関係: SSG/SSRは即座にコンテンツを配信できるため有利。CSRはJavaScript実行待ちのため不利。

2. INP（Interaction to Next Paint）

  • 意味: ユーザー操作から次の描画までの応答時間
  • 目標値: 200ミリ秒以内
  • レンダリングとの関係: JavaScriptの実行効率が影響。過度なCSRは重いJavaScript処理により不利になることがある。

3. CLS（Cumulative Layout Shift）

  • 意味: レイアウトの視覚的安定性（予期しない要素の移動）
  • 目標値: 0.1以下
  • レンダリングとの関係: SSR/SSGは初期レイアウトが安定。CSRは画像やフォントの遅延読み込みでレイアウトシフトが発生しやすい。

レンダリング最適化とパフォーマンス改善

SSG/SSRでのCore Web Vitals改善策：

  1. 画像の遅延読み込みと適切なサイズ指定
  2. フォントの最適化（font-display: swap など）
  3. クリティカルCSSのインライン化
  4. JavaScriptの遅延読み込み（defer/async）

CSRでのCore Web Vitals改善策：

  1. コード分割（Code Splitting）でバンドルサイズ削減
  2. SSRへの移行検討
  3. プリレンダリング（主要ページのみ事前生成）
  4. サーバーサイドでの初期データ埋め込み

レンダリングの最適化テクニック【実践編】

HTMLの最適化

1. HTMLの軽量化

  • 不要な空白や改行を削除（minify）
  • 不要なコメントを削除
  • HTMLの構造をシンプルに保つ

2. DOMノードの削減

  • 過度にネストされた要素を避ける
  • 不要な <div> ラッパーを削減
  • セマンティックなHTML要素を使用

CSSの最適化

1. クリティカルCSSのインライン化

Copy<style>
  /* 初回表示に必要な最小限のCSS */
  .header { ... }
  .hero { ... }
</style>

2. CSS読み込みの最適化

Copy<!-- 非クリティカルCSSの遅延読み込み -->
<link rel="preload" href="styles.css" as="style" onload="this.rel='stylesheet'">

JavaScriptの最適化

1. async/defer属性の活用

Copy<!-- DOMContentLoaded後に実行 -->
<script defer src="main.js"></script>

<!-- ダウンロード完了次第実行 -->
<script async src="analytics.js"></script>

2. コード分割（Code Splitting）

Copy// 動的インポートで必要な時だけ読み込む
const module = await import('./heavy-module.js');

3. Tree Shaking 未使用のコードを自動削除し、バンドルサイズを削減

レンダリング方式の選択基準

サイトの特性別の推奨方式：

サイトタイプ

推奨方式

理由

企業サイト

SSG

更新頻度低、SEO重視、高速表示

ブログ・メディア

SSG/ISR

コンテンツ中心、SEO重視

ECサイト商品ページ

ISR/SSR

在庫更新、SEO重視

会員制ダッシュボード

CSR

SEO不要、動的UI重視

ニュースサイト

ISR/SSR

リアルタイム性とSEO両立

ドキュメントサイト

SSG

静的コンテンツ、検索性重視

よくある質問（FAQ）

Q1: レンダリングブロックとは何ですか？ A: ブラウザがページを表示する前に、特定のリソース（CSS、JavaScriptなど）の読み込みと処理を待つ必要がある状態のことです。これによりページ表示が遅延します。

Q2: CSRとSSRはどちらが良いですか？ A: 目的によります。SEOと初回表示速度を重視するならSSR/SSG、リッチなUIとユーザー体験を重視するならCSRが適しています。多くの場合、ISRやハイブリッド方式が最適解になります。

Q3: JavaScriptなしでもWebサイトは表示されますか？ A: SSRやSSGで構築されたサイトは基本的なコンテンツが表示されますが、CSRのみのサイトは空白ページになります。プログレッシブエンハンスメントの考え方が推奨されます。

Q4: レンダリングが遅い原因は？ A: 主な原因は、①大きなJavaScriptバンドル、②レンダリングブロックするリソース、③過度なDOM操作、④最適化されていない画像、⑤サーバーの応答遅延などです。

Q5: SPAとMPAの違いは？ A: SPA（Single Page Application）は1つのHTMLで構成され、CSRを使用します。MPA（Multi Page Application）は複数のHTMLページで構成され、従来のSSRを使用します。

Q6: WordPressはどのレンダリング方式ですか？ A: 従来のWordPressはSSR（PHPによるサーバーサイドレンダリング）です。ただし、Headless CMSとして使用し、Next.jsなどと組み合わせることでSSG/ISRも可能です。

Q7: モバイルとデスクトップでレンダリングは違いますか？ A: 基本的な仕組みは同じですが、モバイルはCPU/メモリが限られるため、JavaScriptの実行やレンダリングにより時間がかかります。モバイルファーストの最適化が重要です。

Q8: レンダリング最適化で最初にすべきことは？ A: PageSpeed InsightsやLighthouseでサイトを測定し、具体的なボトルネックを特定することから始めましょう。測定なしの最適化は効果が不明確です。

まとめ

Webサイトのレンダリングは、ユーザー体験、SEO、パフォーマンスに直接影響する重要な技術です。

本記事のポイント：

  1. レンダリングには2つの側面がある
    • ブラウザレンダリング（DOM構築、レイアウト、ペイント）
    • レンダリング方式（CSR、SSR、SSG、ISR）
  2. レンダリング方式の選択が重要
    • SEO重視ならSSG/SSR/ISR
    • 動的UIならCSR
    • 多くの場合、ハイブリッド戦略が最適
  3. SEOとパフォーマンスへの影響
    • GooglebotのJavaScript実行には遅延がある
    • Core Web Vitalsはランキング要素
    • レンダリング最適化は必須
  4. 実践的な最適化手法
    • クリティカルレンダリングパスの最適化
    • JavaScriptの遅延読み込み
    • コード分割とTree Shaking

記事を書いた人

LandingHub 編集部

LandingHub 編集部

LandingHub編集部です。 知見を持ったLandingHubスタッフが情報を発信しています。 表示速度に関する価値のある再現性の高いノウハウに関して、技術的な知識の少ない担当者の方でもわかりやすく解説していきます。
コラム一覧に戻る