Cloudflareでサイトが遅くなる原因と対処まとめ

Cloudflareは、CDN・キャッシュ・DNS・セキュリティなどを提供するサービスです。
WordPressと組み合わせることで、画像やCSS、JavaScriptなどの配信を効率化し、オリジンサーバーへの負荷を減らせる場合があります。

ところが、Cloudflareを導入したあとに、

「以前より表示が遅くなった気がする」

ということもあります。

この場合、Cloudflareそのものが遅いとは限りません。
キャッシュが効いていない、WordPress側の処理が遅い、リダイレクトが増えている、JavaScript最適化との相性が悪いなど、さまざまな原因が考えられます。

この記事では、Cloudflare導入後にWordPressが遅くなったときに確認したいポイントを、2026年時点のCloudflareの仕様に合わせて解説します。

1 最初に確認：本当にCloudflareが原因なのか

Cloudflare導入後にサイトが遅く感じても、最初からCloudflareの設定を大量に変更するのはおすすめできません。

まず、

• Cloudflare導入前と導入後
• キャッシュHIT時とMISS時
• HTMLと画像などの静的ファイル
• PCとスマートフォン

を分けて確認しましょう。

PageSpeed Insightsの点数だけではなく、ブラウザの開発者ツールやレスポンスヘッダーも確認すると原因を見つけやすくなります。

2 原因① WebアクセスがCloudflareを経由していない

最初に確認したいのがDNSのProxy設定です。

Cloudflareでは、Webサイト用のA・AAAA・CNAMEレコードをProxiedにすると、HTTP/HTTPS通信がCloudflareを経由します。

Cloudflare管理画面では、Proxiedのレコードはオレンジ色の雲で表示されます。

一方、DNS only（グレー雲）の場合は、CloudflareはDNS応答を行うだけで、Webアクセス自体はCloudflareのCDNやWAF、キャッシュを経由しません。

2.1 確認ポイント

• Webサイト用のA・AAAA・CNAMEがProxiedになっているか
• wwwあり・なしの両方を使用している場合は両方確認する
• Webアクセスに使用しているホスト名が正しいか

2.2 メール用DNSは別に考える

MXレコードやTXTレコードはHTTPプロキシの対象ではありません。

また、

mail.example.com

などメールサーバー用のA・CNAMEについても、通常はDNS onlyで使用します。

Web用DNSとメール用DNSを混同しないようにしましょう。

3 原因② HTMLはCloudflareの標準設定ではキャッシュされない

Cloudflareでは、画像、CSS、JavaScriptなど多くの静的ファイルは標準でキャッシュ対象になります。

しかし、HTMLやJSONは標準ではキャッシュされません。

そのため、通常のWordPressページでは、

訪問者
↓
Cloudflare
↓
Webサーバー
↓
PHP
↓
WordPress
↓
データベース
↓
HTML生成

という処理が発生します。

Cloudflareを入れただけでWordPressのPHPやMySQL処理がなくなるわけではありません。

そのため、WordPress側のHTML生成が遅いサイトでは、静的ファイルが高速化されてもHTMLのTTFBが大きく改善しない場合があります。

4 HTMLまでキャッシュしたい場合はCache RulesまたはAPOを検討する

現在のCloudflareでは、HTMLなど標準ではキャッシュされないコンテンツをキャッシュ対象にしたい場合、Cache Rulesを利用できます。

ただし、WordPressのHTMLを無条件にすべてキャッシュするのは危険です。

WordPressには、

• wp-admin
• wp-login.php
• ログインユーザー向けページ
• お問い合わせフォーム
• 会員ページ
• 検索結果
• カート・決済ページ
• Cookieによって内容が変わるページ

などがあるためです。

4.1 WordPressならAPOも選択肢

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

APOはWordPressのHTMLもCloudflareのエッジから配信できる仕組みです。

