イミュータブルなアセットとCDNを使ったHTTPキャッシュはどう機能しますか？

Question

IT Interview Practice · Accepted Answer

HTTPキャッシュは、ブラウザやCDNがレスポンスを再取得する代わりに再利用できるようにするもので、**`Cache-Control`** ヘッダーによって制御されます。Webアプリで勝ちパターンとなるのは、**アセットのファイル名をハッシュ化して永久にキャッシュし、HTMLはキャッシュ不可にする**ことです。

## 2層戦略

```http
# Hashed, versioned assets — content never changes for a given URL
Cache-Control: public, max-age=31536000, immutable
# e.g.  /static/app.9f2c1a.js   (the hash changes when content changes)

# HTML — must always be fresh so it can point at new asset hashes
Cache-Control: no-cache
```

- **`immutable`** は、再読み込み時でさえ、条件付きリクエストを一切行わず再検証しないようブラウザに伝えます。ファイル名のハッシュが*まさに*バージョンなので安全です。新しいコンテンツ = 新しいURLです。
- HTMLの **`no-cache`** は誤解を招く名前です。「保存はするが、使う前に再検証する」（変更がなければ304）という意味であり、ユーザーは常に現在のアセットハッシュを参照するHTMLを得られます。

## 再検証とCDN

- **`ETag`** / `Last-Modified` は、`max-age` が切れたときに安価な `304 Not Modified` レスポンスを可能にします。
- **CDN** はユーザーに近いエッジノードでキャッシュします。共有CDNキャッシュには `s-maxage` を、そしてバックグラウンドで更新しつつ古いコンテンツを即座に配信するには `stale-while-revalidate` を使います:

```http
Cache-Control: public, s-maxage=600, stale-while-revalidate=86400
```

## 落とし穴

- HTMLを長い `max-age` でキャッシュする → ユーザーが古いバージョンに固定され、それを無効化する手段がなくなります。
- ハッシュ化されていないURLに `immutable` を付ける → 修正を出荷できなくなります。

## なぜ重要なのか

キャッシュは最も安価なパフォーマンス施策です。再訪問をネットワークコストゼロに変え、オリジンの負荷を軽減します。ハッシュ化イミュータブルアセット + 再検証HTMLのパターンは業界標準であり、`no-cache` ≠「キャッシュするな」である*理由*を説明できることは、本物の深さを示します。

2層戦略

再検証とCDN

落とし穴

なぜ重要なのか

関連する質問