Workers を使うと、Cloudflare のネットワーク上でキャッシュの動作をカスタマイズできます。Workers はリクエストライフサイクルのミドルウェアとして動作します。1 つの Worker がリクエストフェーズとレスポンスフェーズの両方を処理します。リクエストが届くと、キャッシュの確認より先に Worker に到達します。Worker は受信リクエストを変更できます（例: URL の書き換えやヘッダーの追加）。そのあと fetch() を呼び出して、キャッシュ経由でリクエストを続行します。レスポンスが戻ってきたら（キャッシュからでもオリジンサーバーからでも）、訪問者に返す前に Worker でレスポンスを変更できます。
次の図は、Workers と Cache の一般的なやり取りの流れです。
- 訪問者 (a) が URL をリクエストし、そのリクエストは Worker に送られます。Worker はこのリクエストを処理できます。(b)
fetch()でオリジンサーバーからコンテンツを取得するか、(f) 訪問者にレスポンスを返すことができます。 - コンテンツがキャッシュされている場合、キャッシュは (e) Worker にレスポンスを返します。Worker はレスポンスを変更してから、(f) 訪問者にレスポンスを返せます。
- Workers と キャッシュルール を併用する場合、キャッシュルールは元の訪問者 URL / ホスト (a) ではなく、
fetch()(b) リクエストのプロパティ（ヘッダー、ホスト名、URL パスなど）に一致する必要があります。一致しないと、ルールは適用されません。
Workers でキャッシュの動作をカスタマイズする例をいくつか示します。
-
レスポンスの変更: キャッシュから取得したあとにコンテンツを調整または拡張し、最新の内容や特定の用途に合わせたレスポンスにします。
-
署名付き URL: 有効期限付きの署名付き URL を生成し、アクセスを制御してセキュリティを高めます。
-
パーソナライズされたレスポンス: ユーザーデータに基づく個別コンテンツを配信しつつ、キャッシュ済みリソースを使ってオリジンサーバーの負荷を下げます。
-
レイテンシの削減: 訪問者に近いデータセンターからコンテンツを配信し、読み込み時間を短くして体験を改善します。
ヘッダー変更、リダイレクト、JWT 検証などの軽い変更なら、Snippets も使えます。フルの Worker スクリプトをデプロイする必要はありません。Snippets は有料プランすべてに追加料金なしで含まれますが、リソース上限は厳しめです（実行時間 5 ms、パッケージサイズ 32 KB）。
Workers には、キャッシュとやり取りする方法が 2 つあります。Worker がオリジンへのサブリクエストを送るときは fetch() を使います。バックエンドオリジンなしでレスポンスを生成するときは Cache API を使います。
-
fetch(): Worker が
fetch()を呼び出すと、リクエストは Cloudflare のキャッシュと（有効な場合は）Tiered Cache を通ります。リクエストのcfオブジェクト にプロパティを設定すると、キャッシュの動作を制御できます。TTL、カスタムキャッシュキー、キャッシュヘッダーなどです。詳しくは Cache using fetch を参照してください。 -
Cache API:
caches.defaultまたはcaches.open()を使い、Cloudflare のキャッシュにレスポンスをプログラムで保存、取得、削除できます。fetch()と違い、Cache API は現在のリクエストを処理しているデータセンターのキャッシュだけを操作します。Tiered Cache とはやり取りしません。オリジンから来ていないレスポンスをキャッシュしたいときに使います。詳しくは Using the Cache API を参照してください。
Cache と Workers の関係について、詳しくは Cache in Workers を参照してください。