no-cache, no-store の違い
キャッシュ関連のディレクティブは多々ありますが、
その中で間違えやすい no-cache, no-store を取り上げます。
no-cache の仕組み
「キャッシュしない」ではない！
キャッシュが有効期限内であっても毎回キャッシュが最新かどうか検証します。
タワレコよろしく、
No Validation, No Cache
と覚えましょう。
使い所
更新のあるコンテンツに対して、更新に追随しつつもキャッシュを利用したい場合に有効です。
利用時の注意点
ブラウザバック時に (disk cache) が返ってしまい、コンテンツが更新されない場合があります。
参考: Chrome の Back button を押した際に「意図しない Cache」が利用されて、期待と違うページが表示される問題について調査した
サポートするブラウザの仕様によって意図しない挙動をする場合があるので、その場合はキャッシュをそもそもさせない no-store が対策の一手。
no-store
キャッシュを保存せず、毎回 Origin にリクエストします。
使い所
その命名である「no-store = ストアしない」という意味合いから
キャッシュストレージの容量を奪わない様にする場合に利用します。
CloudFront 等 CDN サービスではキャッシュストレージ容量への懸念が小さいですが、
CDN を DIY するときにはストレージ容量は有限なので懸念がある為です。
厳密にキャッシュさせたくない場合
1 | Cache-Control: private, no-store, no-cache, must-revalidate |
- private: Proxy や CDN の経路上のキャッシュをしない
- no-store: キャッシュを保存しない
- no-cache: 再検証なしではキャッシュしない
- must-revalidate: キャッシュ期限切れ時に再検証を強制
- Stale (期限切れ) キャッシュを利用させない
- Origin がダウンしていたら 504 Gateway Timeout を返す
- max-age, no-cache と共存不可
手厚い防御をしている理由
Proxy, CDN の互換性を軽減する為です。
総評
キャッシュの設定を細かく制御する際は
ブラウザ, Proxy, CDN の互換性を勘案し
検証を細かく実施する必要があることがわかりました。
参考
同僚に勧められた本！
Web における配信の最適化・高速化について解説いただいてます。
自分自身が AWS CloudFront 使っていた程度でしたが
Varnish の設定がそもそも分かりやすく記述されており
入りやすかったです。
キャッシュに対しての理解が非常に深まりました。
この場を借りて感謝申し上げます。
テストをどの様に行うか、開発時の本番環境の再現性等々、まだまだ知りたいことがいっぱいです。
続編求！
