Webページの更新が反映されない？ブラウザー・配信側のキャッシュ確認方法

どのページの、どの変更を確かめる？

先に公開対象のURLと、更新後に読めるはずの文章を一つ決めます。管理画面で原稿を保存したことと、訪問者へその原稿が返ったことは別です。下書き、公開待ち、別ページや別のファイルを見ていないかも確認します。

WordPressなら対象の投稿・固定ページを開き、現在の保存内容と公開状態、公開URLを照合します。そのURLを訪問者が使う条件で読み、変更した一文を探します。編集画面のプレビューだけで公開側の確認を終えないでください。

ログイン中とログアウト後、同じ端末と別端末は、最初から同じ結果とは限りません。本文が違ったら、URL、確認時点、ブラウザー、ログイン条件、再読込の方法をそろえて比べます。Cookieを消して全条件を変える前に、今どの条件で見ているかを確かめます。

本人の相談にも、管理画面では変更を見られるのにログアウト後は見られない、または自分のPCと電話・別PCで表示が違うという報告があります。報告はこの困りごとの根拠ですが、返信で挙げられたCDNや追加機能を、読者の環境の原因と決める根拠にはしません。

参考：本人の相談：管理側とログアウト側で変更が違う

参考：本人の相談：自分のPCと別端末で変更が違う

保存はブラウザーだけにある？

キャッシュは、以前取得・生成した結果を保存し、後で再利用する仕組みです。ブラウザー内の保存と、複数の訪問者へ配る側の保存を分けます。保存場所が違えば、確かめる画面や更新する対象も違います。

配信側には、ページを代理で返す仕組みや、内容を効率よく届けるCDNの保存があります。WordPress側の追加機能やサーバーが、生成したページを保存する場合もあります。使っている製品と構成は管理担当が確かめ、古い表示だけから特定の保存層を断定しません。

ブラウザーがページの処理を補助するservice workerという仕組みを使うサイトもあります。その保存は、通常のHTTPの保存だけを無効にした条件と分けて調べます。使っていないサイトに新しく導入する必要はありません。

ブラウザーの保存を使わずに読む試行で古い本文が返っても、CDNが原因と決めません。生成元に古い原稿が残る、別の公開先を開く等の可能性も、現在の本文と設定で確かめます。サイト全体の追加機能を止める前に、比較する一件と保存場所を絞ります。

参考：MDN：ブラウザー専用と共有・管理された保存

実際の要求と返った本文をどこで読む？

Chromeの開発者向け確認画面DevToolsを開き、Networkへ進みます。Networkはページの読み込み一覧です。画面を開いて記録を開始してから対象ページを再読込し、今回のページ本体の行を選びます。Typeがdocumentの行や完全なURLを手掛かりに、画像や別ページの行と取り違えないようにします。

行のStatusは応答の番号や処理結果、Sizeは転送量や保存からの取得の表示です。Headersは要求・応答の項目、Responseは返された本文を読む欄です。要求URLと応答項目を確認し、Responseで変更した文章を探したうえで実表示と照合します。200の番号だけを更新済みの判定にしません。

通常の再読込を記録したら、比較のためDisable cacheを有効にし、DevToolsを開いたまま同じURLを再読込します。これはブラウザーの保存を無効にする確認条件です。配信側や生成元の保存をまとめて消した結果ではありません。一時条件と取得の違いを残し、確認が終わったら元へ戻します。

前のログが残る場合は、新しく要求した行とURLを特定します。応答の本文が読めない場合は未確認と残し、表示だけで中身を埋めません。認証情報や個人情報を含む要求・応答の丸ごと共有は避け、相談には必要な項目だけを使います。次は説明用の架空二例です。

図の二つの再読込条件を、項目ごとに読む

二つの再読込条件で取得方法の記録は違いますが、表示されたのはどちらも古い相談案内です。ブラウザー保存を無効にした側にネットワーク取得・応答200の記録があっても、新しい本文を得たことや原因確定とは別です。ブラウザー保存の無効化を、共有保存も破棄したことへ広げません。

両記録に共通する対象・期待と表示

対象ページのURL

https://site.example/services/

閲覧の条件

ログアウト状態の同じブラウザー

期待する本文

新しい相談案内

表示された本文

古い相談案内

再読込の条件

通常の再読込

通常の再読込

ブラウザー保存を無効にした再読込

ブラウザーのキャッシュを無効にして再読込

ブラウザーキャッシュの無効化

通常の再読込

無効にしていない

ブラウザー保存を無効にした再読込

無効にした

取得方法の記録

通常の再読込

disk cache と表示されたという記録

ブラウザー保存を無効にした再読込

ネットワーク取得と表示されたという記録

応答番号

通常の再読込

未確認

ブラウザー保存を無効にした再読込

200

応答のCache-Control

通常の再読込

未確認

ブラウザー保存を無効にした再読込

public, max-age=600

応答のAge

通常の再読込

未確認

ブラウザー保存を無効にした再読込

120

両方とも未確認の原因と設定後

実際の原因の層

未確認

設定後の結果

未確認

PC原寸画像を開く · モバイル原寸画像を開く

