Cloudflare Workers で WordPress を高速化する方法【HTMLキャッシュ＋エッジ実行で高速化】

Cloudflare Workersは、Cloudflareのネットワーク上でJavaScriptなどのコードを実行できるサーバーレス環境です。

WordPressと組み合わせることで、WordPressやPHPへリクエストが到達する前に処理を行えるため、リダイレクト、キャッシュ制御、API処理、レスポンスの加工などをエッジ側で実行できます。

ただし、

「Workersを入れればWordPressが必ず高速になる」

というものではありません。

特にHTMLキャッシュやBot対策は、実装方法を間違えると、ログイン中のページを他の利用者へ表示したり、Googlebotなど正規のクローラーを遮断したりする可能性があります。

この記事では、Cloudflare WorkersをWordPressで安全に利用する方法と、Workersを使わずCloudflare標準機能を使った方がよいケースを、2026年時点の仕様に合わせて解説します。

1 Cloudflare Workersとは？

Cloudflare Workersは、Webサイトへのリクエストに対してCloudflare側でプログラムを実行できるサービスです。

通常のWordPressでは、

訪問者
↓
Webサーバー
↓
PHP
↓
WordPress
↓
データベース
↓
HTMLを返す

という流れでページが生成されます。

Cloudflare Workersを利用すると、

訪問者
↓
Cloudflare
↓
Workers
↓
必要な場合だけWordPressへアクセス

という処理を組むことができます。

そのため、WordPressへ到達する前に処理できる内容については、オリジンサーバーへのアクセスを減らせる場合があります。

2 Workersでできる主なこと

• 条件に応じたリダイレクト
• リクエストやレスポンスヘッダーの変更
• APIの加工や中継
• 特定コンテンツのキャッシュ制御
• URLやCookieなどを使った条件分岐
• 外部APIとの連携
• WordPressへ到達する前の軽量な処理

ただし、CloudflareにはWorkers以外にも、

• Redirect Rules
• Cache Rules
• WAF Custom Rules
• Bot Fight ModeなどのBot対策
• WordPress向けAPO

などの機能があります。

専用機能で実現できる処理を、わざわざWorkersで自作する必要はありません。

3 WordPress高速化でWorkersが必須ではない理由

WordPress高速化の記事では、

「WorkersでHTMLを全部キャッシュすればPHPを使わず高速になる」

という方法が紹介されることがあります。

確かにキャッシュHIT時にはオリジンサーバーへのアクセスを避けられる場合があります。

しかしWordPressには、

• ログインユーザー
• 管理画面
• プレビュー
• 検索結果
• お問い合わせフォーム
• 会員ページ
• ECサイトのカート・決済
• Cookieによって内容が変化するページ
• nonceなど利用者ごとに異なる情報

があります。

これらを正しく除外せずHTMLをキャッシュすると、重大な不具合につながる可能性があります。

WordPress全体をエッジキャッシュしたい場合は、独自Workersをいきなり作るよりも、まずCloudflare APOやCache RulesなどWordPressの運用を考慮した仕組みを検討する方が安全です。

4 Cache APIとCloudflare CDNのキャッシュは同じではない

Workersでは、

const cache = caches.default;

というCache APIを利用できます。

ただし、このCache APIについては注意が必要です。

Cache APIで保存したキャッシュは、Cloudflareのすべてのデータセンターへ自動的に複製されるわけではありません。

そのWorkerを実行したデータセンターのキャッシュへ保存される仕組みです。

また、Cache APIの cache.put() はTiered Cacheには対応しません。

そのため、

「caches.defaultにHTMLを保存すれば、一度のアクセスですぐ世界中へキャッシュされる」

という理解は正しくありません。

5 新しくWorkersを作るならCache APIだけに頼らない

CloudflareにはWorkersのキャッシュ方法が複数あります。

低レベルな制御が必要な場合はCache APIが便利ですが、単純な高速化だけが目的であれば、Cloudflareの標準キャッシュやCache Rules、APOなどで対応できないかを先に確認しましょう。

Workersでオリジンへの fetch() を行う場合にも、Cloudflare側のキャッシュ設定を指定できます。

たとえば、

