要点：輻輳時に強い次世代プロトコル。 本ページでは、現場での判断軸/実装/検証までをまとめます。
定義
HTTP/3（QUIC）はネットワーク/キャッシュ/優先度制御に関わる設計要素です。CDNとブラウザの双方で一貫したポリシーを持つことが重要です。
なぜ重要か
ヘッダひとつの設定ミスがキャッシュ不能や最新化遅延を招きます。キー爆発の抑制が肝です。
実務での活用（判断基準付き）
- Cache-Control/ETag/Surrogate-Keyを役割分担。
- SWR/代替で障害時も一定の可用性を保つ。
- キー爆発を避け、Client Hintsは最小構成で。
実装例
# 例: 画像のキャッシュ制御（CDN優先＋SWR）
Cache-Control: public, max-age=31536000, immutable
Surrogate-Control: max-age=31536000, stale-while-revalidate=86400, stale-if-error=604800
検証と失敗例
- 計測軸: キャッシュヒット率/再検証率、帯域節約とLCP改善の寄与。
- 失敗例: Vary乱立でキー爆発 / immutable乱用で更新不能 / preload過多で帯域奪取。
- 判断軸: 回線劣化時もp75指標が悪化しない。障害時はSWR/代替で継続提供。
チェックリスト
- Cache-ControlとCDN設定の二重管理を避けたか
- Vary/Client Hintsによるキー爆発を抑制したか
- SWR/再検証のポリシーが障害時に機能するか
- 重要リソースへpreconnect/preloadを適切に付与したか