SSR/SSG/ISRの選び方は、Next.js/React案件で「設計ができる人」として評価される分かれ道です。やみくもにSSRに寄せると遅くなり、SSGに寄せすぎると更新運用が破綻します。ポイントは、SEO（検索で拾われる）×速度（離脱を減らす）×運用（更新を回す）を同時に満たすこと。

この記事では、SSR/SSG/ISRの違いを「現場での設計パターン」として整理し、Core Web Vitals（LCP/INP/CLS）改善まで含めて“案件で語れる判断軸”に落とします。Core Web Vitalsは実ユーザー体験を測る指標で、検索におけるページ体験の考え方とも整合します。

まず結論：迷ったら「SSG/ISRを優先、SSRは必要な所だけ」

レンダリング戦略を選ぶときは「コンテンツがどれくらいの頻度で変わるか」で決めるのが鉄板です。Vercelの指針でも、SSGを基本に、定期更新はISR、リアルタイム性が必要なところだけSSRという考え方が推奨されています。

方式 HTML生成タイミング SEO/速度 向いているページ 注意点
SSG ビルド時 最速になりやすい LP/記事/ヘルプ/企業情報 更新のたびにビルドが必要
ISR 静的配信＋必要時に再生成 速い＋鮮度も確保 ブログ/求人一覧/カテゴリ一覧 再生成ルール設計が必要
SSR リクエストごと 鮮度最強だが重くなりやすい ログイン後/個別最適/在庫・価格の即時反映 TTFBやコストが増えやすい

SSR/SSG/ISRを「ページタイプ別」で決める設計パターン

パターン1：LP・集客ページはSSG（“最速”を取りにいく）

  • 目的：検索流入 → 1秒でも早く読ませる → CV/応募へ
  • 理由：更新頻度が低く、速度と安定性を最大化できる
  • 実装の考え方：画像最適化、不要JS削減、フォント最適化、構造化データ

SSGは配信が軽く、LCP（表示の体感速度）やCLS（レイアウトのズレ）を安定させやすいのが強みです。Core Web Vitalsは読み込み・操作性・安定性を測る指標として整理されています。

パターン2：記事一覧・カテゴリ一覧はISR（“鮮度”と“速さ”の両立）

記事が増えるサイトでSSGだけにすると、更新のたびにビルドが重くなりがちです。ここでISRを使うと、基本は静的で速いまま、必要なときだけページを再生成できます。Next.jsのISRは「一定時間で再生成」だけでなく「オンデマンド再検証」も用意されています。

  • 例：記事一覧（/articles）、タグ一覧、求人カテゴリ一覧
  • 運用のコツ：更新頻度に応じて再生成間隔を調整／急な更新はオンデマンド再検証

「更新はあるが秒単位のリアルタイム性は不要」なら、ISRはかなり強い選択肢です。

パターン3：マイページ・ダッシュボードはSSR（またはCSR）

ユーザーごとに内容が変わるページは、静的に作るほど複雑になります。この領域はSSR（もしくはCSRでデータ取得）に寄せ、SEOの対象外として割り切るのが合理的です。SSRは検索向きのHTMLを返せる一方、毎リクエスト生成で重くなりやすいので、必要なページに限定するのがポイントです。

SEOと速度の両方で効く「5つの実務チェックリスト」

1）「検索で拾いたいページ」を先に決める

  • 検索流入が目的：LP、解説記事、用語ページ、比較ページ
  • 検索対象外でOK：ログイン後画面、通知一覧、管理画面

検索対象のページは、HTMLが安定してクロールしやすい構成（SSG/ISR中心）に寄せると、設計がシンプルになります。

2）“最初に見える情報”を軽くする（LCP対策）

  • ヒーロー画像の最適化（サイズ/形式/遅延読み込みの設計）
  • 不要なJSを減らす（初回ロードに載せない）
  • 上部に重いコンポーネントを置かない

LCP/INP/CLSは実ユーザー体験を測る指標として、検索におけるページ体験の考え方と結びつきます。

3）操作の“引っかかり”を消す（INP対策）

  • 重い計算・巨大なレンダリングを避ける
  • 無駄な再レンダリングを減らす（メモ化/分割）
  • 入力やクリックに対する反応を早くする

4）レイアウトのズレを潰す（CLS対策）

  • 画像・広告枠のサイズを事前に確保する
  • フォント切替でガクッと動かないようにする
  • 遅延表示する要素は“場所取り”をする

5）更新運用の設計まで語れると「単価が伸びる」

Next.js案件で評価が上がるのは「作れる」だけでなく、更新頻度・運用フロー・再生成戦略（ISR）まで設計して説明できる人です。ISRは静的配信の速度を維持しつつ、再生成で鮮度を確保できるため、運用要件のあるサイトで採用されやすいです。

“案件で語れる”ようになる最短の考え方

面談で刺さる説明はシンプルです。たとえば次のように言えると強いです。

  • 「検索流入ページはSSG/ISRで高速化し、更新頻度が高い一覧はISRで運用負荷を下げました」
  • 「ユーザー別ページはSSR/CSRに寄せ、SEO対象と切り分けました」
  • 「Core Web Vitals（LCP/INP/CLS）を意識して、初回表示の重さとズレを潰しました」

この“切り分け”と“理由”が説明できると、同じReact経験でも単価レンジが変わってきます。

関連：Next.js案件で評価されるスキルもセットで確認

レンダリング戦略は「設計」の一部です。実務で評価されるスキルセット（TypeScript/設計/運用）も合わせて押さえると、案件の選び方が一気にラクになります。

Next.js案件で評価される必須スキル（TypeScript/設計/運用）を読む →

BranDix JobでNext.js/React案件を探すときの見方

  • 募集要件にSSR/SSG/ISRやSEO、速度改善が書かれているか
  • 担当範囲が「実装だけ」か「設計・改善」まで含むか
  • 運用（更新・再生成・監視）まで責任範囲があるか

Next.js/React案件を確認する

「SSR/ISR設計」「SEO」「Web Vitals改善」が絡む募集は、高単価になりやすい傾向があります。まずは案件一覧で、条件に合う募集を見比べてみてください。

BranDix Jobの案件一覧を見る この特集トップへ戻る

まとめ：迷ったら「SSG/ISRを基本、SSRは必要なページだけ」。そして、Core Web Vitals（LCP/INP/CLS）を意識して“速くて安定した体験”を作れると、Next.js案件での評価と選択肢が一段上がります。