SSG (Static Site Generation)

frontendwebrenderingjamstack

ビルド時に全ページの HTML を生成しておき、静的ファイルとして配信するレンダリング戦略。SSR と同じ「サーバー側で HTML を作る」でも、タイミングが「リクエスト時」ではなく「デプロイ前」。リクエスト時の計算はゼロで、配信は CDN に置くだけ。

仕組み

graph LR
    subgraph "ビルド時（1回だけ）"
        MD["コンテンツ<br/>(Markdown / CMS / DB)"] --> B["ビルド<br/>全ページを HTML 化"]
        B --> F["HTML / CSS / JS<br/>ファイル群"]
    end
    subgraph "リクエスト時"
        F --> CDN["CDN"]
        CDN -->|"ファイルを返すだけ"| U["ユーザー"]
    end

本質は「レンダリングを 1 回だけやって結果を全員に使い回す」— つまり究極のキャッシュ。SSR が毎リクエスト計算するのに対し、SSG は N 人目のアクセスにも 1 人目と同じファイルを返す。

トレードオフ

長所短所
最速（TTFB は CDN のファイル配信のみ）更新にリビルドが必要 — 反映にタイムラグ
最安（レンダリングサーバー不要）ビルド時間がページ数に比例 — 数万ページ級で苦しくなる
最も堅牢（落ちるサーバーが無い、攻撃面が小さい）リクエスト時情報を使えない — パーソナライズ不可
スケールは CDN 任せ「全員に同じもの」しか出せない

限界への回答

手法何を解決するか
ISR (Incremental Static Regeneration)「更新のたびに全ビルド」を解消。期限切れページをリクエストを契機に裏で再生成する（stale-while-revalidate の発想）
On-demand revalidationCMS 更新の Webhook で該当ページだけ再生成
SSG + クライアント JS枠は静的に固定し、ユーザー固有部分（カート数・ログイン名）だけクライアントで fetch して埋める
Islands Architecture静的 HTML の中に interactive な島だけ埋め込む（Astro）

この「静的配信 + API + クライアント JS」という構成を思想として掲げたのが Jamstack（2016〜, Netlify）。

向くケース

誰が見ても同じで、更新頻度がビルドで追えるサイト。ブログ・ドキュメント・LP・マーケティングサイト。このリポジトリの viewer（Astro 製）も SSG そのもの。

押さえどころ（カード化候補）

関連

Graph

Backlinks