const response = await fetch(request, {
	cf: {
		cacheEverything: true,
		cacheTtl: 300
	}
});

のように、対象リクエストをCloudflare側でキャッシュする方法があります。

ただし、これをWordPressサイト全体へ無条件に適用してはいけません。

対象URLが公開コンテンツであり、ログイン状態やCookieなどで内容が変化しないことを確認して使用します。

6 安全な例：公開専用APIだけを短時間キャッシュする

たとえば独自プラグインで、

/wp-json/example/v1/public-data

という「誰がアクセスしても同じ内容を返す公開API」を作っているとします。

このような用途なら、対象URLを限定して短時間キャッシュする方法があります。

export default {
	async fetch(request) {
		const url = new URL(request.url);

		// 対象の公開API以外は通常処理
		if (
			request.method !== "GET" ||
			url.pathname !== "/wp-json/example/v1/public-data"
		) {
			return fetch(request);
		}

		// 公開APIだけ5分間キャッシュ
		return fetch(request, {
			cf: {
				cacheEverything: true,
				cacheTtl: 300
			}
		});
	}
};

この例ではWordPress全体ではなく、公開専用APIだけを対象にしています。

ログインユーザーごとに結果が異なるAPIや、個人情報を含むAPIには使用してはいけません。

7 WordPressのHTMLをWorkersでキャッシュするときの注意

WordPressのHTMLを独自Workersでエッジキャッシュする場合は、単純に、

if (response.ok) {
	// キャッシュ
}

だけでは不十分です。

少なくとも次のような項目を考慮する必要があります。

• GET・HEAD以外をキャッシュしない
• wp-adminを除外する
• wp-login.phpを除外する
• ログインCookieを除外する
• プレビューページを除外する
• 検索結果を除外する
• REST APIを必要に応じて除外する
• WooCommerceなどの動的ページを除外する
• Cookieによって内容が変化するページを除外する
• Set-Cookieを含むレスポンスを慎重に扱う
• エラーページを不用意に長時間キャッシュしない
• 更新時のキャッシュ削除方法を用意する

特にWordPressでは記事を更新したあとに古いHTMLを表示し続けない仕組みが必要です。

そのため、一般的なWordPressサイトでHTML全体をキャッシュする目的なら、独自WorkersよりもAPOを検討する価値があります。

8 APOと独自Workersの違い

CloudflareにはWordPress向けのAutomatic Platform Optimization（APO）があります。

APOはWordPressサイトをCloudflareのエッジから配信するための仕組みです。

CloudflareのWordPressプラグインと組み合わせることで、WordPressの更新に応じたキャッシュ更新や、ログイン中ユーザーのキャッシュ回避などが考慮されています。

そのため、

「WordPressのページ全体をCloudflare側から配信したい」

という目的だけなら、独自Workersを書く前にAPOを検討した方が管理しやすいケースがあります。

一方Workersは、

• 独自の条件分岐が必要
• 外部APIと連携する
• 特殊なURL変換を行う
• レスポンスを動的に加工する

といった、より自由な処理に向いています。

9 リダイレクトはまずRedirect Rulesを検討する

たとえば、

/old-page/
↓
/new-page/

という単純な301リダイレクトなら、Workersを作らなくてもCloudflareのRedirect Rulesで設定できます。

単純なリダイレクトは専用機能を利用する方が設定内容も確認しやすく、保守もしやすくなります。

10 複雑なリダイレクトならWorkersが便利

一方、

• 複数条件を組み合わせる
• URLパラメータを判定する
• 国やリクエスト情報によって分岐する
• 外部データを使って転送先を決める

など、Redirect Rulesだけでは管理しにくい処理ではWorkersが便利です。

単純なWorkersリダイレクトの例は次のとおりです。

export default {
	async fetch(request) {
		const url = new URL(request.url);

		if (url.pathname === "/old-page/") {
			return Response.redirect(
				"https://example.com/new-page/",
				301
			);
		}

		return fetch(request);
	}
};

この処理はWordPressやPHPを実行する前にCloudflare側でリダイレクトできます。

11 Bot対策をUser-Agentの文字だけで行わない

Workersの記事で特に注意したいのが、次のようなBot遮断コードです。

