どんな場面で検討するか
既存Webサイトの画像・CSS・JavaScript等の配信をキャッシュし、オリジン負荷と地域差を減らしたい場合。HTML/APIは、公開範囲と更新頻度を決めた上で別ルールとして扱う。
組織で使う条件
HTML/JSONはデフォルトでキャッシュされないため、必要な公開応答だけ明示的にルール化する。 private/no-store/Set-Cookieなどの扱いと、purge後の表示版を監視する。
採用前に試すこと
- 検証ドメインで合成画像/JSと利用者別APIを用意し、公開資産とno-store応答を区別する。
- 2利用者でキャッシュ状態/内容を読み、片方のデータが他方へ返らないか試す。
- 資産を改版してpurgeし、オリジンとCDNの版・SHA256・応答時間を比較する。
合格と判断する条件
- 公開対象と非公開対象を説明でき、HTTPSが成立する。
- 公開資産はキャッシュが使われ、個人別APIは共有されない。
- 合意した更新時間内に新しい版となり、古い資産と不整合を起こさない。
見落としたくない点
- 利用者別の応答を無条件にCache Everythingへ含める設計は採用しない。 DNS/オリジンを変更できない場合や特殊プロトコルは構成条件を先に確認する。
- 利用者別の応答を無条件にCache Everythingへ含める設計は採用しない。
- DNS/オリジンを変更できない場合や特殊プロトコルは構成条件を先に確認する。