Cache-Control・ETag・304の使い分け｜更新を早く届ける公開設計

先に答え：HTMLと版付きファイルを同じ期限にしない

更新を早く反映しながら表示を速くする基本は、役割でキャッシュ方針を分けることです。頻繁に内容が変わり、次に読むCSSや画像のURLを決めるHTMLは再検証しやすくします。一方、内容が変わるたびにファイル名へハッシュや版番号を付けるCSS・JavaScript・画像は、長期間保存できます。

画像を拡大 ↗

HTML、版付きCSS、画像、個人別ページのキャッシュ方針を並べた表。閉じる ×

URLと更新方法を一緒に設計します。

これは出発点です。CMS、CDN、認証、更新頻度、緊急差し替えの方法に合わせて調整します。

no-cacheは「保存禁止」ではない

名前が紛らわしいため、次の違いを先に押さえます。

画像を拡大 ↗

no-cache、no-store、privateの意味を比較した図。閉じる ×

no-cacheは保存禁止という意味ではありません。

• no-cache：保存済み応答をそのまま再利用する前に、サーバーへ確認する。
• no-store：応答をキャッシュへ保存しないよう求める。
• private：ブラウザー等の私的キャッシュには保存できるが、共有キャッシュには保存させない。
• max-age=秒：保存した応答を新鮮と扱える期間。
• immutable：URLの内容が変わらないため、期限中の再検証も不要と示す。

MDNは、最新内容を毎回確認したい場合でも、no-store を広く付けるのではなく、no-cache とETag等の検証子を使う方法を説明しています。個人別の内容は private も必要です。no-store は既に保存済みの古い応答を消す命令ではありません。

ETagと304は「本文を送り直さず確認する」仕組み

サーバーが応答へETagを付けると、ブラウザーは古くなった応答を再利用する前に If-None-Match でその値を送れます。サーバー上の現在版と同じなら、本文のない 304 Not Modified を返し、ブラウザーは保存済み本文を使います。変わっていれば 200 OK と新しい本文・ETagを返します。

画像を拡大 ↗

ブラウザーがIf-None-Matchを送り、同じETagなら304を返す流れ。閉じる ×

304はエラーではありません。

# 最初の応答
HTTP/1.1 200 OK
Cache-Control: no-cache
ETag: "page-v12"

# 次の確認リクエスト
If-None-Match: "page-v12"

# 同じ内容なら
HTTP/1.1 304 Not Modified
ETag: "page-v12"

304はエラーではありません。「キャッシュしている内容が現行版なので本文を送り直さなくてよい」という応答です。反対に、内容を変えたのにETagが同じままなら、誤って304を返し続ける実装になり得ます。ETagの生成と更新単位を確認します。

キャッシュは一か所ではない

「キャッシュを消したのに直らない」のは、保存場所が複数あるためです。ブラウザー、CDN・リバースプロキシ、WordPress等のページキャッシュ、サービスワーカー、アプリ内キャッシュを分けます。

画像を拡大 ↗

ブラウザー、CDN、サーバー、Service Worker等のキャッシュ層。閉じる ×

各層のURLと応答ヘッダーを記録します。

1. オリジンサーバーのファイル・データが新しいか。
2. オリジン応答の Cache-Control、ETag、Age等が意図どおりか。
3. CDNがどのルールで保存し、どのURLを消去したか。
4. ブラウザーが通常再読み込みと強制再読み込みでどう変わるか。
5. Service Workerやアプリが独自に応答を保存していないか。

CDNを消去してもブラウザーの長期キャッシュは残り得ます。逆にブラウザーを消してもCDNが古い応答を返せば直りません。「全部消す」前に、各層の応答ヘッダーとURLを記録します。

版付きURLで長期保存する

MDNは、変わらない静的ファイルはURLへ版番号やハッシュを含め、長い max-age を付けるキャッシュバスティングを紹介しています。内容が変わればURLも変わるため、古いファイルが長期保存されていても新しいHTMLは新URLを参照します。

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