Cloudflare公式WordPressプラグインと組み合わせることで、WordPressの記事を更新したときのキャッシュ更新や、ログイン中ユーザーのキャッシュ回避なども考慮されます。

ただし、すべてのWordPressサイトでAPOが必須というわけではありません。

まず通常のCloudflare設定で速度を測定し、HTMLのTTFBがボトルネックになっている場合に検討するとよいでしょう。

5 原因③ キャッシュがHITしていない

Cloudflareを導入している場合、レスポンスヘッダーの
CF-Cache-Status
を確認するとキャッシュ状態を判断できます。

たとえば画像に対して、

curl -I https://example.com/wp-content/uploads/photo.jpg

を実行します。

レスポンスに、

CF-Cache-Status: HIT

と表示されれば、Cloudflareのキャッシュから返されたことを示します。

5.1 HIT・MISS・BYPASSの違い

• HIT：Cloudflareのキャッシュから配信された
• MISS：キャッシュ可能だが、その時点のCloudflareキャッシュにはなかった
• BYPASS：そのレスポンスをCloudflareがキャッシュ対象外と判断した

2026年現在、Cloudflareではキャッシュ不可能なレスポンスについては基本的にBYPASSが返され、MISSは「キャッシュ可能だがまだ存在しない」場合に使われます。

そのため、

MISSが出た
＝
設定が壊れている

という意味ではありません。

6 キャッシュされない代表的な原因

Cloudflareがキャッシュしない原因には、たとえば次のようなものがあります。

• 標準ではキャッシュ対象外のHTML
• Cache-Controlでprivateやno-cacheなどが指定されている
• レスポンスにSet-Cookieが含まれている
• Authorizationヘッダーを使用している
• Cache Rulesでキャッシュ対象外になっている

Cookieが存在するだけで、すべてのリクエストが必ずキャッシュ不可になるわけではありません。

重要なのは、Cloudflareやオリジンサーバーがそのリクエスト・レスポンスをどのように扱っているかです。

7 原因④ WordPressのオリジンサーバー自体が遅い

キャッシュMISSやキャッシュ対象外のページでは、Cloudflareはオリジンサーバーへアクセスします。

そのためWordPress側が遅ければ、Cloudflareを通してもその遅延は残ります。

7.1 WordPress側で確認したいポイント

• 重いプラグインがないか
• PHP処理が遅くないか
• データベースクエリが遅くないか
• wp_optionsのautoloadデータが肥大化していないか
• 外部APIへの通信待ちがないか
• レンタルサーバーが高負荷になっていないか
• WordPress側のページキャッシュが機能しているか

CloudflareはWordPressそのものを高速化するPHPアクセラレーターではありません。

キャッシュMISS時にWordPressが遅い場合は、オリジンサーバー側の改善も必要です。

8 原因⑤ SSL/TLSやリダイレクト設定が重複している

Cloudflare導入後に確認したいのがリダイレクトです。

たとえば、

http
↓
https
↓
wwwあり
↓
wwwなし

のように複数回リダイレクトしていると、そのたびに通信が発生します。

さらにCloudflare側とWordPress側、レンタルサーバー側のすべてで同じリダイレクトを設定すると、設定によってはループすることもあります。

8.1 Flexible SSLには特に注意

CloudflareのSSL/TLSモードがFlexibleの場合、

訪問者 → Cloudflare：HTTPS
Cloudflare → オリジン：HTTP

となります。

オリジンサーバー側でHTTPをすべてHTTPSへリダイレクトしている場合、設定の組み合わせによってはリダイレクトループになることがあります。

オリジンサーバーに正常なSSL証明書が設定されている場合は、通常はFullまたはFull (strict)を検討します。

8.2 確認したいもの

• CloudflareのSSL/TLSモード
• CloudflareのRedirect Rules
• Always Use HTTPS
• .htaccessのリダイレクト
• WordPressプラグインによるHTTPS転送
• レンタルサーバー側のHTTPS転送

