SSRとSSGの違いをビルド時レンダリングで整理

SSRとSSG(Static Site Generation)の違いをビルド時レンダリングの観点から整理する

SSRとSSGは「サーバ側でHTMLを作る仕組み」という点で似ていますが、実際の設計判断ではまったく違う性質を持ちます。違いはフレームワークの機能ではなく、いつHTMLを生成するかです。

この「いつ」を理解すると、なぜSSRは動的アプリ向きで、SSGはSEOに強いのかが自然に見えてきます。

レンダリングのタイミングがすべてを決める

まずレンダリングとは、ブラウザに渡すHTMLを生成する処理です。MPA・SPA・SSR・SSGの違いは、HTMLを作る場所ではなく、作るタイミングにあります。

方式 HTML生成のタイミング
SPA ブラウザ実行時
SSR リクエスト時
SSG ビルド時

ここが最重要ポイントです。

SSRは「アクセスが来た瞬間」にHTMLを作ります。
SSGは「デプロイ前」にHTMLを作ります。

同じサーバ側レンダリングでも、処理の重さと運用設計が根本的に変わります。

SSRの動作

SSRではユーザーがURLにアクセスするたび、サーバがHTMLを生成します。

ユーザーアクセス
↓
サーバがDB取得
↓
テンプレート生成
↓
HTML返却

つまり、毎回計算します。アクセスごとに処理が走るため、常に最新データが表示されます。

例えば次のようなページに向いています。

  • マイページ
  • カート
  • 管理画面
  • ログイン後画面

ユーザーごとに内容が違うため、事前生成ができません。

SSGの動作

SSGはビルド時にすべてのHTMLを生成します。

ビルド実行
↓
DBまたはCMS取得
↓
全ページHTML化
↓
静的ファイルとして配置

ユーザーがアクセスしたとき、サーバは計算をしません。単にファイルを返すだけです。ApacheやNginxが画像を返すのと同じ扱いになります。

このためSSGは極端に速くなります。サーバ処理がゼロだからです。

なぜSSGがCore Web Vitalsに強いのか

SSGでは、アクセス時に行われるのは「ファイル転送」だけです。

  • DB接続なし
  • テンプレート処理なし
  • API待ちなし

つまりLCPが短くなります。ブラウザはHTMLを受け取った瞬間に描画できます。

検索流入の多いページ(記事・ドキュメント)は、この特性と非常に相性が良いです。

SSRのメリットと注意点

SSRの最大の強みは「リアルタイム性」です。最新の状態を表示できます。

ただし、その代償としてサーバ負荷が増えます。アクセス数が増えるほどHTML生成回数も増えます。キャッシュ設計が必須になります。

特に起きやすい問題が、スパイクトラフィックです。SNSで拡散された場合、DBアクセスが集中してサイト全体が遅くなることがあります。

SSGの弱点

SSGにも明確な弱点があります。更新です。

例えば1000記事あるブログで1記事を修正した場合、本来は再ビルドが必要になります。ビルド時間が長いと公開が遅れます。

最近のフレームワークではISR(Incremental Static Regeneration)という仕組みで、この問題を緩和しています。変更ページのみ再生成する方式です。

よくある誤解:SSRの方が高機能?

これは半分正しく、半分誤りです。

SSRは「動的生成が可能」なだけで、機能が上というわけではありません。SSGでもクライアント側JavaScriptを組み合わせれば、SPAのような操作性を実現できます。

つまり次のようになります。

  • 表示の速さ → SSGが有利
  • 個別化表示 → SSRが有利

用途が違うだけです。

実務での選び方

単純な基準が1つあります。

「URLに直接アクセスしたとき、その内容は全員同じか?」

同じならSSG、違うならSSRが基本です。

例えばニュース記事、ブログ、ドキュメントはSSGが適します。一方で通知一覧やダッシュボードはSSR向きです。

注意点:SSRとSSGは混在させてよい

最近のフレームワーク(Next.jsなど)は、ページ単位でSSRとSSGを選択できます。ここが非常に重要です。

サイト全体をどちらかに統一する必要はありません。

検索流入ページ → SSG
ログイン画面 → SSR
アプリ画面 → SPA

このように役割分担すると、パフォーマンスと運用の両立が可能になります。

まとめ

SSRとSSGの違いは技術名ではなく、HTML生成のタイミングの違いです。SSRはアクセス時、SSGはビルド時にレンダリングします。

この差は、SEO・パフォーマンス・サーバ負荷・更新性のすべてに影響します。どちらが優れているかではなく、どのページにどの性質が必要かで選ぶのが適切です。

レンダリング方式を「フレームワークの流行」で選ぶと失敗します。ページの性格から逆算して決めると、設計はかなり安定します。