更新したのに古い画面が出る？Webのキャッシュを知る

Webページの表示では、以前に取得したデータを再利用する「キャッシュ」が使われます。表示を速める助けになる一方、更新が届く経路を分かりにくくすることもあります。保存場所と再利用の条件を整理します。

毎回取りに行かず、前のデータを使う

同じロゴ画像をページを開くたびに最初から取得すると、同じ通信が繰り返されます。一度受け取った画像を保存し、使ってよい間は再利用できれば、その通信を省けます。

HTTPのキャッシュは、この再利用を支える仕組みです。HTTPキャッシュの仕様であるRFC 9111は、保存した応答を再利用する仕組みと、その条件を定めています。

ただし、保存したデータは公開元の変更を自動的に知っているわけではありません。「どれだけの間、再確認せず使ってよいか」「使う前に更新の有無を確かめるか」といった条件も必要になります。

キャッシュには、利用者のブラウザー内にあるものと、複数の利用者のために配信経路で共有されるものがあります。CDNと呼ばれる配信サービスも、共有キャッシュを使う代表的な場所です。

たとえば、案内ページの画像を差し替えたのに、一台だけ前の画像が出る場面を考えてみます。ブラウザー内の保存が関係している可能性がありますが、それだけで原因は決まりません。配信側に古い画像が残っている、編集内容がまだ公開されていない、別のURLを見ている、といった可能性もあります。

この例は特定の障害を調査した結果ではありません。「古く見える」という現象と、「どこが古いか」という原因を分けるための例です。

HTTPでは、Cache-Controlというヘッダーで保存や再利用の条件を伝えます。ヘッダーは、本文とは別に応答へ添えられる情報です。

似た名前でも、指示する内容は異なります。RFC 9111の応答ディレクティブでは、次のように区別されています。ここでは引数を付けないno-cacheを扱います。

表が見切れる場合は横にスクロールできます

no-cacheは、名前に反して「一切保存しない」という意味ではありません。開発担当者と更新方法を相談するときも、保存を止めたいのか、再利用前に確認してほしいのかを分けると、意図が伝わりやすくなります。

まず、編集画面の保存と、読者向けの公開が両方終わっているかを確認します。次に、見ているURLと、古く見える箇所を特定します。ページ全体なのか、一枚の画像なのかでも調べる対象は変わります。

別のブラウザーで同じURLを開くと、問題が一つのブラウザーに限られるかを比べられます。それでも同じなら、配信側のキャッシュや公開されたデータを開発担当者が調べる手掛かりになります。別ブラウザーでも古いことだけで、CDNが原因とは断定できません。

サイト全体の保存データを消す操作は、ログイン状態などに影響することがあります。最初からすべて消すより、URL、期待した表示、実際の表示を記録してから、対象のキャッシュを調べるほうが状況を共有しやすくなります。

なお、PWAにはHTTPキャッシュとは別に、アプリが管理する保存の仕組みもあります。通信がないときの表示は、PWAのオフライン対応で説明しています。

キャッシュは、前に受け取ったデータを条件付きで再利用する仕組みです。ブラウザーと配信側のどちらにも関係するため、更新が見えないときは、公開状態・URL・古く見える部分から順に確かめると原因を絞りやすくなります。