キャッシュの動作

Workersは、開発者がCloudflareキャッシュと直接相互作用できるように、Cloudflareのグローバルネットワークの上に設計され、構築されました。キャッシュは、一時的なデータセンター内のローカルストレージを提供し、静的または動的コンテンツに頻繁にアクセスする便利な方法を提供します。

開発者がキャッシュに書き込むことを許可することで、WorkersはCloudflareのCDN上でキャッシュの動作をカスタマイズする方法を提供します。キャッシュの利点については、Learning Centerの記事キャッシュとは？ ↗を参照してください。

Cloudflare Workersはキャッシュの前に実行されますが、キャッシュから返されたアセットを変更するためにも利用できます。キャッシュから返されたアセットを変更することで、応答に署名したりパーソナライズしたりすることができ、オリジンへの負荷を軽減し、近くの場所からアセットを提供することでエンドユーザーへのレイテンシを減少させることができます。

Cloudflareキャッシュとの相互作用

概念的には、Workerを使用してCloudflareのキャッシュと相互作用する方法は2つあります。

• Workersスクリプト内でfetch()を呼び出す。Cloudflareを通じてプロキシされたリクエストは、Workersがなくてもゾーンのデフォルトまたは設定された動作に従ってキャッシュされます（たとえば、.jpgで終わるファイルのような静的アセットはデフォルトでキャッシュされます）。Workersはこの動作をさらにカスタマイズできます：

  • Cloudflareキャッシュルールを設定する（つまり、リクエストのcfオブジェクトで操作する）。

• WorkersスクリプトからCache APIを使用して応答を保存する。これにより、オリジンから来ていない応答をキャッシュでき、さらに以下のように細かい制御が可能になります：

  • cache.put()に渡される応答にCache-Controlのようなヘッダーを設定することで、任意のアセットのキャッシュ動作をカスタマイズする。

  • cache.put()を通じてWorker自体によって生成された応答をキャッシュする。

階層キャッシュ

Cache APIは階層キャッシュと互換性がありません。階層キャッシュを利用するには、fetch APIを使用してください。

Workerによってキャッシュされたアセットの単一ファイルパージ

Workerによってキャッシュされたアセットを単一ファイルパージを使用してパージする場合、エンドユーザーのURLをパージしないようにしてください。代わりに、fetchリクエストに含まれるURLをパージします。たとえば、https://example.com/helloで実行されるWorkerがあり、このWorkerがhttps://notexample.com/helloにfetchリクエストを行います。

キャッシュに関しては、fetchリクエスト内のアセット（https://notexample.com/hello）がキャッシュされているアセットです（https://notexample.com/hello）。これをパージするには、https://notexample.com/helloをパージする必要があります。

エンドユーザーのURLであるhttps://example.com/helloをパージしても機能しません。なぜなら、それはキャッシュが見るURLではないからです。実際に取得しているURLをWorker内で確認し、正しいアセットをパージできるようにする必要があります。

前の例では、https://notexample.com/helloはCloudflareを通じてプロキシされていません。もしhttps://notexample.com/helloがCloudflareを通じてプロキシされていた場合（オレンジの雲）、notexample.comを所有している必要があり、notexample.comゾーンからhttps://notexample.com/helloをパージする必要があります。

例をよりよく理解するために、以下の図を確認してください：

