ブラウザキャッシュとCloudflareキャッシュは別物：Cache-Control、Edge TTL、公開後の更新

Sat, 13 Jun 2026 10:12:32 +0800

Cloudflareのキャッシュを設定するとき、最も混同しやすいのは次の2つです。

Cloudflareのエッジノードがどれだけ長くキャッシュするか。
ユーザーのブラウザがローカルでどれだけ長くキャッシュするか。

どちらもキャッシュですが、制御している層が違い、リスクも違います。

静的ブログでは、Cloudflareのエッジキャッシュは少し攻めてもよく、ブラウザキャッシュは控えめにするのが安定します。Cloudflareのキャッシュは管理画面やAPIで削除できますが、ユーザーのローカルブラウザキャッシュはサイト管理者が直接消せないからです。

まず三層を分ける

1回のアクセスは、おおよそ次の三層を通ります。

ブラウザ
  ↓
Cloudflare エッジノード
  ↓
VPS / Nginx / Hugo 静的ファイル

重要なキャッシュは主に2種類あります。

Browser cache：ユーザーの端末上に保存されるブラウザキャッシュ。
Edge cache：Cloudflareのエッジノード上に保存されるキャッシュ。

オリジンのNginxが返すCache-Controlはブラウザに影響し、CDNにも影響する場合があります。CloudflareのCache RulesではEdge TTLとBrowser TTLを別々に設定できます。さらにResponse Header Transform Rulesを使えば、最終的にブラウザへ返すレスポンスヘッダーも書き換えられます。層を分けて考えないと、「キャッシュを設定した」と思っても、実際には一部しか制御できていないことがあります。

Cache-Controlは誰を制御するのか

Cloudflareの学習センターでは、Cache-Controlをブラウザや中間キャッシュにリソースの扱い方を伝えるHTTPレスポンスヘッダーとして説明しています。

よくある例です。

`1`	`Cache-Control: public, max-age=300`

このレスポンスはキャッシュ可能で、ブラウザは最大300秒間新鮮なものとして扱えます。

`1`	`Cache-Control: private`

これはブラウザのようなプライベートキャッシュにだけ適しており、CDNのような共有キャッシュには保存すべきではない、という意味です。

`1`	`Cache-Control: no-store`

どこにもキャッシュしない、という意味です。非常に機密性の高いデータに向いています。

`1`	`Cache-Control: no-cache`

名前は少し紛らわしいです。完全にキャッシュしないという意味ではなく、キャッシュを使う前にサーバーへ更新確認が必要という意味です。通常はETagやLast-Modifiedと組み合わせます。

`1`	`Cache-Control: s-maxage=86400`

s-maxageはCDNなどの共有キャッシュ向けです。ブラウザはmax-ageなどに従いつつ、CDNだけをより長くキャッシュさせることができます。

つまり、Cache-Controlはブラウザ専用でもCDN専用でもありません。キャッシュに関する指示の集合であり、どの層が採用し、どの層が上書きするかは中間設定次第です。

Cloudflare Edge TTLとBrowser TTLの違い

Cloudflareの2つのTTLは分けて見ます。

Edge TTLは、Cloudflareエッジノードがどれだけ長くキャッシュするかを決めます。

たとえば：

`1`	`Cloudflare Edge TTL = 1 day`

これは、Cloudflareがページ、画像、CSS、JSなどをエッジノードに1日保存できるという意味です。訪問者が同じURLを再度リクエストしたとき、キャッシュが命中すればCloudflareが直接返し、VPSへ戻りません。

Browser TTLは、ブラウザがどれだけ長くキャッシュするかを決めます。

たとえば：

`1`	`Browser TTL = 5 minutes`

これは、ブラウザがリソースを受け取ったあと、最大5分間ローカルで新鮮なものとして扱えるという意味です。5分以内ならローカルキャッシュを直接使うことがあります。5分を過ぎると、再検証または再リクエストが必要になります。

最大の違いは次の点です。

Edge cacheはサイト管理者がpurgeできる。
Browser cacheはユーザーのPC内にあり、サイト管理者は直接消せない。

そのため、HTMLページに長いブラウザTTLを付けるのはおすすめしません。記事を更新してCloudflareをpurgeしても、ユーザーのブラウザがローカルの古いページを表示し続ける可能性があります。

静的ブログでHTMLをキャッシュできる理由

動的サイトではHTMLを安易にキャッシュできません。ページにログイン状態、ユーザープロフィール、カート、推薦内容、権限情報などが含まれる可能性があるからです。

静的ブログは違います。Hugoが生成するページは通常、純粋な静的ファイルです。

ホームページ。
記事ページ。
カテゴリページ。
タグページ。
多言語ページ。
RSS。
sitemap。

これらは基本的にすべての訪問者に同じ内容を返すため、CloudflareでHTMLをキャッシュできます。これによりオリジンへのリクエストを減らし、海外からのアクセスも速くできます。

重要なのは次の考え方です。

1
2

Cloudflare Edge は長めでもよい
ブラウザ Browser は短めにする

例：

1
2

Cloudflare Edge TTL = 1 day
Browser TTL = 5 minutes

Cloudflareは1日キャッシュできますが、ユーザーのブラウザは5分だけキャッシュします。

毎回purge allするならEdge TTLは長めにできる

デプロイスクリプトが毎回Cloudflareのpurge everythingを呼ぶなら、Edge TTLは長めにできます。

流れはこうです。

1
2
3

通常時：Cloudflareが1日キャッシュして回源を減らす
公開時：新しいpublicをアップロードしてpurge all
公開後：Cloudflareがオリジンから新しい内容を取得する

