Cloudflare on plzhans blog

Cloudflare Workers キャッシュ設定方法 - エッジキャッシュとTiered Cache

Fri, 11 Sep 2026 13:01:00 +0000

概要

この記事は Cloudflare Workers 静的サイトガイド - デプロイからSEOまでシリーズの一部です。

Workerが外部APIを呼び始めると、すぐにキャッシュが必要になります。かけなければオリジンの負荷がページビューの分だけ増えます。

かけること自体は1行で済みますが、その後に知らなければ必ず踏む罠がいくつかあります。特にエッジキャッシュが全世界で共有されないという点は、知ってしまえば当然ですが、知らなければ「なぜキャッシュが当たらないのか」としばらく悩むことになります。

この記事で扱うこと

キャッシュをかける2つの方法 — fetch() の cf オプションとCache API
エッジキャッシュがデータセンターごとに別であることと、その対応
Tiered Cacheでオリジンへのリクエストを減らす方法・そのとき cache.put() が使えない理由
同じURLがヘッダーによって異なるレスポンスを返す場合のキャッシュキーの問題

扱わないこと

Workers Static Assetsの構造とデプロイは Cloudflare Workers 静的サイトホスティング - リクエストの流れと課金基準、ローカル開発は wrangler 使い方 - Cloudflare Workers のローカル開発とデプロイにあります。

KV・R2・D1のようなストレージは範囲外です。この記事はHTTPレスポンスキャッシュのみを扱います。

キャッシュをかける2つの方法

① fetch() の cf オプション — レスポンスをCloudflareのエッジキャッシュに任せます（Request ドキュメント）。

1await fetch(url, {
2 cf: { cacheTtl: 3600, cacheEverything: true },
3});

② Cache API — 自分で入れて取り出します。

1const cache = caches.default;
2const hit = await cache.match(key);
3if (hit) return hit;
4// ...
5ctx.waitUntil(cache.put(key, response.clone()));

知っておくべきこと3つ

エッジキャッシュはデータセンターごとに別です。 ドキュメントの表現そのままです。

The contents of the cache do not replicate outside of the originating data center.

Cloudflare Workers 静的サイトガイド - デプロイからSEOまで

Fri, 11 Sep 2026 13:01:00 +0000

概要

ReactやVueで作ったSPA、Hugoで生成した静的サイトを、そのままCDNに載せて使うケースが多いです。デプロイが単純で、サーバーがないので運用するものもありません。

ところが少し経つと、**「レスポンスに手を入れたいのにサーバーがない」**という瞬間が来ます。ページごとに異なるメタタグを入れたいときや、クローラーに本文を見せたいとき、レスポンスヘッダーを一つ付けたいときです。

Cloudflareを使っているなら、サーバーを新しく立てずにそれができます。静的アセットの前にコードを一枚重ねるのです。このシリーズは、その過程を4編に分けて整理したものです。

読む順序

Cloudflare Workers 静的サイトホスティング - リクエストの流れと課金基準 — 構造とリクエストの流れ。いつWorkerが動き、いつ課金されるのか
wrangler 使い方 - Cloudflare Workers のローカル開発とデプロイ — ローカルで立ち上げてデプロイする方法
Cloudflare Workers キャッシュ設定方法 - エッジキャッシュとTiered Cache — 外部APIを呼び始めたなら
React SPA SEO 改善方法 - Cloudflare WorkersでメタタグからSSRまで — メタタグの注入からサーバーレンダリングまで

1番は概念、2番はツールです。この2つは順番に読む方がよいです。3・4番は必要なときに選んで読めば大丈夫です。

なぜWorkersなのか

追加インフラが0です。 すでにCloudflareがアセットをサービングしているなら、そこにコードを重ねるだけです。デプロイ対象が増えることもなく、落ちたらサイトが落ちるサーバーがもう一つ増えることもありません。

無料プランで始められます。 1日10万リクエストまで無料で、静的アセットのリクエストはそもそも課金対象ではありません。

エッジで動きます。 ユーザーに近いデータセンターで実行されるため、オリジンへの往復がありません。

もちろん万能ではありません。リクエストあたりCPU 10ms（無料プラン）といった制約があるので、重い計算には向きません。その境界がどこにあるのかもシリーズで扱います。

各編で扱うこと

1編 - 静的サイトホスティング

Workers Static Assetsとは何か、そしてリクエストがどの順序で流れるのかをシーケンス図で整理しました。

核心は**「アセットがあればWorkerは動かない」**という基本ルールと、それを覆す run_worker_first です。課金がどこで発生するのかもここで扱います — 静的アセットは無料で、Workerが実行されたリクエストだけがカウントされるので、Workerを通す経路を狭く取ることがそのままコストになります。

→ Cloudflare Workers 静的サイトホスティング - リクエストの流れと課金基準

2編 - wrangler 使い方

wrangler のインストールからデプロイまで。ランタイム依存は増えないということ、Workerコードの型設定を分離すべき理由、そして最も紛らわしいもの一つ。

Cloudflare Workers 静的サイトホスティング - リクエストの流れと課金基準

Fri, 11 Sep 2026 13:01:00 +0000

概要

この記事は Cloudflare Workers 静的サイトガイド - デプロイからSEOまでシリーズの一部です。

静的サイトをCloudflareに載せる方法として Workers Static Assets があります。ビルド成果物（dist/）をアップロードすると全世界のエッジでサービングされ、必要ならその前にコードを一枚重ねることができます。

静的ホスティングとして使っているうちに「レスポンスを少し直したい」という要求が生まれたとき、サーバーを新しく立てずに解決できる道です。

この記事で扱うこと

