HTTP キャッシュ

HTTP キャッシュとは

同じ画像や CSS を、アクセスのたびにダウンロードし直すのは無駄です。HTTP キャッシュは、一度取得した応答を手元に保存して再利用し、通信そのものを省く仕組みです。

効果は 2 つあります。利用者には表示が速くなり、提供側にはサーバ負荷と転送量が減る。Core Web Vitals の LCP 改善にも直結する、地味だが効果の大きい施策です。

• うまく効けば、2 回目以降の表示はほぼ瞬時になる。
• 反面、設定を誤ると古い内容が表示され続ける事故になる。

鮮度（Cache-Control）

キャッシュの中心は、サーバが応答に付ける Cache-Control ヘッダです。「どれだけの間、どう使い回してよいか」を指定します。

# 1 年間、変更されない前提で強くキャッシュ（ハッシュ付きファイル向け）
Cache-Control: public, max-age=31536000, immutable

# 毎回サーバに確認させる（HTML など内容が変わるもの向け）
Cache-Control: no-cache

# 一切キャッシュさせない（個人情報を含む応答など）
Cache-Control: no-store

主要な指示子の意味を押さえておきましょう。

指示子	意味
max-age=N	N 秒間は再取得せずそのまま使ってよい
public	CDN など共有キャッシュにも保存してよい
private	各ブラウザのみ保存可（共有キャッシュ不可）
no-cache	保存はするが、使う前に毎回サーバへ検証する
no-store	保存自体を禁止する
immutable	有効期間中は変わらない。再検証も省く

検証（ETag / Last-Modified）

max-age が切れても、中身が変わっていなければ再ダウンロードは無駄です。そこで変わったかどうかだけを確認するのが検証です。

サーバは応答に ETag（内容の指紋）や Last-Modified（更新時刻）を付けます。次回ブラウザは、その値を If-None-Match / If-Modified-Since で送って問い合わせます。

# サーバ → ブラウザ：内容の指紋を付与
ETag: "abc123"

# 期限切れ後、ブラウザ → サーバ：この指紋のままか確認
GET /style.css HTTP/1.1
If-None-Match: "abc123"

# 変わっていなければ本文ゼロで「そのまま使え」と返る
HTTP/1.1 304 Not Modified

変更が無ければサーバは 304 Not Modified を本文なしで返し、ブラウザは手元のコピーを使い続けます。本文を再送しない分だけ通信が軽くなります。これを再検証と呼びます。

ブラウザと CDN のキャッシュ

キャッシュは 1 か所ではありません。利用者に近い順に、複数の層があります。

層	置き場所	特徴
ブラウザキャッシュ	各利用者の端末	その人専用。private でも保存される
CDN / 共有キャッシュ	世界各地のエッジ拠点	多数の利用者で共有。public が必要
オリジンサーバ	大本のサーバ	最終的なデータの出どころ

**CDN（Content Delivery Network）**は、コンテンツを利用者に物理的に近い拠点へ複製し、そこから配信します。public 指定の応答をエッジでキャッシュすることで、オリジンへのアクセスを減らし、世界中で高速に届けられます。

更新時の無効化（キャッシュバスティング）

強くキャッシュすると速い反面、更新したのに古いファイルが表示され続ける問題が起きます。これを避ける定番がキャッシュバスティングです。

仕組みは単純で、ファイル名にハッシュ（内容に応じた識別子）を埋め込むだけです。

• 旧: app.js → 新: app.9f3c2a.js
• 中身が変わればファイル名そのものが変わるため、ブラウザは新しい URL を別物として取得する。
• 変わらないファイルは名前も同じなので、長期キャッシュがそのまま効く。

これにより、「長くキャッシュして速い」と「更新は確実に届く」を両立できます。多くのビルドツールが、この命名を自動で行います。

土台となる HTTP のヘッダやステータスコード、配信を速くする観点では Web パフォーマンス もあわせて読むと、全体像がつながります。