この方式は静的ブログに向いています。サイト内容はリアルタイムに変わらず、更新もデプロイ時に集中するからです。

Edge TTLは1日でも1か月でも構いません。違いは主にリスク許容度です。

1 day：purgeに失敗しても、古い内容は最大1日で自然に切れる。
1 month：キャッシュヒット率は高いが、purge失敗時に古い内容が長く残る可能性がある。

個人ブログなら、まず1 dayから始めるほうが無難です。

ブラウザも長期キャッシュにしない理由

ブラウザキャッシュが長いほど再訪問は速くなりますが、更新制御は難しくなります。

たとえばHTMLに次を設定するとします。

`1`	`Cache-Control: public, max-age=31536000`

ユーザーが記事ページを一度訪問すると、ブラウザはそのページを1年間新鮮と見なす可能性があります。その後に誤字修正、リンク更新、本文修正をしてCloudflareをpurgeしても、そのユーザーのローカルキャッシュには効かない場合があります。

静的アセットを長期キャッシュできるのは、多くの場合フィンガープリント付きファイル名だからです。

1
2

/scss/style.min.5e5f1f8f7ce389becd0a48fe3eff3e1c79b2750a903584200a3a6fc54ae1e664.css
/ts/main.9acdcb7a78e911f2c617b8cd4af2eab573c04169dddc51c052977dde63210ced.js

内容が変わればファイル名も変わるため、古いキャッシュは新しいページが参照する新ファイルに影響しません。

しかしHTMLのURLは通常変わりません。

`1`	`/2026/06/13/browser-cache-vs-cloudflare-edge-cache/`

そのため、HTMLには短いブラウザTTLが向いています。

シンプルな設定例

ファイル種別ごとに細かく分けたくないなら、統一ポリシーで始められます。

1
2
3

Cloudflare Edge TTL = 1 day
Browser TTL = 5 minutes
毎回公開時に purge everything

Cloudflare Cache Ruleがエッジキャッシュを担当します。

`1`	`(http.host in {"knightli.com" "www.knightli.com"} and not starts_with(http.request.uri.path, "/cdn-cgi/"))`

動作：

Eligible for cache
Edge TTL: 1 day
Browser TTL: 5 minutes
Query string: ignore

オリジンのNginxがCSS、JS、画像に長いCache-Controlを設定していて、ブラウザへ返すすべてのリソースを5分に統一したい場合は、CloudflareにResponse Header Transform Ruleを追加します。

Set:
Cache-Control: public, max-age=300

Remove:
Expires

これで次の形になります。

EdgeキャッシュはCloudflare Cache Ruleで制御する。
BrowserキャッシュはCloudflareのレスポンスヘッダールールで統一する。
NginxはブラウザTTL統一のために変更しなくてよい。

分層キャッシュが必要になる場合

より高い性能を狙うなら、リソース種別ごとに分けられます。

HTML:
  Edge TTL: 1 day
  Browser TTL: 5 minutes

CSS / JS / 画像 / フォント:
  Edge TTL: 1 month
  Browser TTL: 1 month または 1 year

RSS / sitemap:
  Edge TTL: 1 hour
  Browser TTL: 5 minutes

この構成はより効率的ですが、維持コストも上がります。個人ブログなら最初からここまで複雑にする必要はありません。

すべての静的アセットにhash付きファイル名があることを確認してから、CSS、JS、画像のBrowser TTLを長くすると安定します。

有効かどうかを確認する

curl -Iで同じURLを連続してリクエストします。

1
2

curl.exe -I https://knightli.com/
curl.exe -I https://knightli.com/

見るべきヘッダーは2つです。

1
2

cf-cache-status: HIT
cache-control: public, max-age=300

cf-cache-status: HITはCloudflareエッジキャッシュに命中したことを示します。

cache-control: public, max-age=300は、ブラウザ側のキャッシュTTLが最大300秒であることを示します。

もし次が出た場合：

`1`	`cf-cache-status: MISS`

初回アクセス、purge直後、ルール未反映、またはキャッシュ条件に合っていない可能性があります。再度リクエストするとHITになることがよくあります。

CSSやJSでまだ次が見える場合：

`1`	`cache-control: public, max-age=31536000, immutable`

ブラウザキャッシュヘッダーがまだオリジン、またはより優先度の高いルールから来ています。静的アセットの長期キャッシュを受け入れるか、Cloudflare Response Header Transform Ruleで上書きします。

まとめ

ブラウザキャッシュとCloudflareキャッシュは同じものではありません。

実用的な判断は次の通りです。

Cloudflare Edgeキャッシュは攻めてもよい。サイト管理者がpurgeできるから。
ブラウザキャッシュは慎重にする。ユーザーのローカルキャッシュは消せないから。
HTMLページには短いBrowser TTLが向いている。
hash付き静的アセットには長いBrowser TTLを使える。
毎回公開時にpurge allする静的ブログでは、Edge TTL 1日は安定した出発点になる。

Hugoの静的ブログなら、まず次の設定で十分です。

1
2
3

Cloudflare Edge TTL = 1 day
Browser TTL = 5 minutes
毎回公開時に purge everything

これだけでCDNによる高速化の大部分を得られ、記事更新後に古いHTMLがユーザーのブラウザに長く残る問題も避けやすくなります。

参考リンク

Cloudflare：https://www.cloudflare.com/zh-cn/learning/cdn/glossary/what-is-cache-control/
Cloudflare Cache Rules：https://developers.cloudflare.com/cache/how-to/cache-rules/
Cloudflare Response Header Transform Rules：https://developers.cloudflare.com/rules/transform/response-header-modification/

ブラウザキャッシュ on KnightLiブログ