Cloudflare は Workers Cache を全プランで提供開始した。Worker がオリジンとなる SSR アプリや service binding / ctx.exports でつなぐ多段 Worker 構成向けに、各エントリポイントの前段に地域階層キャッシュを置ける。ゾーンの Cache Rules ではなく Worker 単位のキャッシュであり、Wrangler とレスポンスヘッダーだけで設定する。
有効化は Wrangler の cache.enabled を true にし、レスポンスに Cache-Control を付ける。タグ付け purge は Cache-Tag と ctx.cache.purge() を使う。
jsonc
{
"cache": { "enabled": true }
}主な挙動は次のとおり。
- キャッシュヒット時は Worker を実行せず、CPU 時間は課金されない。リクエスト自体は通常の Workers リクエスト単価がかかる
stale-while-revalidateに対応し、期限切れ後も古い応答を即返しつつバックグラウンドで更新できるVaryで Accept / Accept-Language など表現ごとに別バリアントを保持できる- キャッシュは Worker に紐づき、カスタムドメイン・workers.dev・プレビュー URL・Workers for Platforms でも動作する。プレビューは本番と別キャッシュ
- 下位・上位の 2 段地域キャッシュがデフォルトで有効。両方ミスしたときだけ Worker が実行される
- service binding や ctx.exports 経由の Worker 間呼び出しもキャッシュ対象。
ctx.propsはキャッシュキーに含まれ、認証済み API をユーザー単位で安全にキャッシュできる - Wrangler の
exportsでエントリポイントごとにキャッシュのオン・オフを切り替えられる。ゲートウェイはオフ、重い内部 entrypoint はオン、といった構成が取れる - Workers Observability ダッシュボードでヒット率・MISS / BYPASS / UPDATING などを確認できる
- Astro の
@astrojs/cloudflare/cacheプロバイダーで統合済み。TanStack Start や Vinext 経由の Next.js など他フレームワーク向けも進行中
課金面では、キャッシュヒットは CPU なしのリクエスト課金のみである。キャッシュ有効化後は、これまで無料だった静的アセット要求や Worker 間呼び出しもキャッシュ照会の分、通常のリクエスト単価がかかる点に注意が必要である。Workers Cache 専用 SKU や GB 単位のストレージ課金はない。ローンチ時点ではキャッシュ可能サイズは Free プラン上限の 512 MB に統一され、プラン別上限への移行は今後予定されている。