Workers Static Assetsの構造 — アセットとWorkerコードが一単位でデプロイされる
リクエストがどの順序で流れるのか — いつWorkerが動き、いつ動かないのか（シーケンス図）
課金がどこで発生するのかと無料プランの制限

続きの記事

この記事は構造とデプロイを扱います。残りは別にあります。

wrangler 使い方 - Cloudflare Workers のローカル開発とデプロイ — インストール · 型設定 · wrangler dev · デプロイ
Cloudflare Workers キャッシュ設定方法 - エッジキャッシュとTiered Cache — エッジキャッシュ · Tiered Cache
React SPA SEO 改善方法 - Cloudflare WorkersでメタタグからSSRまで — メタタグの注入 · サーバーレンダリング

KV・R2・D1のような他のバインディング、Durable Objects、Cron Triggersは範囲外です。

前提

Cloudflareのアカウントがあり、静的サイトをビルドできること（npm run build → dist/）以外に必要な事前知識はありません。

React SPA SEO 改善方法 - Cloudflare WorkersでメタタグからSSRまで

Fri, 11 Sep 2026 13:01:00 +0000

概要

この記事は Cloudflare Workers 静的サイトガイド - デプロイからSEOまでシリーズの一部です。

Reactで作ったSPAを静的ホスティングに載せて使うケースが多いです。デプロイが単純で、サーバーがないので運用するものもありません。コストもほとんどかかりません。

ところが検索を気にし始めると、すぐに壁にぶつかります。サーバーが返す生のHTMLに、検索エンジンが読むものが一つもないからです。

この記事は、その問題をバックエンドサーバーを新しく立てずにCloudflare Workersだけで解いていった記録です。3つの段階に分けて扱います。後ろに行くほど得られるものが大きく、手間もかかります。

0段階 — 何もしない。 生のHTMLが空の殻です。ほとんどのSPAがここにいます。

1段階 — Workersでメタを埋める。 タイトル・説明・OG・構造化データがレスポンスのHTMLに入ります。作業量が少なく効果が明確です。

2段階 — Workersで本文まで描く。 実際の画面をサーバーでレンダリングして入れます。最も手間がかかりますが、クローラーが読む内容ができます。

この記事で扱うこと

GoogleがJSをレンダリングするのに、なぜ自分で入れる方がよいのか
Workersで <head> を埋める方法と、そのときの罠
entry-client / entry-server の分離と vite build --ssr
サーバーが受け取ったデータをブラウザに渡し、APIの往復を増やさない方法
実際に変わった数値と、踏んだ罠

扱わないこと

各メタ項目を何で埋めるか — SEO側のテーマです。SEO最適化の記事を参照
wranglerの使い方・リクエストの流れ・デプロイ — Cloudflare Workers 静的サイトホスティング - リクエストの流れと課金基準 · wrangler 使い方 - Cloudflare Workers のローカル開発とデプロイ
エッジキャッシュ・Tiered Cache — Cloudflare Workers キャッシュ設定方法 - エッジキャッシュとTiered Cache

前提

Cloudflareに静的サイトを載せたことがあり、wrangler でローカルにWorkerを立ち上げたことがあると仮定します。初めてなら、上のデプロイの記事を先に読む方がよいです。

問題 — 生のHTMLに検索エンジンが読む内容がない

ビルドされたSPAのHTMLをそのまま受け取ってみましょう。

1curl -s https://example.com/products/1234

 1<!doctype html>
 2<html lang="ko">
 3 <head>
 4 <title>My Service</title>
 5 <meta name="description" content="A generic site description" />
 6 </head>
 7 <body>
 8 <div id="root"></div>
 9 <script type="module" src="/assets/index-a1b2c3.js"></script>
10 </body>
11</html>

1.6KBほどの殻です。商品名も価格も説明もありません。すべてJSが実行され、APIのレスポンスが届いた後にはじめて作られます。

wrangler 使い方 - Cloudflare Workers のローカル開発とデプロイ

Fri, 11 Sep 2026 13:01:00 +0000

概要

この記事は Cloudflare Workers 静的サイトガイド - デプロイからSEOまでシリーズの一部です。

Cloudflare Workersを扱う仕事は、実質的にwrangler を扱う仕事です。ローカルで立ち上げるのも、デプロイするのも同じCLIです。

ところが名前のせいで誤解が一つ生まれます。wrangler dev はフロントエンドの開発サーバーではありません。 筆者も最初はここでしばらく悩みました。

この記事で扱うこと

何をインストールすべきか — そしてランタイム依存は増えないということ
Workerコードの型設定を分離すべき理由
wrangler dev が実際に何をするのか · vite dev との違い
なぜ静的サイトのビルドが先でなければならないのか
Workerがレスポンスを直したか確認する方法
デプロイ — 環境ごとの値の注入 · CIで動かすときの注意点

扱わないこと

Workers Static Assetsの構造とリクエストの流れは Cloudflare Workers 静的サイトホスティング - リクエストの流れと課金基準にあります。

前提

Cloudflareのアカウントがあり、静的サイトをビルドできること（npm run build → dist/）以外に必要な事前知識はありません。

wrangler のインストール

CloudflareのCLIです。ローカル実行とデプロイの両方を担当します。コマンド一覧は Commands ドキュメントにあります。

インストールしないという選択肢

wrangler はデプロイツールであってアプリケーションコードではありません。 そのため依存に入れず、必要なときだけダウンロードして使うこともできます。

1# As a devDependency
2npm i -D wrangler
3npx wrangler dev
4
5# Or without installing - pin the major version
6npx wrangler@4 dev
7pnpm dlx wrangler@4 dev

後者の利点は、ローカルとCIが同じバージョンを使い、アプリの package.json にデプロイツールが入らないことです。欠点は毎回ダウンロードの時間が少しかかることです。