最終更新:
【仕組み解説】キャッシュはなぜ速い? — データの再利用・有効期限・更新を図解
同じサイトを2回目に開くと速いのは、前の画面を覚えているから?
どこに保存しているの?自分のパソコンの中だけ?
キャッシュにあれば、そのまま使っていいの?
期限が来たら、また画像を丸ごとダウンロードするの?
変更の有無だけを確かめられる場合があるよ。ETagという内容の版を区別する値を受け取っていれば、If-None-Matchでその値を送り、変わっていないか問い合わせる。変更がなければ304 Not Modifiedが返り、手元の本文を再利用できるんだ。通信そのものがゼロになるのではなく、大きな本文の再転送を省けるんだね。
ハッシュを使う実装もあるけれど、必ずそうとは限らないよ。版番号などでもよく、生成方法は一つに決められていないんだ。クライアントは値の意味を推測するより、サーバーから受け取った識別子として扱うよ。
no-cacheって指定すれば、コピーを保存しないんだよね?
アプリが商品データをキャッシュしていたら、価格変更はどう反映するの?
アプリ側で更新のルールを作るよ。たとえばDBを更新した後に該当するキャッシュを無効にし、次の読み取りで入れ直す方法がある。ただし同時アクセスなどで古い情報が残る可能性もあるんだ。期限を付けるだけで常に最新になるとは限らないので、在庫確定など正確さが必要な処理では元データをどう確認するかまで考えるよ。
ヒット率を100%に近づければ成功?
HTTPキャッシュの指示を読み分ける
| 応答のCache-Control | 基本的な意味 |
|---|---|
max-age=3600 | 応答の経過時間が3600秒未満なら新鮮とみなす。ほかの条件も適用される |
no-cache | 保存は禁止しないが、別の要求への再利用前に検証する |
no-store | その応答を保存しない |
private | 共有キャッシュに保存しない。専用キャッシュは保存できる |
no-storeを後から返しても、過去に保存されたコピーを一括で消す命令にはなりません。また、ブラウザの「戻る」で画面を復元する仕組みはHTTPキャッシュと同じではありません。
CSSやJavaScriptは、内容が変わったらstyle.a1b2c3.cssのようなファイル名も変える方法があります。新しいHTMLが新しい名前を参照すれば、古いファイルとの混同を防ぎやすくなります。HTML側の更新方針もセットで設計します。
この記事はウェブ配信とアプリのキャッシュが対象です。CPUキャッシュの具体的な容量・遅延や、製品間の性能比較を示すものではありません。
次に読む:CDNの配信と更新。
参考資料
確認日:2026年9月21日。
- RFC 9111 — HTTP Caching — 鮮度、再検証、304応答、private・no-cache・no-storeの違い。
- MDN — HTTP caching — ブラウザと共有キャッシュ、Cache-Control、再検証とファイル名のバージョニング。
- MDN — ETag header — ETagは生成方法を限定しない識別子で、ハッシュだけでなく版番号なども使えること。
- Microsoft — Cache-Aside pattern — アプリがキャッシュと元データを扱う流れ、更新・失効・整合性の課題。
訂正履歴
- 2026-09-21:条件のない速度・容量・ヒット率の目安、ETagは必ずハッシュという説明、DBは常にディスクを読むという断定を修正。