同じ目的のリダイレクトを何重にも設定しないことが重要です。

9 原因⑥ Rocket LoaderとJavaScriptの相性

CloudflareにはRocket LoaderというJavaScript読み込み最適化機能があります。

Rocket LoaderはJavaScriptの読み込みを遅延させ、ページ内容を先に描画できるようにする機能です。

サイトによっては表示開始を改善できます。

一方で、WordPressテーマやプラグインのJavaScriptとの組み合わせによって、

• スライダーが動かない
• メニューが動かない
• フォームのJavaScriptが動かない
• JavaScriptエラーが発生する

といった問題が起きることがあります。

Cloudflare公式も、JavaScriptやjQueryに問題が発生した場合はRocket Loaderを無効化して再確認するよう案内しています。

9.1 WordPressだから最初からOFFとは限らない

Rocket Loaderを、

WordPressでは必ずOFF

とする必要はありません。

ONにして問題がなければ利用できます。

不具合や速度低下が発生した場合に、一度OFFにして比較するのが適切です。

特定のJavaScriptだけRocket Loaderの対象外にする方法もあります。

10 原因⑦ 画像最適化を何重にも行っている

WordPressでは、

• WordPress画像最適化プラグイン
• レンタルサーバーの画像最適化
• Cloudflare Polish
• Cloudflare Image Transformations

など複数の画像最適化機能を利用できる場合があります。

複数使っているから必ず遅くなるわけではありませんが、同じ画像を何度もLossy圧縮すると、画質低下の割にファイルサイズがあまり減らない場合があります。

10.1 Polishとは？

Cloudflare Polishは、画像からメタデータを削除し、LosslessまたはLossy圧縮などを行う画像最適化機能です。

すでに十分最適化されている画像では、再圧縮によるメリットが小さい場合があります。

Cloudflare自身も、すでに最適化された画像の再エンコードでは、ファイルサイズ削減より画質低下の方が大きくなる場合があると説明しています。

10.2 「必ず片方をOFF」にする必要はない

重要なのは、

• どのサービスで画像圧縮しているか
• WebP変換をどこで行っているか
• リサイズをどこで行っているか

を把握することです。

同じ処理を複数箇所で重複させる必要がなければ、構成をシンプルにした方が管理しやすくなります。

11 原因⑧ キャッシュが複数あることではなく、キャッシュ削除が連携していない

WordPressでは、

ブラウザキャッシュ
↓
Cloudflare
↓
レンタルサーバーキャッシュ
↓
WordPressキャッシュプラグイン
↓
WordPress

のように複数のキャッシュ層が存在することがあります。

これは必ずしも間違いではありません。

問題になるのは、

WordPressを更新
↓
WordPress側キャッシュは削除
↓
Cloudflareに古いページが残る

といった状態です。

「キャッシュは1ヶ所だけ」と考えるのではなく、どの層に何が保存され、更新時にどのキャッシュが削除されるのかを把握しましょう。

11.1 APO導入時は最初に構成をシンプルにする

CloudflareはAPOの初期設定時、WP RocketやW3 Total Cacheなどのキャッシュプラグインを一旦停止して動作確認する方法を案内しています。

これは、

「APOとキャッシュプラグインは絶対に併用できない」

という意味ではありません。

まずAPO単体で正常動作を確認し、そのあと必要なプラグインを再度有効化して、速度と動作をテストする方が原因を切り分けやすくなります。

12 原因⑨ WAF・Bot対策・Challengeによって待ち時間が発生している

CloudflareにはWAFやBot Fight Modeなどのセキュリティ機能があります。

これらは不正アクセス対策に役立ちますが、設定によっては正規の通信にもChallengeが発生する場合があります。

特に、

• API
• 監視サービス
• モバイルアプリ
• 自動処理

などはBot対策の影響を受ける場合があります。

