こんにちは。株式会社プラハCEOの松原です。
先日プラハチャレンジの参加者に「Cache-Control: max-age=0って何の意味があるの？毎回サーバーに問い合わせてたらキャッシュのメリットがないのでは？」と聞かれたので、それについて思ったことをまとめてみます
TL:DR;
- どでかいレスポンスを毎回取得しなくて済む
- 内容が更新されたらすぐ知りたいけどめっちゃ重いから毎回受け取りたくないリソースに向いてる
説明
例えば、内容が変わったらすぐに反映させたいどでかい画像を返してくるサーバーに複数回アクセスするケースを考えてみます
レスポンスにmax-age=0が指定されている場合、2回目以降も毎回サーバーまでは問い合わせるけど変更がなければレスポンスのボディにはどでかい画像は含まれていない状態で返ってきます。空っぽです。1回目のレスポンス（どでかい画像）をクライアントがキャッシュしているので、それを使えば良いわけですね
もし「どうせ毎回確認しに行くならメリットないし、キャッシュしない設定にしておくか」となると、毎回どでかい画像が含まれた状態でレスポンスが返ってきます。これを防げるのが1番のメリットじゃないかなと。ただブラウザに関してはデフォルト設定ではそこまでどでかいレスポンスはキャッシュしてくれないし、全てのユーザーに「もしもし？ブラウザのキャッシュ設定を変えてくれない？」と頼むわけにもいかないので注意が必要です
指定しておけば挙動が読みやすくなるかも？
RFCによればキャッシュの寿命が指定されていない場合はheuristic freshness(クライアントが寿命を推察した値)を使っても良いとされています。が、具体的な計算式が明示されていないのでクライアントごとに計算値が異なり、挙動が読みづらくなる可能性があるのではないでしょうか？そういう挙動のブレを防ぐ意味でもmax-ageを指定しておくことには意味がある気がします
ちなみにfastlyのブログによると、世界中のレスポンスヘッダを解析したところ7~8割はmax-ageを指定しているそうです。この記事自体めっちゃ面白いのでオススメ！
おまけ
この辺の表を見るとキャッシュ制御ヘッダーの扱いってサービスごとにだいぶ違いますよね。RFCに全てのサービスが準拠していることは保証できないため、RFCに書いてあるから絶対そうなるはずと考えてしまうと意外な被害を受けるかもしれません
何度掘り返すんだって感じかもしれませんが昔CDNを切り替えたら仕様の差で問題が起きた話もありましたし、本当にキャッシュはよくよく調べてから使わないと怖い...
- 事前にテストしづらい
- 事故った時に検知しづらい
- 事故った時に致命的な影響を受ける
- 事故った時に直しづらい
みたいな悪魔的な要素が揃っているにも関わらずRFC的には「キャッシュを使うのはWEBサービスとして当然だろう？デフォルトオンだ」というスタンスなので、キャッシュを使わないようにするために知識が求められるのも事故が絶えない原因の1つではないかと個人的に思ったり。キャッシュを使うようにするために知識が求められるのであれば、知らない人にとってはキャッシュが使われないだけで済むし...
Discussion