配信（Delivery）実務：HTTP/キャッシュ/CDN設計
配信はオリジン・CDN・ブラウザの三層で最短に整えます。大切なのは“やりすぎない最小設計”。キャッシュは共有を長めに・ユーザーは短めに、プリヒントは重要資産に限定、可視化はメトリクスに寄せて意思決定します。
先に結論
長寿命はバージョニングとセット、短命は
stale-while-revalidate で切れ目を隠す。Early Hints は preconnect + 重要CSS/フォントのみ に絞る。保護が必要な配信は 署名URL を採用。要点（TL;DR）
- キャッシュは“共有長く・端末短く” —
s-maxage長め +stale-while-revalidate。
ユーザーは短めのmax-ageで誤配信を防ぐ。 - プリヒントは少数厳選 —
preconnectと 重要CSS/フォントのpreloadだけ。
乱用はキュー飽和で逆効果。 - 保護は署名URL — 画像/動画/ライセンス/セグメントまで範囲化。
期限・リファラ・クレーム組合せで漏れに耐性。 - ロールアウトはカナリア — 地域/割合で段階適用し、失敗時は迅速ロールバック。
TTFB/Hit率/帯域で判断。
背景：なぜ“やりすぎない設計”が効くのか
キャッシュ/プリヒント/エッジロジックはどれも強力ですが、適用範囲を誤ると優先度競合やVary膨張で逆効果になります。まずは“既定で速い”設計を作り、ボトルネックにだけ個別対策を足す順序が安全です。
とくに キャッシュキー は事故の温床です。URL/クエリ/ヘッダのうち、意味があるものだけを採用し、それ以外は正規化して落とす方針にします。
設計：キャッシュ→プリヒント→エッジ→保護→計測
- キャッシュ設計 — 静的はバージョニング+immutable、準静的は
s-maxage+SWR、動的は private/no-store。 - プリヒント — 103 Early Hints で
preconnectと重要CSS/フォントの先行のみ。 - オリジン分割 — 画像/動画/静的/動的を分け、TLS/帯域/障害をアイソレーション。
- エッジロジック — AB/Geo/Device を最小限にし
Varyを肥大化させない。 - 保護 — 署名URL を活用し、期限/参照元/クレームで多層防御。
- 計測 —
Server-Timingとログで TTFB/Hit率/帯域/エラーを監視、ダッシュボード化。
実装：ヘッダ/ヒント/署名URLの最小セット
1) Cache-Control の定石
# 典型: 静的アセット（ビルド後は内容不変）
Cache-Control: public, max-age=31536000, immutable
# 共有キャッシュ（CDN）を優先し、ユーザーは短命に
Cache-Control: public, max-age=300, s-maxage=86400, stale-while-revalidate=600
# JSON API（動的・短寿命）
Cache-Control: private, max-age=0, no-store2) Early Hints（103）
# Early Hints (103) の例（CDN/サーバで送出）
Link: </styles/critical.css>; rel=preload; as=style
Link: </fonts/ibmplex.woff2>; rel=preload; as=font; crossorigin
Link: <https://img.example-cdn.com>; rel=preconnect; crossorigin3) 署名URL（擬似コード）
// 署名URLのクレーム例（擬似コード）
claim = {
exp: now + 300, // 5分
path: "/images/*", // パススコープ
ref: "example.com", // 許可リファラ
ua: "Mobile|Desktop", // 簡易UAグループ
ip: "203.0.113.0/24" // NW制限（必要時）
}
token = HMAC_SHA256(secret, claim)応用：画像/動画と連携する
NG/落とし穴
- プリヒント乱用 — 何でもpreloadでキュー飽和。
- Vary過多 — キャッシュミス増大。キーは最小限に。
- クエリキーの爆発 — utm_* をキーに含めてしまう事故。
- 長寿命と無版管理 — immutable なのにバージョンがない。
公開前チェックリスト
- キャッシュ — 静的=immutable、準静的=s-maxage+SWR、動的=no-store。
- プリヒント — preconnectと重要CSS/フォントに限定。
- キャッシュキー — v/buildのみ採用、utm_*は無視。
- 署名URL — 期限/参照元/クレームを組み合わせ、検証を実装。
- メトリクス — TTFB/Hit率/帯域/エラー/地域差をダッシュボード化。
まとめ
配信は“最小で速い”のが正解。キャッシュは共有長寿命+端末短命、プリヒントは厳選、保護は署名URL、ロールアウトはカナリア。画像/動画の戦略と揃えて全体最適を図りましょう。
FAQ
FAQ（よくある質問）
1キャッシュキーの典型
パス+クエリのうち、v/ver/build 等のバージョンだけを採用。utm_* は無視。ヘッダは Accept/Accept-Encoding 程度に限定。
2stale-while-revalidate の扱い
CDNに長めのs-maxage + stale-while-revalidate を与え、ユーザー側は短めの max-age。更新の切れ目を体感させない設計。
3配信と動画/画像の連携
動画は ポスター/LQIP と 再生メトリクス、画像は 優先度設計 と srcset/sizes を併用。