Bot Fight Modeは、Botと判断した通信に計算コストの高いChallengeを行う機能です。

そのため、

Bot Fight Modeは必ずOFF

とするのではなく、問題が起きている場合はCloudflareのSecurity Analyticsやイベント履歴を確認しましょう。

12.1 セキュリティを速度のために全部OFFにしない

サイトが遅いからといって、

• WAFを全部OFF
• Bot対策を全部OFF
• セキュリティルールを全部削除

とするのはおすすめできません。

どのルールやChallengeが実際に影響しているのか確認してから調整します。

13 原因⑩ Cloudflareからオリジンサーバーまでの経路に時間がかかっている

Cloudflareを利用すると、

利用者
↓
Cloudflare
↓
オリジンサーバー

という通信になります。

キャッシュHITならCloudflare側からコンテンツを返せますが、MISSや動的ページではCloudflareからオリジンサーバーへの通信が必要です。

そのため、ネットワーク経路によってはオリジンへの接続時間が影響する場合があります。

13.1 「日本サーバーならCloudflareは遅い」とは限らない

日本国内のレンタルサーバーを利用しているからCloudflareを使うと必ず遅くなる、ということではありません。

逆にCloudflareを通せば必ず速くなるとも限りません。

サイト利用者の地域、キャッシュ状況、オリジンサーバーの位置、ネットワーク状況などによって変わります。

導入前後を同じ条件で測定して判断しましょう。

14 Argo Smart Routingとは？

CloudflareにはArgo Smart Routingというネットワーク最適化機能があります。

Argoはリアルタイムのネットワーク情報などを利用して、Cloudflareから接続先までの効率的な経路を選択する仕組みです。

ただし、

東京POPにつながらない
↓
ArgoをONにすれば東京POPになる

という機能ではありません。

WordPressのPHP処理が遅い場合や、巨大な画像・JavaScriptが原因の場合もArgoだけでは解決できません。

ネットワーク経路が実際のボトルネックになっていると判断できた場合に検討します。

15 .htaccessそのものがCloudflareと競合するとは限らない

Cloudflare導入後の問題として、

.htaccessとCloudflareが競合している

と説明されることがあります。

しかし、より重要なのは.htaccessに設定されたリダイレクトやアクセス制限の内容です。

特に確認したいのは、

• http → https
• wwwあり → wwwなし
• wwwなし → wwwあり
• URL正規化
• アクセス制限

です。

Cloudflare側でも同じ転送を設定している場合は、不要なリダイレクトやループが発生していないか確認しましょう。

16 古い記事の「Cloudflare Auto Minify」は現在使わない

以前のCloudflare高速化記事では、

HTML Minify
CSS Minify
JavaScript Minify

をONにする方法がよく紹介されていました。

しかし、CloudflareのAuto Minifyは2024年に非推奨となっています。

そのため、2026年現在、

CloudflareのMinifyをONにする
CloudflareのMinifyをOFFにしてAutoptimizeへ統一する

という設定をCloudflare高速化の中心として説明するのは古い情報です。

CSSやJavaScriptの最小化が必要な場合は、現在利用しているテーマ、プラグイン、ビルド環境などに合った方法を選びましょう。

17 Page RulesではなくCache Rulesを中心に考える

古いCloudflare記事では、

Page Rules
Cache Everything

を使ったWordPress高速化方法が多く紹介されています。

現在、新しくCloudflareのキャッシュ条件を設定する場合は、
Cache Rules
を中心に検討します。

Cache Rulesでは、

• 何をキャッシュ対象にするか
• どのくらいキャッシュするか
• どの条件でキャッシュしないか

などを設定できます。

WordPressのHTMLをキャッシュする場合は、管理画面やログインユーザーなどの除外条件を慎重に設定してください。

18 APOが本当に動いているか確認する

APOを有効にしている場合は、

APOをONにしたから高速化されているはず

