CSR・SSR・SSG・ISRの違いを図解で理解する

はじめに

Next.jsを使ったフロントエンド開発の文脈で必ず出てくる「CSR・SSR・SSG・ISR」というアルファベット4種類。それぞれ異なるレンダリング（画面表示）の方法を指しており、どれを選ぶかによってWebサイトの表示速度・SEO・更新の仕組みが大きく変わります。

本記事では、非エンジニアの担当者にも理解できるよう、各レンダリング方式を「いつ・どこでHTMLが生成されるか」という観点からわかりやすく解説します。

レンダリングとは何か

「レンダリング（Rendering）」とは、コンテンツデータをブラウザに表示できるHTML形式に変換するプロセスです。

ユーザーがWebサイトを開くと、ブラウザはHTMLを受け取って画面に表示します。このHTMLが「いつ・どこで」生成されるかによって、4つのレンダリング方式に分類されます。

用途別の早見表｜どの方式を選ぶべきか

方式選びは、比較表の項目を突き合わせるより、3つの質問に順番に答えるほうが早く絞り込めます。

1. 最初に、そのページが検索エンジンからの流入を必要とするかを判断します。不要なログイン後の画面ならCSRで問題ありません。

2. 次に、利用者ごとに表示内容が変わるかを確認します。変わる場合はSSRが基本です。

3. 最後に更新頻度と、公開までに許容できる時間を見ます。更新がまれで即時反映が不要ならSSG

4. 更新が続くが数時間の遅れを許容できるならISRが適します。

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

CSR（Client-Side Rendering：クライアントサイドレンダリング）

仕組み

HTMLの生成をユーザーのブラウザ（クライアント）上で行う方式です。

メリット・デメリット

メリット：ページ遷移が速い（一度読み込んだら次のページへの移動がスムーズ）・リアルタイムな更新が得意

デメリット：初期表示が遅い（JavaScriptの読み込みを待つ必要がある）・SEOが弱い（検索エンジンのクロール時にコンテンツが存在しない可能性）

向いているユースケース

• ログイン後の管理ダッシュボード（SEOが不要）

• リアルタイムで更新されるデータ（株価・チャット等）

• 頻繁にデータが変わるインタラクティブなアプリ

SSR（Server-Side Rendering：サーバーサイドレンダリング）

仕組み

HTMLの生成をサーバー上でリクエストごとに行う方式です。

WordPressが採用している基本的な仕組みがSSRに相当します。

メリット・デメリット

メリット：SEOに強い（完全なHTMLが返るため検索エンジンが読める）・常に最新データを表示できます

デメリット：リクエストのたびにサーバー処理が発生するため、高負荷時に遅くなることがある・サーバーコストが高いです

向いているユースケース

• ユーザーごとにパーソナライズされたコンテンツ（マイページ等）

• リアルタイムで最新データが必要でSEOも重要なページ

• ログイン状態によって異なるコンテンツを表示するページ

SSG（Static Site Generation：静的サイト生成）

仕組み

HTMLの生成をビルド時（デプロイ前）に行い、生成済みのHTMLをCDNで配信する方式です。

メリット・デメリット

メリット：最速の表示速度（CDNから静的ファイルを返すだけ）・サーバー負荷がない・セキュリティが高い・コストが低いです

デメリット：コンテンツを更新するたびにビルドが必要・ビルド時間が長くなると更新が遅れる・ユーザーごとに異なるコンテンツには対応しにくい

向いているユースケース

• コーポレートサイト（更新頻度が低い）

• ランディングページ

• ドキュメントサイト

• ブログ（記事数が少ない場合）

ISR（Incremental Static Regeneration：インクリメンタル静的再生成）

仕組み

SSGのメリット（高速・低コスト）を維持しながら、コンテンツを定期的に自動更新するNext.js独自の方式です。

「60秒ごとに自動更新」「コンテンツ変更時にオンデマンドで再生成」という設定が可能です。

メリット・デメリット

メリット：SSGの速度を維持しながらコンテンツを自動更新・大量ページがあってもビルド時間が増大しない・キャッシュ戦略の柔軟な設計が可能

デメリット：設定が複雑・更新のタイミングがリアルタイムではない（設定した間隔に依存）

向いているユースケース

• 大量の記事を持つブログ・ニュースサイト

• ヘッドレスCMSと連携したサイト（コンテンツ更新を自動反映）

• ECサイトの商品ページ（在庫状況等の更新が必要だが完全リアルタイムでなくてもよい）

Next.jsでの実際の使い方

Next.jsのApp Routerでは、ページ・コンポーネントのコードで使い方を決める。

Next.jsはReactをベースにしたフレームワークですが、両者の役割には違いがあります。詳しい違いについては「ReactとNext.jsの違い」で解説しています。

Server Components（デフォルト）：SSR/SSGに近い動作。サーバーサイドでのデータ取得・HTMLの生成。

fetchのキャッシュ設定でISR相当を実現：

• cache: 'force-cache' → ビルド時に生成してキャッシュ（SSG相当）

• next: { revalidate: 60 } → 60秒ごとに再生成（ISR相当）

• cache: 'no-store' → アクセスのたびに生成（SSR相当）

'use client'ディレクティブ：クライアントコンポーネントの宣言（CSR相当）

一つのNext.jsサイトの中で、ページ・コンポーネントごとに最適なレンダリング方式を使い分けることができます。これがNext.jsの大きな強みの一つです。

ページ種別ごとの推奨（トップ・記事一覧・記事詳細・フォーム）

続いて、記事を増やし続けるメディア型サイトを整理します。

トップページは新着記事の並びが変わるためISRが扱いやすく、更新間隔を短めに設定します。記事一覧やカテゴリ一覧も、記事の追加を反映するためISRです。記事詳細は公開後の変更が少ない一方、誤字修正の差し替えが発生します。時間指定の再生成に加え、CMS側の更新をきっかけに個別ページだけを再生成する仕組みを併用すると反映が早まります。

サイト内検索の結果は入力内容で表示が変わるためCSRまたはSSRが適します。問い合わせフォームは、ページをSSGで配信し、送信処理だけをクライアント側で扱う構成が一般的です。

方式の選定を誤ったときに起きる問題

選定の誤りは、公開直後ではなく運用開始後に表面化することが多い点に注意が必要です。

検索流入を狙うページをCSRでつくると、内容が読み取られるまでに時間差が生じ、想定した評価が得られないことがあります。すべてをSSRにすると、アクセス集中時に処理が積み重なり、表示の遅延や費用の超過という形で現れます。ページ数の多いサイトをSSGだけで運用すると、記事を1本追加するたびに全体の生成処理が走ります。

後からの変更も可能ですが、データ取得やキャッシュの設計に手を入れる必要があるため、設計の段階で判断するほうが手戻りは小さくなります。

まとめ

4つのレンダリング方式を「いつ・どこでHTMLを生成するか」で整理しました。コーポレートサイト・オウンドメディアではSSG＋ISRの組み合わせが最もパフォーマンスとSEOに優れ、ユーザーごとのパーソナライゼーションが必要な部分だけSSRを採用するというアプローチが現代のベストプラクティスです。

次の記事では、Next.jsのApp Routerを実際にどう使うかを入門レベルで解説します。