flowchart TD
accTitle: Workerによってキャッシュされたアセットの単一ファイルパージ
accDescr: この図はファイルをパージする方法を選択するのに役立つことを目的としています。
A("あなたは<code>https://example.com/hello</code>で実行されるWorkerスクリプトを持っており、<br>このWorkerは<code>https://notexample.com/hello</code>に<code>fetch</code>リクエストを行います。") --> B(<code>notexample.com</code>は<br>Cloudflare上のアクティブゾーンですか？)
    B -- はい --> C(<code>https://notexample.com/</code>は<br>Cloudflareを通じてプロキシされていますか？)
    B -- いいえ  --> D(<code>https://notexample.com/hello</code>を<br>元の<code>example.com</code>ゾーンからパージします。)
    C -- はい --> E(<code>notexample.com</code>を所有していますか？)
    C -- いいえ --> F(<code>https://notexample.com/hello</code>を<br>元の<code>example.com</code>ゾーンからパージします。)
    E -- はい --> G(<code>https://notexample.com/hello</code>を<br><code>notexample.com</code>ゾーンからパージします。)
    E -- いいえ --> H(申し訳ありませんが、アセットをパージすることはできません。<br><code>notexample.com</code>の所有者のみがパージできます。)

Cache APIで保存されたアセットのパージ

Cache API操作を通じてキャッシュに保存されたアセットは、いくつかの方法でパージできます：

• Worker内でcache.deleteを呼び出して、リクエスト変数と一致するアセットのキャッシュを無効にします。

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

• アセットをグローバルにパージするには、標準のキャッシュパージオプションを使用する必要があります。Cache APIの実装に基づいて、すべてのキャッシュパージエンドポイントがCache APIによって保存されたアセットのパージに機能するわけではありません。

  • ゾーン内のすべてのアセットは、すべてをパージキャッシュ操作を使用してパージできます。このパージは、設定された方法に関係なく、すべてのデータセンターからCloudflareゾーンに関連付けられたすべてのアセットをキャッシュから削除します。

  • エンタープライズ顧客向けに、キャッシュタグをWorker内でresponse.headers.append()を呼び出して動的にリクエストに追加できます。設定後、これらのタグを使用して、ゾーン内のすべてのキャッシュされたアセットを無効にすることなく、キャッシュからアセットを選択的にパージできます。

• 現在、Workerによって設定されたカスタムキャッシュキーを使用してCache APIを通じて保存されたURLをパージすることはできません。代わりに、キャッシュルールを介して作成されたカスタムキーを使用してください。あるいは、すべてをパージ、タグによるパージ、ホストによるパージ、またはプレフィックスによるパージを使用してアセットをパージしてください。

エッジキャッシュとブラウザキャッシュ

ブラウザキャッシュは、クライアントへの応答に送信されるCache-Controlヘッダーを通じて制御されます（event.respondWith()に渡されたまたは約束された応答）。Workersは、このヘッダーを応答に設定することでブラウザキャッシュの動作をカスタマイズできます。

このドキュメントで言及されていないCloudflareのキャッシュを制御する他の手段には、ページルールやCloudflareキャッシュ設定が含まれます。JavaScriptを書くことなく、ある程度の制御を維持したい場合は、Cloudflareのキャッシュをカスタマイズする方法を参照してください。

キャッシュオブジェクトのキャッシュにCache APIまたはfetchを使用するべきか？

Workersがミドルウェアとして機能しているリクエスト（つまり、Workersがfetchを介してサブリクエストを送信している場合）では、fetchを使用することをお勧めします。これは、キャッシュを最適化し、意図しない動的キャッシュを防ぐための既存の設定があるためです。バックエンドがないプロジェクト（つまり、プロジェクト全体がWorkers SitesのようにWorkers上にある場合）では、Cache APIがキャッシュをカスタマイズする唯一のオプションです。

アセットは、Workerのサブリクエスト内で指定されたホスト名の下にキャッシュされます — Worker自身のホスト名ではありません。したがって、キャッシュされたアセットをパージするには、Workerサブリクエストに含まれるホスト名のためにパージを実行する必要があります。

fetch

Workersのコンテキストにおいて、ランタイムによって提供されるfetchはCloudflareキャッシュと通信します。最初に、fetchはURLが異なるゾーンと一致するかどうかを確認します。一致する場合、そのゾーンのキャッシュ（またはWorker）を読み取ります。そうでない場合、自身のゾーンのキャッシュを読み取ります。URLが非Cloudflareサイトであってもです。fetchのキャッシュ設定は、Cloudflareの設定に基づいて自動的にキャッシュルールを適用します。fetchは、キャッシュに到達する前にオブジェクトを変更または検査することを許可しませんが、キャッシュの方法を変更することは許可します。

応答がキャッシュを満たすと、応答ヘッダーにはCF-Cache-Status: HITが含まれます。CF-Cache-Statusが表示される場合、オブジェクトがキャッシュを試みていることがわかります。

このテンプレートは、fetchを使用して特定のリクエストに対してCloudflareキャッシュの動作をカスタマイズする方法を示しています。

Cache API

Cache APIは、一時的なキー-バリューストアと考えることができ、Requestオブジェクト（またはより具体的には、リクエストURL）がキーであり、Responseが値です。

Cloudflareキャッシュには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リクエストに依存せずにキャッシュから応答にプログラム的にアクセスしたい場合。たとえば、https://example.com/slow-responseエンドポイントのResponseをすでにキャッシュしているかどうかを確認できます。そうであれば、遅いリクエストを避けることができます。

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

階層キャッシュとCache API

Workers内のCache APIは階層キャッシュをサポートしていません。階層キャッシュは、オリジンサーバーへの接続を集中させ、フルセットのネットワークロケーションではなく、少数のデータセンターから接続を行います。Cache APIはデータセンターにローカルであるため、cache.matchはルックアップを行い、cache.putは応答を保存し、cache.deleteはリクエストを処理しているデータセンターのキャッシュ内でのみ保存された応答を削除します。これらのメソッドはローカルキャッシュのみに適用されるため、階層キャッシュでは機能しません。

関連リソース

• Cache API