と判断せず、実際のレスポンスヘッダーを確認します。

APOが正常に動作している場合は、Cloudflare公式では次のようなヘッダーを確認できます。

CF-Cache-Status: HIT
cf-apo-via: tcache
cf-edge-cache: cache,platform=wordpress

WordPressの記事を更新したあとに再度確認し、キャッシュ更新も正常に機能しているか確認しましょう。

19 Cloudflare導入後に遅くなったときの確認順序

原因が分からない場合は、次の順番で確認すると切り分けやすくなります。

1. Web用DNSがProxiedになっているか確認する
2. Cloudflare導入前後の速度を比較する
3. 画像など静的ファイルのCF-Cache-Statusを確認する
4. HIT・MISS・BYPASSを確認する
5. HTMLのTTFBを確認する
6. オリジンサーバーのWordPress処理速度を確認する
7. リダイレクトが何重にもなっていないか確認する
8. SSL/TLSモードを確認する
9. Rocket Loaderを一時的にOFFにして比較する
10. キャッシュプラグインやサーバーキャッシュを確認する
11. 画像最適化が重複していないか確認する
12. WAFやBot対策でChallengeが発生していないか確認する
13. APOを使用している場合はAPOヘッダーを確認する

一度にすべての設定を変更すると、何が原因だったのか分からなくなります。

1項目ずつ変更して、そのたびに速度と動作を確認することが重要です。

20 2026年版：WordPressでCloudflareを使う基本的な考え方

すべてのWordPressに共通する「最強設定」はありません。

まずは次のようなシンプルな構成から始めるのがおすすめです。

• Webサイト用DNSをProxiedにする
• SSL/TLSをオリジンサーバーの状態に合わせて正しく設定する
• まずCloudflare標準キャッシュで動作確認する
• HTMLキャッシュが必要ならAPOまたはCache Rulesを検討する
• Rocket Loaderは有効化後に実際の動作を確認する
• 画像最適化機能の重複を確認する
• WAFやBot対策は必要性に応じて利用する
• 複数キャッシュを使う場合はpurgeの連携を確認する
• 高速化機能を一度に全部ONにしない

21 Cloudflareを使わない方がよい場合もある

Cloudflareは便利なサービスですが、すべてのWordPressサイトに必須ではありません。

たとえば、

• 利用者がほぼ日本国内だけ
• 高速な国内サーバーを利用している
• 小規模サイト
• アクセス数が少ない
• 現在すでに十分高速

という場合は、Cloudflareを追加しても体感できるほど速度が変わらないことがあります。

CDNを導入するとDNS、SSL/TLS、キャッシュ、セキュリティなど管理する場所も増えます。

導入前後でメリットがほとんどないのであれば、無理に使う必要はありません。

22 まとめ：Cloudflareが遅いと決めつけず、HIT・TTFB・WordPressを分けて調べる

Cloudflare導入後にWordPressが遅くなった場合、最初から、

Cloudflareが遅い
Cloudflareを外せばいい

と判断するのではなく、どこで時間がかかっているのか確認しましょう。

特に重要なのは、

• Cloudflareを本当に経由しているか
• 静的ファイルがHITしているか
• HTMLがキャッシュされているか
• WordPressのオリジンTTFBが遅くないか
• 不要なリダイレクトがないか
• Rocket Loaderなどの最適化機能が影響していないか
• キャッシュ削除が正しく連携しているか
• セキュリティ機能によるChallengeが発生していないか

です。

Cloudflareは、設定を大量にONにするほど速くなるサービスではありません。

標準設定から始め、実際のレスポンスヘッダーと速度を測定しながら、必要な機能だけ追加することが安定したWordPress運用につながります。

Cloudflare導入後に遅くなったと感じた場合は、一度に設定を変更せず、
DNS → キャッシュ → TTFB → リダイレクト → JavaScript → セキュリティ
の順番で原因を切り分けてみましょう。