キャッシュの仕組み

Workers は、開発者が Cloudflare Cache に直接アクセスできるように、Cloudflare のグローバルネットワーク上に設計・構築されています。Cache は、静的コンテンツや動的コンテンツへ頻繁にアクセスするための、データセンターローカルな一時ストレージとして使えます。

Workers では Cache への書き込みができるため、Cloudflare CDN 上のキャッシュ動作をカスタマイズできます。キャッシュの利点については、Learning Center の記事 What is Caching? ↗ を参照してください。

Cloudflare Workers は Cache の前で実行されます。Cache から返されたアセットを変更することもできます。Cache から返されたアセットを変更すると、レスポンスへの署名やパーソナライズが可能になります。同時に、オリジンへの負荷を下げ、近くの拠点からアセットを返すことでエンドユーザーへの遅延も減らせます。

概念上、Worker から Cloudflare Cache と連携する方法は 2 つあります。

• Workers スクリプト内で fetch() を呼びます。Cloudflare 経由でプロキシされるリクエストは、Workers がなくてもゾーンの既定または設定済みの動作に従ってキャッシュされます（例: .jpg で終わるファイルなどの静的アセットは既定でキャッシュされます）。Workers では、次の方法でこの動作をさらにカスタマイズできます。

  • Cloudflare のキャッシュルールを設定する（request の cf オブジェクトを操作する）。

• Workers スクリプトから Cache API でレスポンスを保存します。オリジンから来ていないレスポンスもキャッシュでき、次のような細かい制御もできます。

  • cache.put() に渡すレスポンスに Cache-Control などのヘッダーを設定し、任意のアセットのキャッシュ動作をカスタマイズする。

  • cache.put() で Worker 自身が生成したレスポンスをキャッシュする。

Worker がキャッシュしたアセットを single-file purge でパージする場合、エンドユーザー向け URL はパージしないでください。代わりに、fetch リクエスト内の URL をパージします。たとえば、https://example.com/hello で動く Worker があり、この Worker が https://notexample.com/hello へ fetch リクエストを送るとします。

Cache から見ると、キャッシュされるアセットは fetch リクエスト内のアセット（https://notexample.com/hello）です。パージするには、https://notexample.com/hello をパージします。

エンドユーザー向け URL https://example.com/hello をパージしても効きません。Cache が見ている URL ではないためです。Worker 内で実際に fetch している URL を確認し、正しいアセットをパージしてください。

先の例では、https://notexample.com/hello は Cloudflare 経由でプロキシされていません。https://notexample.com/hello が Cloudflare 経由でプロキシされている（オレンジクラウド）場合は、notexample.com を所有し、notexample.com ゾーンから https://notexample.com/hello をパージする必要があります。

例を理解しやすくするため、次の図を確認してください。