通常の再読込ではdisk cacheという、端末の保存から取得した表示の記録があります。一方、ブラウザーの保存を無効にした例はネットワーク取得・200ですが、読めた本文は同じ古い相談案内です。両方とも実際の原因と設定後の結果は未確認です。

この二記録から言えるのは、今回の異なる再読込条件でも古い案内が見えたことです。ブラウザーの保存を無効にする操作だけで更新確認が終わった、全訪問者にも同じ状態、特定のCDNが原因という結論にはしません。

参考：Chrome：読み込みの記録とHeaders・Response

参考：Chrome：ブラウザーキャッシュを無効にする確認条件

応答のキャッシュ指定は何を意味する？

Cache-Controlは、要求や応答に付く保存・再利用の方針です。HeadersでRequest Headers（要求側）とResponse Headers（応答側）を分けて読みます。ブラウザーが今回の要求で求めた条件と、提供側が返した方針は同じ欄ではありません。項目が見つからないことを、保存なしや数値0という結果にしないでください。

no-cacheは、保存した内容を使い直す前に提供元で有効か確かめる指定です。この再確認を再検証と呼び、保存そのものを禁止する意味ではありません。no-storeは、その要求・応答を新たに保存しない指定です。今返す方針を変えることと、すでに残っている保存を消すことを分けます。

privateは共有側で保存させず、ブラウザー等の専用側での保存を許す指定です。publicは共有側を含めて保存を許す指定ですが、常に再利用してよいという無条件の保証ではありません。max-ageは応答を新鮮と扱える期間を秒で指定し、s-maxageは共有側に対する期間です。これらは公開原稿が新しい版だと証明する値ではありません。

Ageは、応答が生成・再検証されてからの経過を見積もった秒数を示す応答項目です。架空二例目のpublic, max-age=600とAge 120は、その記録にあった文字列です。実際の変更反映までの待ち時間や、特定の製品の保存時間と読み替えません。未取得なら未確認のままです。

再検証で返る304は、条件付きの確認に対し変更なしと通知し、保存済みの本文を利用する応答です。新しい本文を丸ごと返した番号ではありません。200でも期待した変更文が含まれるかを別に読みます。戻るボタンで過去の表示へ戻る操作は、新しくページを読む要求と区別して確認してください。

参考：MDN：Cache-Controlの要求側・応答側と各指定

参考：HTTP標準：保存、共有と再利用の指定

参考：MDN：再検証、304と履歴の表示

参考：MDN：Age応答項目の秒数

方針を変えれば、古い保存も消える？

応答の方針を変更しても、新しい要求が提供元へ届かず、途中の保存から返る間は、新しい指定が届かない場合があります。no-storeを追加しただけで、すべての既保存が消えたとは判断しません。これからどう保存するかと、今ある保存をどう扱うかは二つの作業です。

まず管理された保存を使っている製品と管理画面、対象URL、編集権限を確かめます。管理担当は現製品の文書で、対象ページだけの保存を破棄する方法があるか、生成元の保存や別URLも関係するかを調べます。purgeなどの表示は保存済み内容を破棄する操作を指す場合がありますが、範囲は製品ごとに確認します。

更新ごとに確認する運用なら、対象ページを変えた後に、どの保存を更新・破棄するかを決めます。試し環境で原稿と配信設定の変更前を保管し、対象URLの応答と表示を比較します。保存・再利用の方針を変更する場合も、そのページに必要な更新性、閲覧条件、負荷を考え、全サイトへ一律に同じ値を足しません。

試し環境で対象を限定して保存を破棄・再生成した後、同条件の要求を取り直します。提供元で新しい本文を生成できるか、配信側から同じ本文が返るか、ブラウザーで読めるかを順に対応させます。差が残った場所の本文・要求・設定を比較し、別の設定を重ねる前に変更前へ戻す方法を使います。

保存の破棄後には再生成や取り直しが必要です。全サイトの保存破棄、全Cookie削除、全追加機能停止を万能手順にせず、負荷やログインへの影響、戻す担当を確認します。本稿の架空例は実設定・破棄・成功の記録ではありません。

参考：MDN：管理された保存と既保存の削除の範囲

参考：MDN：方針変更だけでは途中の既保存を消せない

何をそろえて再確認する？

変更前後で、同じ公開URL、ログイン条件、期待する本文、再読込方法、今回の要求をそろえます。応答の番号と保存方針だけでなく、返った本文と実表示に変更文があるかを比較します。試行条件を変えた結果を、通常の訪問者全体の結果へ広げません。

次の例では、期待する新しい案内と対象URLだけがあり、閲覧や読み込みの記録は未取得です。表示がない、保存時間0、エラーや原因がないという結果へ埋めません。

確認ができていない場合は、公開対象と期待する一文を確かめ、Networkを開いてそのURLの要求と本文を読むところへ戻ります。URL変更・301転送の動作は別の確認です。同じURLの文章更新を理由に、新しい転送設定を足す必要はありません。

今日の一歩は、古いままに見える一ページを選び、通常の再読込とブラウザー保存を使わない条件で、要求・本文・表示を並べて読むことです。その比較で次に見る保存層を絞り、管理された保存の扱いと応答方針を分けて確認できます。

1ページのURLを移す場合の301確認

デザインの実装と公開後の点検