if (/bot/i.test(userAgent)) {
	return new Response("Access Denied", {
		status: 403
	});
}

このようなコードはおすすめできません。

User-Agentに bot が含まれているだけで遮断すると、検索エンジンの正規クローラーなど、必要なBotまで遮断する可能性があります。

また、悪質なBotはUser-Agentを簡単に偽装できます。

そのため、Bot対策では単純なUser-Agent文字列の判定だけに頼らない方が安全です。

12 Bot対策はCloudflareのセキュリティ機能を先に使う

CloudflareにはBot対策やWAF機能が用意されています。

まずは、

• CloudflareのBot関連設定
• WAF Custom Rules
• Managed Challenge
• Rate Limiting

などを検討します。

Cloudflareには、GooglebotやBingbotなどを含む正規Botを識別するためのVerified Botsという仕組みもあります。

Workersで独自Bot判定を書くのは、Cloudflareの標準セキュリティ機能では実現できない特殊な条件が必要な場合に限定した方がよいでしょう。

13 Rate LimitingもWorkersより専用機能を優先する

たとえば、

wp-login.phpへの大量アクセス
XML-RPCへの大量アクセス
特定APIへの短時間の大量アクセス

などを制限したい場合も、Workersで自作する前にCloudflareのRate LimitingやWAF機能を検討しましょう。

セキュリティ機能は、独自コードを増やすほど保守や誤判定への対応が必要になります。

14 Cache-Controlを全ファイルへ一律設定しない

次のようなコードをサイト全体に適用するのも注意が必要です。

response.headers.set(
	"Cache-Control",
	"public, max-age=31536000"
);

31536000秒は約1年間です。

ファイル名が変更される静的アセットなどでは長期キャッシュが有効な場合がありますが、HTMLまで1年間ブラウザキャッシュするような設定は通常適切ではありません。

HTML、CSS、JavaScript、画像では更新方法やキャッシュ戦略が異なるため、すべて同じTTLにする必要はありません。

15 Edge CacheとBrowser Cacheを混同しない

キャッシュを設定するときは、

• Cloudflare側に保存するEdge Cache
• 利用者のブラウザに保存するBrowser Cache

を区別する必要があります。

ブラウザ側のキャッシュ期間を長くすると、Cloudflare側のキャッシュを削除しても利用者のブラウザには古いファイルが残る可能性があります。

そのため、キャッシュ期間は「長ければ長いほど速い」と考えず、更新方法まで含めて決めましょう。

16 Workersを使えばLCPが必ず改善するわけではない

HTMLやAPIをエッジから返せるようになり、TTFBが短くなれば、結果としてLCP改善につながる場合があります。

しかしLCPは、

• 画像サイズ
• Webフォント
• CSS
• JavaScript
• サーバー応答
• ブラウザでのレンダリング

など多くの要素に影響されます。

Workersを導入しただけでLCPが必ず大幅改善するわけではありません。

17 INP改善をWorkersだけに期待しない

INPは、クリックやタップなどユーザー操作に対してページがどの程度素早く反応できるかを評価する指標です。

INPではブラウザ側のJavaScript処理や長時間タスクなどが大きく影響します。

WorkersによってAPI通信などが高速化されることで改善につながるケースはありますが、Workersを導入すればINPが改善するという単純な関係ではありません。

INPが悪い場合は、フロントエンド側のJavaScriptなども調べる必要があります。

18 「PHPの負荷ゼロ」とは限らない

キャッシュHITによってWordPressへのアクセスを回避できれば、PHPやデータベースの処理を減らすことができます。

しかし、

• キャッシュMISS
• ログインユーザー
• POSTリクエスト
• 動的ページ
• キャッシュ期限切れ

などではWordPressへアクセスします。

そのため、

「Workersを使えばPHPの負荷がゼロになる」

という説明は正しくありません。

正確には、キャッシュやエッジ処理が利用できるリクエストについて、オリジンサーバーへのアクセスを減らせるということです。

19 Cache APIでキャッシュ保存するときはctx.waitUntilを使う

WorkersのModule形式で、Cache APIへの書き込みをレスポンス返却後も継続させる場合は、ctx.waitUntil() を利用できます。