flowchart TD
accTitle: Worker がキャッシュしたアセットの単一ファイルパージ
accDescr: この図は、ファイルのパージ方法を選ぶためのものです。
A("Worker スクリプトが <code>https://</code><code>example.com/hello</code> で動き、<br> この Worker が <code>https://</code><code>notexample.com/hello</code> へ <code>fetch</code> リクエストを送ります。") --> B(<code>notexample.com</code> は <br> Cloudflare 上のアクティブなゾーンですか?)
    B -- はい --> C(<code>https://</code><code>notexample.com/</code> は <br> Cloudflare 経由でプロキシされていますか?)
    B -- いいえ  --> D(元の <code>example.com</code> ゾーンから <br> <code>https://</code><code>notexample.com/hello</code> をパージします。)
    C -- はい --> E(<code>notexample.com</code> を <br> 所有していますか?)
    C -- いいえ --> F(元の <code>example.com</code> ゾーンから <br> <code>https://</code><code>notexample.com/hello</code> をパージします。)
    E -- はい --> G(<code>notexample.com</code> ゾーンから <br> <code>https://</code><code>notexample.com/hello</code> をパージします。)
    E -- いいえ --> H(アセットはパージできません。<br> <code>notexample.com</code> の所有者だけがパージできます。)

Cache API の操作で Cache に保存したアセットは、次の方法でパージできます。

• Worker 内で cache.delete を呼び、一致する request 変数のアセットのキャッシュを無効化します。

  • この方法でパージしたアセットは、Worker runtime が実行されたデータセンターのローカルに限られます。

• グローバルにアセットをパージするには、標準の キャッシュパージオプション を使います。Cache API の実装上、Cache API で保存したアセットのパージに使えるキャッシュパージエンドポイントは一部に限られます。

  • ゾーン上の全アセットは、Purge Everything 操作でパージできます。このパージは、設定した方法に関係なく、Cloudflare ゾーンに関連する全アセットをすべてのデータセンターの Cache から削除します。

  • Cache Tags は、Worker 内で response.headers.append() を呼び、Cache-Tag の値を動的にリクエストへ追加できます。設定したタグは、ゾーン上のキャッシュ済みアセットをすべて無効化せずに、選択的にパージするために使えます。

• 現時点では、Worker が設定したカスタムキャッシュキーを使う URL はパージできません。代わりに、Cache Rules で作成したカスタムキー を使います。あるいは、Purge Everything、タグ指定パージ、ホスト指定パージ、プレフィックス指定パージでアセットをパージします。

ブラウザキャッシュは、クライアントへ返すレスポンス（ハンドラーが返す Response インスタンス）の Cache-Control ヘッダーで制御します。Workers はこのヘッダーをレスポンスに設定して、ブラウザキャッシュの動作をカスタマイズできます。

このドキュメントに書いていない、Cloudflare Cache を制御するほかの手段には、Page Rules と Cloudflare のキャッシュ設定があります。JavaScript を書かずに、ある程度の粒度で制御したい場合は、Cloudflare の Cache をカスタマイズする方法 を参照してください。

Workers の文脈では、runtime が提供する fetch は Cloudflare Cache と通信します。まず fetch は、URL が別のゾーンに一致するかを確認します。一致する場合は、そのゾーンの Cache（または Worker）を通して読みます。一致しない場合は、URL が Cloudflare 以外のサイトでも、自身のゾーンの Cache を通して読みます。fetch のキャッシュ設定は、Cloudflare の設定に基づくキャッシュルールを自動適用します。fetch では、オブジェクトが Cache に到達する前に変更や検査はできません。ただし、どのようにキャッシュするかは変更できます。

レスポンスが Cache に入ると、レスポンスヘッダーに CF-Cache-Status: HIT が含まれます。CF-Cache-Status が付いていれば、オブジェクトがキャッシュを試みていると判断できます。

この テンプレート では、fetch を使って特定リクエストの Cloudflare Cache 動作をカスタマイズする方法を示します。

Cache API は、一時的なキーバリューストアと考えられます。キーは Request オブジェクト（より正確にはリクエスト URL）、値は Response です。

Cloudflare Cache で使えるキャッシュ名前空間は 2 種類あります。

• caches.default — caches.default で、fetch リクエストと共有するデフォルトキャッシュにアクセスできます。レスポンスを受け取ったあと、すでにキャッシュされているコンテンツを上書きしたいときに便利です。
• caches.open() — let cache = await caches.open(CACHE_NAME) で、fetch リクエストと共有しない名前空間キャッシュにアクセスできます。caches.open ↗ は caches.default と違い、非同期関数です。

Cache API を使う場面:

• キャッシュからレスポンスをプログラムで保存・削除したいとき。たとえば、オリジンが Cache-Control: max-age:0 ヘッダーを返し、変更できない場合です。代わりに Response をクローンし、ヘッダーを max-age=3600 に調整してから、Cache API で変更後の Response を 1 時間保存できます。

• fetch リクエストに頼らず、キャッシュから Response をプログラムで取得したいとき。たとえば、https://example.com/slow-response エンドポイントの Response がすでにキャッシュされているかを確認できます。あれば、遅いリクエストを避けられます。

この テンプレート では、Cache API の使い方を示します。Cache API の制限については、Limits を参照してください。

• Cache API
• Workers でキャッシュ動作をカスタマイズする