CSSや画像が更新されないときに疑うブラウザキャッシュの基本と対処
CSSを書き換えたのに見た目が変わらない。画像を差し替えたのに古いまま表示される。Web制作やWordPress運用では、かなりよく起きる現象です。
原因の多くは、ブラウザやサーバー、CDNが古いファイルを再利用していることにあります。ブラウザキャッシュは表示を速くする仕組みですが、更新作業中は「変更が反映されない」ように見える原因にもなります。
この記事では、CSS・JavaScript・画像などの静的ファイルを例に、キャッシュの考え方、確認手順、実務で使う対処法を整理します。
- ブラウザキャッシュは、同じCSSや画像を毎回ダウンロードしないための保存機能
- 変更が反映されないときは、ブラウザ、サーバー、CDN、WordPressプラグインのどこで古いファイルが残っているかを切り分ける
- 制作中はハードリロードやDevTools、本番反映ではファイル名・クエリ文字列の変更が有効
style.css?v=20260707のようなバージョン付けは、古いCSSを読ませないための実務的な方法
対象環境の例は、一般的なWebブラウザ、HTML/CSS、WordPressサイトです。ブラウザやサーバー設定によって画面名は少し変わりますが、考え方は共通です。
ブラウザキャッシュとは何か
ブラウザキャッシュは、Webページで使ったファイルを手元に保存し、次回以降の表示を速くする仕組みです。
たとえば、あるページで次のようなファイルを読み込んだとします。
<link rel="stylesheet" href="/css/style.css">
<img src="/images/main.jpg" alt="メイン画像">
<script src="/js/app.js"></script>
ブラウザはページを表示するために、HTMLだけでなくCSS、画像、JavaScriptも取得します。毎回すべてをサーバーから取り直すと遅くなるため、条件が合えば一度取得したファイルを再利用します。
この再利用がキャッシュです。
何が保存されるのか
キャッシュの対象になりやすいのは、ページの見た目や動作を支える静的ファイルです。
- CSSファイル
- JavaScriptファイル
- PNG、JPEG、WebP、SVGなどの画像
- フォントファイル
- 一部のHTMLやAPIレスポンス
CSSや画像が変わらない問題でよく見るのは、style.css や logo.png のように、同じURLのまま中身だけを差し替えたケースです。
ブラウザから見るとURLは同じです。サーバーやブラウザの設定によっては、「前に取得したファイルをまだ使ってよい」と判断されます。
ここがポイント: キャッシュは「ファイル名」だけではなく、URL、HTTPヘッダー、有効期限、再検証の結果を見て使われます。
CSSや画像の変更が反映されない主な原因
反映されない原因は一つとは限りません。まずは、どこに古いファイルが残っているかを分けて考えると早く切り分けできます。
1. ブラウザが古いファイルを使っている
もっとも身近な原因です。
通常の再読み込みでは、ブラウザがキャッシュ済みのCSSや画像を使うことがあります。制作中にCSSを直しても画面が変わらない場合、まずここを疑います。
確認方法は簡単です。
- シークレットウィンドウや別ブラウザで開く
- ハードリロードを試す
- DevToolsのNetworkタブで、対象ファイルが再取得されているか見る
Chrome DevToolsでは、Networkタブを開いた状態で「Disable cache」を有効にすると、DevToolsを開いている間はキャッシュを無効にして確認できます。制作中の切り分けに向いています。
2. サーバーが長いキャッシュ期間を返している
サーバーは、レスポンスヘッダーで「このファイルをどれくらい保存してよいか」をブラウザに伝えます。
代表的なのが Cache-Control です。MDNのHTTPキャッシュ解説でも、HTTPキャッシュはレスポンスの保存と再利用に関わる仕組みとして説明されています。
例として、次のようなヘッダーが返る場合があります。
Cache-Control: public, max-age=31536000
max-age=31536000 は、秒数で約1年です。画像やCSSのURLが変わらないまま中身だけ変わると、ブラウザが長く古いファイルを使い続けることがあります。
この設定自体が悪いわけではありません。むしろ、ファイル名を変更する運用と組み合わせれば高速化に有効です。問題は、長期キャッシュと同じURLでの上書き更新を同時に使うことです。
3. CDNやサーバー側キャッシュが残っている
WordPressサイトでは、ブラウザだけでなくサーバー側にもキャッシュが入ることがあります。
- レンタルサーバーの高速化機能
- CDN
- WordPressのキャッシュプラグイン
- 画像最適化プラグイン
- リバースプロキシ
この場合、手元のブラウザでキャッシュを消しても、サーバーやCDNが古いCSS・画像を返しているため変わりません。
「自分のPCでは変わらない」だけならブラウザキャッシュの可能性が高いですが、「別端末でも古い」「スマホ回線でも古い」ならサーバー側やCDN側のキャッシュも見ます。
4. WordPressテーマやプラグインの出力が別ファイルを読んでいる
WordPressでは、編集したCSSファイルと実際に読み込まれているCSSファイルが違うこともあります。
たとえば、次のようなケースです。
- 子テーマではなく親テーマのCSSを編集している
- ビルド後の
style.min.cssが読み込まれているのに、元のstyle.cssを編集している - プラグインがCSSを結合・圧縮して別名で出力している
- ブロックテーマや追加CSSの出力が別の場所にある
キャッシュを疑う前に、DevToolsで実際に読み込まれているファイルURLを確認すると、無駄な作業を減らせます。
まず試す確認手順
変更が反映されないときは、いきなり設定を大きく変えず、表示確認から順に進めます。
手順1: ハードリロードする
通常の更新で変わらない場合は、ハードリロードを試します。
よく使う操作は次の通りです。
- Windows Chrome / Edge:
Ctrl + F5またはCtrl + Shift + R - macOS Chrome:
Command + Shift + R - Safari: 開発メニューや履歴削除を使う場合がある
これは閲覧者全員への対処ではなく、制作者側の確認用です。本番サイトで全ユーザーに確実に新しいCSSを読ませたい場合は、後述するURL変更やバージョン付けが必要です。
手順2: DevToolsで実際の読み込みを確認する
ChromeやEdgeでは、ページ上で右クリックして「検証」を開き、Networkタブを使います。
確認するポイントは次の3つです。
- 対象のCSSや画像のURLが、編集したファイルと一致しているか
- Statusが
200か、304か、あるいはキャッシュ由来か - Response Headersに
Cache-ControlやETag、Last-Modifiedがあるか
304 Not Modified は、ブラウザがサーバーに確認した結果、「前に持っているファイルでよい」と判断された状態です。ファイルが本当に更新されていないのか、サーバー側の更新時刻やヘッダーが期待通りでないのかを見ます。
手順3: URLを直接開く
CSSや画像のURLを直接ブラウザで開くのも有効です。
たとえば、HTMLで次のCSSを読んでいるなら、
<link rel="stylesheet" href="https://example.com/wp-content/themes/sample/style.css">
ブラウザでこのURLを直接開き、CSSの中身が新しいか確認します。
ここで古い内容が表示されるなら、HTML側の問題ではなく、CSSファイルそのもの、サーバー側キャッシュ、CDN、アップロード先の取り違えを疑います。
実務で使う対処法
一時的な確認と、本番反映で使う対処は分けて考えます。
制作中: キャッシュを無効にして確認する
制作中は、DevToolsのNetworkタブでキャッシュを無効にする方法が便利です。
Chrome DevToolsでは、Networkパネルを開いた状態で「Disable cache」をオンにします。これにより、DevToolsを開いている間はキャッシュを使わずに読み込みを確認できます。
この方法は、CSSを何度も直しながら見た目を確認する場面に向いています。ただし、閲覧者のブラウザ設定を変えるものではありません。
本番反映: ファイルURLを変える
本番サイトでは、ファイルの中身を変えたときにURLも変えるのが確実です。
よく使う方法は2つあります。
<link rel="stylesheet" href="/css/style.css?v=20260707">
または、ファイル名自体を変えます。
<link rel="stylesheet" href="/css/style.20260707.css">
URLが変わると、ブラウザは別のファイルとして扱います。古い style.css?v=20260701 を持っていても、新しい style.css?v=20260707 は改めて取得されます。
WordPressでは、wp_enqueue_style() の第4引数でバージョンを付けるのが一般的です。
wp_enqueue_style(
'theme-style',
get_stylesheet_uri(),
array(),
'20260707'
);
この例では、出力されるCSSのURLにバージョン情報が付きます。テーマ更新時にこの値を変えれば、閲覧者のブラウザにも新しいCSSを読ませやすくなります。
WordPress公式の関数リファレンスでも、wp_enqueue_style() はスタイルシートを登録・読み込みする関数として説明され、バージョン指定用の引数を持っています。
画像: 同じファイル名で上書きしない
画像は、CSS以上に「差し替えたのに変わらない」が起きやすいファイルです。
たとえば、次のように同じURLのまま画像だけ上書きすると、古い画像が残ることがあります。
<img src="/images/banner.jpg" alt="キャンペーンバナー">
確実に切り替えたいなら、ファイル名を変えます。
<img src="/images/banner-202607.jpg" alt="キャンペーンバナー">
キャンペーン画像、ロゴ、ファーストビュー画像のように、見た目の変更が重要な画像ではこの方法が扱いやすいです。CMSのメディア差し替え機能を使う場合でも、実際のURLが変わるか確認しておくと安心です。
入力例と出力例で見るキャッシュ対策
ここでは、CSSの修正が反映されない場面を最小例で見ます。
NG例: 同じURLのままCSSだけ更新する
HTMLは次のままです。
<link rel="stylesheet" href="/assets/site.css">
CSSを変更します。
.button {
background: #0b65c2;
color: #fff;
}
期待する表示は青いボタンです。しかし、ブラウザやCDNが古い /assets/site.css を返していると、前の色のまま表示されます。
問題はCSSの文法ではなく、同じURLで古いファイルが再利用されている点です。
改善例: URLにバージョンを付ける
HTML側でCSSのURLを変えます。
<link rel="stylesheet" href="/assets/site.css?v=20260707">
このとき、ブラウザから見るURLは /assets/site.css ではなく /assets/site.css?v=20260707 です。前回の /assets/site.css?v=20260701 とは別のURLとして扱われます。
期待される読み込みは次のようになります。
Request URL: https://example.com/assets/site.css?v=20260707
Status Code: 200
DevToolsのNetworkタブでこのURLが表示され、新しいCSS内容が返っていれば、キャッシュ対策としては前に進んでいます。
Cache-Controlをどう考えるか
キャッシュ設定は、短ければよいわけでも、長ければよいわけでもありません。ファイルの変わりやすさで分けます。
| 対象 | 考え方 | 実務での扱い |
|---|---|---|
| HTML | 内容が変わりやすい | 短め、または再検証しやすくする |
| CSS / JavaScript | 変更時だけ新しく読ませたい | バージョン付きURLやファイル名変更と組み合わせる |
| ロゴ・バナー画像 | 見た目の差し替えが重要 | 同名上書きより別名アップロードが安全 |
| フォント・ライブラリ | 頻繁に変わらない | 長期キャッシュと相性がよい |
長期キャッシュを使うなら、ファイルの中身が変わったときにURLも変える運用が必要です。逆に、URLを変えない運用なら、長すぎるキャッシュ期間はトラブルの原因になります。
MDNの Cache-Control リファレンスでは、max-age や no-cache などのディレクティブが説明されています。初心者が最初に押さえるなら、まずは次の違いで十分です。
max-age: 何秒間キャッシュを新鮮とみなすかno-cache: 保存禁止ではなく、再利用前にサーバーへ確認させる指定no-store: レスポンスを保存しない指定
no-cache は名前だけ見ると「キャッシュしない」と誤解しやすいですが、実際には再検証を求める指定です。ログイン後の個人情報ページなど、保存自体を避けたい場面では no-store を検討します。
WordPressでよくある確認ポイント
WordPressでは、テーマ、プラグイン、サーバー機能が重なりやすいため、確認順を決めておくと迷いにくくなります。
テーマのCSSを更新した場合
まず、実際に読み込まれているCSSを確認します。
- 親テーマと子テーマのどちらを編集したか
style.cssとstyle.min.cssのどちらが読み込まれているか- キャッシュプラグインがCSSを結合していないか
wp_enqueue_style()のバージョンが古いままではないか
テーマファイルを直接編集しても、ビルド済みCSSやプラグイン生成CSSが読まれていれば反映されません。DevToolsでURLを確認するのが近道です。
画像を差し替えた場合
WordPressのメディアライブラリで画像を差し替えるときは、表示中のURLが新しくなっているか見ます。
同じファイル名で上書きする運用では、ブラウザやCDNに古い画像が残ることがあります。重要な画像は、別ファイル名でアップロードし、記事やテーマ側の参照先を変える方が確認しやすいです。
キャッシュプラグインを使っている場合
キャッシュプラグインを使っているサイトでは、変更後にプラグイン側のキャッシュ削除も必要になることがあります。
確認する場所は、主に次の3つです。
- ページキャッシュ
- CSS / JavaScriptの結合・圧縮キャッシュ
- 画像最適化や遅延読み込みのキャッシュ
プラグインによって名称は違いますが、「キャッシュ削除」「Purge」「Clear cache」のような操作を探します。CDNを併用している場合は、CDN側の削除も必要です。
よくある失敗と対処
キャッシュ問題は、見た目が変わらないためCSSの書き方ミスと混同されがちです。次の順で確認すると、原因を切り分けやすくなります。
失敗1: CSSだけを何度も書き直す
画面が変わらないと、CSSセレクタやプロパティを疑いたくなります。
もちろんCSSの指定ミスもありますが、DevToolsで新しいCSSが読み込まれていないなら、書き方以前の問題です。まずNetworkタブで対象ファイルのURLと中身を確認します。
失敗2: 自分のブラウザだけで判断する
自分のブラウザだけ古い場合と、全員に古いファイルが返っている場合では対処が違います。
切り分けには、次の確認が使えます。
- 別ブラウザで見る
- スマホのモバイル回線で見る
- URLに一時的なクエリを付けて見る
- DevToolsでレスポンスヘッダーを見る
自分だけならブラウザキャッシュ、本番全体ならサーバー・CDN・プラグイン側の可能性が高くなります。
失敗3: ?v=1 のまま放置する
バージョン付けは有効ですが、値を変えなければ意味がありません。
<link rel="stylesheet" href="/css/style.css?v=1">
このままCSSを更新しても、URLは変わりません。更新日、テーマバージョン、ビルド番号など、変更時に確実に変わる値を使います。
<link rel="stylesheet" href="/css/style.css?v=20260707">
WordPressなら、テーマのバージョンやファイル更新時刻を使う方法もあります。ただし本番環境でファイル更新時刻を毎回参照する実装は、サーバー構成によって負荷や運用差が出ることがあります。小規模サイトでは便利ですが、チーム運用ではリリース番号に寄せる方が管理しやすいです。
代替手段と使い分け
キャッシュ対策には複数の方法があります。目的によって選びます。
| 方法 | 向いている場面 | 注意点 |
|---|---|---|
| ハードリロード | 制作者本人の確認 | 閲覧者全員には効かない |
| DevToolsのDisable cache | 制作中のCSS確認 | DevToolsを開いている間の確認用 |
| クエリ文字列でバージョン付け | CSSやJSの更新反映 | 更新時に値を変える必要がある |
| ファイル名にハッシュや日付を入れる | 本番運用、ビルド環境 | HTMLやCMS側の参照も変える必要がある |
| CDNのPurge | CDNが古いファイルを返す場合 | 反映に時間差があることがある |
| キャッシュ期間の見直し | 頻繁に変わるファイル | 短すぎると表示速度に不利 |
初心者向けに一つ選ぶなら、制作中はDevTools、本番反映はURL変更です。この2つを分けて覚えるだけで、CSSや画像の反映トラブルはかなり整理しやすくなります。
変更が反映されないときのチェックリスト
最後に、実務でそのまま使える確認順をまとめます。
- 変更したファイルと、実際に読み込まれているURLが一致しているか
- ハードリロードで変わるか
- DevToolsのNetworkタブで新しいCSS・画像が返っているか
Cache-Controlのmax-ageが極端に長くないか- WordPressのキャッシュプラグインを削除したか
- CDNやサーバー側のキャッシュを削除したか
- CSSや画像のURLに新しいバージョンが付いているか
- 同じファイル名で画像を上書きしていないか
- 別ブラウザ、別端末、モバイル回線でも同じ状態か
キャッシュは高速化に必要な仕組みです。避けるものではありません。大事なのは、更新したいファイルだけを確実に新しいURLで読ませることです。
CSSや画像が反映されないときは、まず「書いた内容が間違っているのか」「新しいファイルがそもそも読まれていないのか」を分けて見ます。次に見るべき場所は、DevToolsのNetworkタブです。そこに表示されるURLとレスポンスヘッダーが、原因の多くを教えてくれます。