export default {
	async fetch(request, env, ctx) {

		const cache = caches.default;
		const cached = await cache.match(request);

		if (cached) {
			return cached;
		}

		const response = await fetch(request);

		// ここでは説明用の例
		// 実際にはキャッシュ対象を厳密に限定する
		const cacheResponse = new Response(
			response.body,
			response
		);

		ctx.waitUntil(
			cache.put(
				request,
				cacheResponse.clone()
			)
		);

		return cacheResponse;
	}
};

ただし、このコードもWordPressサイト全体へそのまま配置するためのコードではありません。

実際にはレスポンスの種類、Cookie、キャッシュ可否、対象URLなどを確認する必要があります。

20 Set-Cookieを含むレスポンスに注意

WordPressやプラグインによっては、レスポンスに Set-Cookie が含まれる場合があります。

Cookieは利用者固有の状態に関係する可能性があるため、キャッシュ処理では慎重に扱わなければなりません。

単純に、

response.ok

だけを見て「安全にキャッシュ可能」と判断することはできません。

21 Workersの料金

Cloudflare WorkersにはFreeプランとPaidプランがあります。

小規模サイトではFreeプランの範囲で試せる場合がありますが、サイト全体のアクセスをWorkerへ通す場合は、ページビューだけではなく画像やAPIなど、Workerを実行する対象範囲も確認してください。

料金や利用上限は変更される可能性があるため、実際に導入するときはCloudflare公式の最新料金表を確認しましょう。

22 Workersを使うと便利なWordPressサイト

• 複雑なリダイレクト処理が必要
• WordPressと外部APIを連携したい
• 公開APIのレスポンスをエッジでキャッシュしたい
• リクエストによってレスポンスを動的に変更したい
• Cloudflare標準ルールだけでは実現できない処理がある
• Workersの動作を理解した開発者が管理できる

23 Workersを無理に使わなくてもよいWordPressサイト

• 単純に画像やCSSをCDN配信したいだけ
• 単純な301・302リダイレクトだけ
• 一般的なBot対策だけ
• 通常のWordPressブログを高速化したいだけ
• キャッシュの仕組みをよく理解していない

このような場合は、Cloudflareの標準CDN、Cache Rules、Redirect Rules、WAF、APOなどから検討した方が安全です。

24 WordPressでWorkersを導入するときのおすすめ順序

1. まず通常のCloudflare設定でサイトを正常に動作させる
2. SSL/TLSやDNSに問題がないことを確認する
3. Cloudflareの標準キャッシュを利用する
4. 必要に応じてCache Rulesを設定する
5. 単純な転送はRedirect Rulesを利用する
6. Bot対策はWAF・Bot機能を確認する
7. WordPress全体のエッジ配信ならAPOも検討する
8. 標準機能では実現できない処理だけWorkersを使う

最初からWorkersで何もかも自作する必要はありません。

25 まとめ：Workersは「最強高速化ツール」ではなく自由度の高い開発ツール

Cloudflare Workersは非常に強力なサービスです。

しかし、WordPress高速化では、

「Workersを入れれば速くなる」

と考えるのではなく、

「Cloudflare標準機能ではできない処理をエッジで実行したいときにWorkersを使う」

と考える方が安全です。

• 単純なリダイレクト → Redirect Rules
• キャッシュ条件の調整 → Cache Rules
• WordPress全体のエッジキャッシュ → APOを検討
• Bot・不正アクセス対策 → WAFやBot機能
• 複雑な独自処理 → Workers

特にWordPressのHTMLキャッシュは、ログイン状態やCookie、フォーム、会員機能などを考慮せず実装すると危険です。

また、WorkersのCache APIは、保存したデータが一度にCloudflareの全拠点へ複製される仕組みではありません。

Workersは「WordPressを完全に置き換えるもの」ではなく、WordPressの手前で必要な処理だけを実行できる便利な開発環境として利用するのがおすすめです。

まずはCloudflareの標準機能を利用し、それでも実現できない処理が出てきたときにWorkersを追加する。
この順番で導入すれば、WordPressを壊すリスクを抑えながらCloudflareの機能を活用できます。