キャッシュ戦略 — いつ捨てるかを設計する

What — キャッシュがどう判断されるか

ブラウザは、リクエストを出す前にキャッシュを見ます。ここでの分岐が体感速度を決めます。

ヘッダの意味を1つずつ確定させる

max-age=N

N 秒間は再検証せずに使ってよい。この間サーバーには一切問い合わせが行かない。最も強く、最も危険な指定。

no-cache

保存はするが、使う前に必ず再検証する。名前に反して「キャッシュするな」ではない。

no-store

一切保存するな。本当にキャッシュを禁止したいのはこちら。

private

ブラウザは保存してよいが、CDN などの共有キャッシュは保存するな。個人向けレスポンスに付ける。

immutable

有効期間中は絶対に変わらない。リロードしても再検証させない。ハッシュ付きファイル名とセットで使う。

ETag

コンテンツの指紋。変わっていなければ 304 を返せる。本体の転送だけを省く仕組み。

stale-while-revalidate=N

期限切れ後 N 秒間は、古いものを即座に返しつつ裏で更新する。待たせずに新しくできる。

no-cache と no-store の取り違えは実務で頻出します。キャッシュしてほしくないときに no-cache を書くと、保存はされます。

2つの更新戦略を比べる

<!-- ビルドのたびにハッシュが変わる -->
<script src="/assets/app.a3f9c2.js"></script>

Cache-Control: public, max-age=31536000, immutable

Why — なぜ「捨て方」が難しいのか

キャッシュの難しさは、元データの変更をキャッシュ側が知る手段がないことに尽きます。

元データを持っている側（サーバー）は、いつ変わったかを知っています。しかしキャッシュを持っている側（ブラウザ・CDN）は、自分から見に行かない限り分かりません。そして見に行くなら、キャッシュの意味が薄れます。

この矛盾に対する答えは、原理的に3つしかありません。

1. 時間で諦める — 「N 秒間は変わらないことにする」と決め打つ。これが max-age。速いが、その間の変更は届かない。
2. 毎回確認する — 使う前に必ず聞く。これが no-cache + ETag。確実だが往復が発生する。
3. そもそも同じ名前を使わない — 変わったら別物にする。これがバージョニング。確実で速いが、URL を自分で決められる対象にしか使えない。

なぜ「1年キャッシュ」が推奨されるのか

一見すると危険な max-age=31536000 が定石とされるのは、ハッシュ付きファイル名とセットのときだけです。この組み合わせでは、そもそも中身が変わった時点で URL が変わるので、「古いものが返る」という事象が定義上発生しません。

冒頭の事故は、この組み合わせの片方だけを採用したために起きました。1年キャッシュはファイル名を変える仕組みへの依存であって、単体の設定ではない。 ここを分離して覚えていると、いつか同じ事故を踏みます。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。