#cdn (1)

従来アーキテクチャ（GCP VM）

User Request
  ↓
GCP Cloud Run / App Engine VM ← コールドスタート / スケーリング遅延
  ↓
HTML 生成 / SSR
  ↓
レスポンス

問題

1. コールドスタート: 初回実行時 500ms 以上
2. スケーリング: 同時アクセス増加時に自動スケール待ち
3. 往復レイテンシ: 物理的な距離（地理的に離れたデータセンター）
4. 固定コスト: インスタンス維持費

新アーキテクチャ（Astro → CF Pages CDN）

User Request
  ↓
CDN エッジ（地理的に近い）← 99.99% はキャッシュヒット
  ↓
静的 HTML / JS / CSS 返却（ミリ秒単位）
  ↓
レスポンス

メリット

1. ゼロレイテンシ: キャッシュは世界 200+ のエッジロケーション
2. スケーリング不要: CDN が自動的に分散
3. コールドスタート無し: ファイルサーバーなので即座に返却
4. 従量課金: 無制限の静的配信（Free）

実測値の例

指標	GCP Cloud Run（SSD ストレージ）	CF Pages CDN
TTFB（東京から）	150-300ms	20-50ms
キャッシュヒット率	N/A（毎回生成）	99.9%
スケール対応	数秒待ち	即座
月額コスト	$10-50	$0（Free）

Astro + CF Pages が強い理由

ビルド時生成

# yarn build
astro build
  ↓
dist/ に静的 HTML/CSS/JS を生成
  ↓
Pages が自動的に CF CDN に配置

Edge Functions は必要な時だけ

// Pages Functions（エッジで実行、スピン不要）
export const onRequest: PagesFunction = async (ctx) => {
  return fetch('https://api.example.com/data');
};

動的処理はエッジ関数で即座に実行。サーバーVM起動なし。

チューニングのポイント

1. キャッシュキー: 静的アセットに Cache-Control: max-age=31536000（1年）
2. Stale-While-Revalidate: ISR 相当（バックグラウンド再生成）
3. 圧縮: CF が自動的に Brotli 圧縮

// wrangler.toml でのキャッシュ設定
[env.production]
routes = [
  { pattern = "/static/*", cache_control = "public, max-age=31536000" },
  { pattern = "/*", cache_control = "public, max-age=3600, stale-while-revalidate=86400" }
]

移行判断基準

• 静的コンテンツ 80% 以上 → Astro + CDN（この場合）
• ユーザーごとの動的生成 → SSR 維持（Next.js）
• リアルタイム更新 → SPA + API（React）

結論: 静的配信できるなら CDN エッジが最高パフォーマンス。サーバーレス関数は webhook/API にのみ使う。