画像を拡大 ↗

CSSの内容変更時にURLをapp.a1b2.cssからapp.c3d4.cssへ変える図。閉じる ×

ファイル名の値は架空の版識別子です。

長い期限を同じURLの app.js や style.css に付けたまま中身だけ置き換えると、利用者は期限が切れるまで旧版を使う場合があります。長期保存するファイルは、ビルドやCMSが内容変更時にURLを確実に変えることを確認します。

HTMLへ1年の max-age を設定するような構成は、緊急更新でも中間キャッシュへ到達できず、サーバーから消去できないことがあります。MDNも、長い max-age で保存された中間キャッシュの応答をオリジンから能動的に削除する標準手段はないと説明しています。CDN独自のパージ機能がある場合も、対象URLと範囲を運用票へ残します。

公開前後の確認手順

1. HTML、CSS、JavaScript、画像、API、個人別ページに分類する。
2. 現在のヘッダーとCDNルールをURL単位で取得する。
3. HTMLは再検証、版付き資源は長期保存という方針を決める。
4. 個人別・Cookie依存の応答に private が必要か確認する。
5. 新しい版を公開し、HTMLが新しい版付きURLを参照するか確認する。
6. 通常アクセス、再読み込み、別端末、未ログイン、ログイン後を確認する。
7. 旧版へ戻す場合も、新しいURLまたは確実なパージ手順を使う。

画像を拡大 ↗

資源の分類、ヘッダー設定、公開、別端末等での確認の順序。閉じる ×

公開後はHTML版と参照先の版を一緒に確認します。

確認例：

curl -I https://example.com/
curl -I https://example.com/assets/app.a1b2.css
curl -I -H 'If-None-Match: "page-v12"' https://example.com/

ヘッダーだけを確認するコマンドでも、CDN・プロキシ・認証によって実際のブラウザーと応答が異なることがあります。対象URL、Cookieの有無、Host、圧縮、地域等の条件をそろえます。

失敗したときの分岐

そのまま使えるキャッシュ設計メモ

対象サイト：https://example.com/
HTML：Cache-Control＿＿＿＿／ETag＿＿＿＿
版付きCSS・JS：URL命名＿＿＿＿／max-age＿＿＿＿／immutable有無＿＿＿＿
画像：差し替え時にURL変更する／しない
個人別ページ：private有無＿＿＿＿
CDN：なし／あり（パージ方法＿＿＿＿）
Service Worker：なし／あり（更新方法＿＿＿＿）
公開確認：HTML版＿＿＿／CSS版＿＿＿／JS版＿＿＿
304確認：If-None-Match＿＿＿→状態＿＿＿
ロールバック方法：＿＿＿＿
担当：配信＿＿＿／CDN＿＿＿／ブラウザー確認＿＿＿
確認日時（UTC）：2026-10-12 19:30

キャッシュは「有効か無効か」の二択ではありません。更新単位が違うものへ別の方針を与え、公開時にURL・ヘッダー・保存層を一緒に確認すると、速さと反映の両方を保ちやすくなります。

SITE PORTを検討するときの確認ポイント

サイト制作を依頼する場合は、画面の見た目だけでなく、この記事で扱った設定を誰が担当するか、公開後の変更や障害確認をどこまで依頼できるかを先に確認します。SITE PORTの完成例と編集デモでは、完成イメージと日常的な編集の流れを確認できます。DNS、サーバー、WordPressの定期処理、HTTPヘッダー等は通常の本文編集と同じ範囲で扱えるとは限らないため、必要な作業を具体的に伝え、対応範囲を確認してください。

関連記事

[更新が反映されないとき](/articles/website-update-not-visible)・[画像を軽くする順番](/articles/website-images-size-alt)・[DNSのTTLと切り替え準備](/articles/dns-ttl-before-server-move)