Cloudinary のキャッシュ検証テストで確認すべきポイント
Cloudinary を使った画像配信の動作確認をするとき、ブラウザキャッシュ、CDN キャッシュ、そして Cloudinary の画像（さらに、ある場合はオリジンの画像）を考慮する必要があります。
Enterprise のお客様では CNAME/プライベート CDN をセットアップして、カスタムの CDN キャッシュ時間を設定するのはよくあるユースケースであり、その検証をするにはキャッシュ挙動への適切な理解が必要です。
この記事では、Cloudinary を使った画像配信のキャッシュ設定が正しく動作しているかを確認するとき、どこを見ればよいのか、何に注意が必要なのかをまとめます。
Cloudinary の画像配信とキャッシュ
Cloudinary から画像が届くまでには以下の経路をたどります。
ブラウザ → Cloudinary CDN → Cloudinary サーバ
そして一言で「キャッシュ」といっても以下のような種類が存在します。
| 場所 | キャッシュの種類 | 特徴 |
|---|---|---|
| ブラウザ（RAM） | メモリキャッシュ | 最速; タブを閉じると消える |
| ブラウザ（HDD/SSD） | ディスクキャッシュ | ブラウザを再起動しても残る |
| Cloudinary CDN | CDN キャッシュ | ブラウザには存在しない; 複数のエッジサーバーで共有 |
ブラウザは メモリ → ディスク → CDN → オリジン の順に探し、見つかった時点でそこから返します。
デフォルトでは Cloudinary CDN のキャッシュ期間 は30日で、CNAME や fetch など条件により異なります。プライベート CDN でカスタム設定をする場合は、 max-age（ブラウザ向け）と s-maxage（CDN 向け）をそれぞれ設定します。パスごとに異なる値を設定することも可能です。
（参考：https://cloudinary.com/glossary/caching-images）
キャッシュヒットの確認
ブラウザキャッシュ
キャッシュ期間内外に2回目以降のアクセスを行い、開発者ツールを使ってブラウザキャッシュひヒットしたかどうか確認します。「Disable Cache」は無効にしてください。
Chrome の場合は「Size」列で以下のように表示されます：
(memory cache)：メモリキャッシュから返した(disk cache)：ディスクキャッシュから返した- 数値（例：231.57 kB）：ネットワークから取得した（=ブラウザキャッシュでない）
Firefox では「Transferred」列に cached 、Safari では「Transfer Size」列に (memory) や (disk) とやや表記は異なるものの、ほぼ同様の動きでした。
▲ ページをリロードしてメモリキャッシュにヒット
▲ 別タブで画像URLを開き、ディスクキャッシュにヒット
⚠️ 注意：画像単体で同じタブでのリロード
ソフトリロード（F5 / Ctrl+R / Cmd+R / ブラウザ更新ボタン 🔄 / 同じタブで同じURLにアクセス）、いわゆる通常の更新では、メインリソース（URLバーに入力した URL）はブラウザキャッシュを使わずにサーバーへ再検証リクエストを送ります。
一方、ページ内の <img> タグなどで読み込まれるサブリソースは、リロードしてもメモリキャッシュからそのまま返されます。
つまり、画像単体 URL への直アクセス & 同じタブでリロードをしてしまうと、キャッシュ期間内でもブラウザキャッシュが使われず、キャッシュ動作のテストになりません。
▲ サーバへ再検証リクエストが飛び、変更がなければ 304 (Not Modified) を返す
テストをする場合には、新しいタブで URL を開く、そしてできればページ内に埋め込んだ画像（サブリソース）で検証をすることで、一般ユーザーの実際の閲覧行動に近い条件でテストできます。
▲ Firefox で新規タブでページアクセスし、ディスクキャッシュにヒット
✏️ ソフトリロードの解説
ユーザがソフトリロードを実行する主な理由は2つです：
- ページが壊れている（表示崩れなど）
- コンテンツが古い（ニュースサイトなど）
毎回ページコンテンツすべてを再検証するとネットワーク負荷が膨大になるため、ソフトリロード時には画像などのサブリソースは再検証せず、問題であるメインリソースだけを再検証するという意図的なブラウザの仕様です。
参考：Chromium Blog - Reload, reloaded: faster and leaner page reloads（2017）
CDN キャッシュ
こちらも同様に開発者ツールで確認します。
対象のリクエストを選択し、Response Headers の Server-Timing を確認します。
desc=hit：CDN キャッシュにヒットしたdesc=miss：CDN キャッシュになく、Cloudinary サーバから取得した
▲ desc=miss（ただし、ページ内リロードしたため、メモリキャッシュにヒットしており、メモリキャッシュである元のアクセスが Cloudinary サーバから取得したものということになる）
💡 CDN キャッシュは必ずしもヒットするとは限らない
複数のブラウザで何度かアクセスしていても、必ずしも毎回 hit になるとは限りません。
Cloudinary の CDN は地理的に分散した複数のエッジサーバーで構成されており、ユーザーの近くのエッジから高速に画像を配信します。リクエストは拠点や負荷に応じて最適なエッジにルーティングされるため、アクセスごとに異なるエッジを経由することがあります。
そのため、あるエッジでキャッシュが生成されていても、キャッシュの共有されていない別のエッジを経由することで miss になる可能性があります。
💡 CDN キャッシュが「消えた」ことを確認する場合
Cloudinary 側でアセットを更新・キャッシュ無効化した後、CDN キャッシュが正しく消えているかを確認したいケースがあります。この場合に miss が返ってくれば期待通りですが、前述の通り miss がルーティングの問題である可能性も残ります。
確認をより確実にするには、miss を1回確認するだけでなく、数回リクエストして miss が続くかを確認するのが確実です。
参考
今回利用した検証に使ったページ：
ソフトリロードについて：
- https://stackoverflow.com/questions/45829055/why-doesnt-chrome-re-validate-in-memory-cache-when-doing-a-normal-reload
- https://blog.chromium.org/2017/01/reload-reloaded-faster-and-leaner-page_26.html
Cloudinary の CDN とキャッシュ：
