WordPressをCloudflareで高速化【2026】キャッシュ設定の勘所

Cloudflare・CDN活用中級
CloudflareWordPressCacheCDNPerformance

本記事はアフィリエイト広告（A8.net）を含みます。価格・仕様は2026年6月時点の目安です。最新は各公式サイトでご確認ください。

TL;DR

WordPressがCloudflareで遅く感じるのは、設定不足というより「何をキャッシュし、何をキャッシュしないか」の線引きができていないからです。

押さえる順番はこの3つ。

  • まず無料プランの基本：CDN・Brotli・自動キャッシュ（CSS/JS/画像など静的ファイル）を有効化する
  • 次にHTMLキャッシュ：Cache Everything でページHTMLまでエッジに載せる。ただしログイン・カート・プレビューは必ず除外する
  • 最後に土台：表示速度はホスティングとテーマの素の速さでも大きく変わる。Cloudflareは増幅装置であって、遅い土台を魔法では直さない

除外ルールを先に設計すれば、Cache Everything は怖くありません。除外を後回しにすると、他人のカートが見える・管理画面でログアウトされるといった事故が起きます。

なぜWordPressは重いのか

WordPressは、アクセスのたびにPHPが動いてDBに問い合わせ、HTMLをその場で組み立てる動的生成が基本です。素のままだと、1リクエストごとに次が走ります。

  1. PHP実行（テーマ・プラグインの処理）
  2. MySQL/MariaDBへの複数クエリ
  3. HTMLの組み立て・返却

ここにプラグインが10も20も乗ると、1ページの生成に数百ミリ秒〜数秒かかることもあります。さらにアクセスが集中すると、PHPワーカーとDB接続が枯渇して全体が詰まります。

つまりWordPressの遅さは大きく2種類です。

遅さの種類原因効く対策
生成が遅いPHP/DBの動的処理・重いプラグインサーバーキャッシュ・HTMLキャッシュ・軽いテーマ
配信が遅い画像が重い・遠いサーバー・1接続あたりの転送CDN・画像最適化・Brotli圧縮

Cloudflareは主に「配信が遅い」を解消し、HTMLキャッシュで「生成が遅い」も肩代わりします。逆に言うと、土台（ホスティング・テーマ）が重いと、キャッシュが切れた瞬間（キャッシュミス時）に素の遅さが顔を出します。

Cloudflareでできる高速化

無料プランでも効果の大きい部分は十分カバーできます。

1. CDN（エッジ配信）

世界中のエッジに静的ファイルを置き、訪問者に近い拠点から配信します。国内向けでも、画像・CSS・JSの初回以降の配信が速く・サーバー負荷も下がるのが利点です。これはネームサーバーをCloudflareに向けるだけで自動的に効きます。

2. 静的ファイルのキャッシュ

CSS・JS・画像・フォントなどは、Cloudflareがデフォルトでキャッシュ対象にします。Caching → Configuration でBrowser Cache TTLを適切（例：数時間〜1か月の目安）に設定すると、再訪問が速くなります。

3. 画像最適化

画像はページ容量の大半を占めがちです。Cloudflareでは次のような選択肢があります。

  • Polish（有料・Pro以上）：自動圧縮とWebP/AVIF変換
  • 無料プランの場合：WordPress側の画像最適化プラグイン（EWWW・ShortPixel等）やWebP配信で代替

「まず無料で画像を軽くしたい」なら、プラグイン側で生成時にWebP化＋圧縮しておくのが現実的です。

4. Brotli圧縮

テキスト系（HTML/CSS/JS）をgzipより高効率に圧縮します。Speed（または Caching）の設定でBrotliをオンにするだけで転送量が減ります。無料プランで有効化できます。

5. HTTP/2・HTTP/3・TLS

CloudflareをかませるとHTTP/2・HTTP/3が自動で有効になり、複数ファイルの並行取得とハンドシェイク短縮が効きます。常時HTTPS化も合わせて整います。

無料 / Pro でできることの目安

項目無料Pro
CDN・Brotli・HTTP/3◯◯
静的ファイルキャッシュ◯◯
Cache Everything（Cache Rules）◯◯
Polish（画像自動圧縮・WebP/AVIF）✗◯
Mirage / 画像遅延最適化✗◯
WAF（マネージドルール強化）基本のみ◯

画像の自動最適化を「Cloudflare側で完結させたい」かどうかが、無料とProの主な分岐点です。多くの小規模サイトは無料＋WordPress側プラグインで足ります。

WordPress固有の注意：キャッシュしてはいけない領域

ここが本記事の核心です。WordPressにはユーザーごとに中身が変わるページがあり、これをエッジにキャッシュすると事故になります。

キャッシュ除外が必須の代表例です。

  • wp-admin / wp-login（管理画面・ログイン）
  • ログイン中ユーザー向けの表示（wordpress_logged_in などのCookieが付く状態）
  • カート・購入・マイページ（WooCommerce の cart / checkout / my-account）
  • プレビュー（?preview=true などの下書き確認）
  • プラグインのAjax（wp-admin/admin-ajax.php）
  • フォーム送信・問い合わせの動的応答

これらをキャッシュすると、他人のカートが見える・ログイン状態が混ざる・編集中の下書きが公開されるといった深刻な不具合につながります。HTMLキャッシュを入れるなら、除外設計を先に固めるのが鉄則です。

なお、キャッシュが「効きすぎて更新が反映されない」逆の悩みは、別記事で扱っています。あわせて読むと、効かせる側と止める側の両方が見えます。

→ Cloudflareでキャッシュを意図的にバイパスする実務

Cache Everything ＋ 除外ルールの組み方

WordPressのHTMLまでエッジに載せるには、Cloudflareの Cache Rules（旧Page Rules相当）で Cache Everything を使います。順番が重要です。

手順（決定木）

  1. 除外ルールを先に作る — 以下に当てはまるリクエストは「Bypass cache（キャッシュしない）」にする
    • URLパスが /wp-admin/・/wp-login.php・/cart・/checkout・/my-account を含む
    • クエリに preview・s=（検索）など動的パラメータを含む
    • Cookieに wordpress_logged_in / woocommerce_ などが付いている（ログイン・カート保持中）
  2. 次にキャッシュルールを作る — 上記以外のURLに Cache Everything を適用し、Edge Cache TTLを設定する
  3. 適用順を確認 — 除外ルールがキャッシュルールより上に来ているか（先に評価されるか）を必ず確認する
  4. デプロイ後に検証 — レスポンスヘッダの cf-cache-status を見る
    • 静的ページ：HIT（2回目以降）になっていればOK
    • ログイン中・カート：DYNAMIC または BYPASS になっていればOK（HIT なら除外漏れ）

検証コマンドの例

# トップページ（キャッシュされてほしい）
curl -sI https://example.com/ | grep -i cf-cache-status
# → cf-cache-status: HIT が目標

# 管理画面（キャッシュされてはいけない）
curl -sI https://example.com/wp-admin/ | grep -i cf-cache-status
# → BYPASS / DYNAMIC が正常

cf-cache-status: HIT をログイン系で見たら、即座に除外ルールを見直してください。これは設定ミスのサインです。

さらに踏み込んで、Workersでエッジ側のロジックを書く構成は別記事で扱っています。テンプレ単位のキャッシュやA/B、ヘッダ書き換えまでやるなら参考になります。 → Cloudflare WorkersでWordPressをエッジ最適化する

プラグインとの併用

CloudflareとWordPress側のキャッシュプラグインは役割が違うので、競合させずに分担させます。

層役割代表例
サーバー内キャッシュPHP/DB結果・ページキャッシュをサーバー側に保持LiteSpeed Cache・WP Super Cache・W3 Total Cache
オブジェクトキャッシュDBクエリ結果をメモリに保持Redis Object Cache
エッジキャッシュ（CDN）HTML/静的ファイルを世界のエッジに保持Cloudflare

併用のコツです。

  • 二重圧縮・二重minifyを避ける — minify/結合はプラグインかCloudflareのどちらか一方に寄せる
  • 公式プラグイン（Cloudflare 連携）を入れる — 記事更新時にエッジキャッシュを自動パージできる構成にすると、「更新が反映されない」事故を防げる
  • APO（Automatic Platform Optimization） — WordPress向けにHTMLキャッシュを簡単化する有料オプション。手動でCache Rulesを組むのが難しい場合の選択肢

土台が LiteSpeed系サーバーなら、LiteSpeed Cache プラグインが強力です。サーバー側で生成済みHTMLを持てるため、Cloudflareのキャッシュミス時でも素の遅さが出にくくなります。

高速なホスティング・テーマ選びも効く

繰り返しになりますが、Cloudflareは増幅装置です。キャッシュが切れた瞬間の素の速さは、土台で決まります。

ホスティング

WordPressを速くしたいなら、KUSANAGI / LiteSpeed 等の高速化技術に対応した共有・VPSが現実的です。

  • ConoHa WING：国内の高速共有として定番。WordPressの導入・移行がしやすく、独自の高速化技術を備える。小〜中規模サイトの標準解
  • mixhost：LiteSpeed採用の高速共有。WordPress標準・無料移行（年1回目安）・無料独自ドメインで、小規模WPの定番
  • より自由度が要るならKUSANAGI対応のVPSでサーバーキャッシュ＋Cloudflareの二段構えにする

法人・規模別のサーバー選びは、別記事の決定木が使えます。 → あわせて法人のサーバー選び方（共有/VPS/専用）も参照してください。

テーマ

テーマが重いと、どれだけキャッシュしてもキャッシュミス時とエディタ操作が遅いままです。軽量・高速設計のテーマを選ぶと、Core Web Vitals（LCP等）の素点が底上げされます。

  • Emanon：高速表示とSEO・集客導線を意識した国内有料テーマ。ビジネスサイト・オウンドメディア向け。軽さと機能のバランスを取りたい場合の選択肢

まとめ

状況やること
まず無料で速くしたいCDN・Brotli・HTTP/3・静的キャッシュを有効化＋画像をプラグインでWebP化
HTMLまでキャッシュしたい除外ルールを先に作ってから Cache Everything
ログイン/カート/プレビュー必ずキャッシュ除外（cf-cache-status で検証）
画像をCloudflare側で自動最適化Pro（Polish）を検討
キャッシュミス時も速くしたい高速ホスティング（ConoHa WING / mixhost）＋軽量テーマ
エッジでロジックを書きたいWorkers構成（別記事）

要点は「除外を先に設計し、土台の速さを底上げしてからCloudflareで増幅する」。この順番を守れば、無料プランでも体感は十分変わります。

各サービス公式（最新の価格・申込はこちら）

高速ホスティング（WordPress向け） ConoHa WING / VPS mixhost

高速WordPressテーマ WordPress 有料テーマ Emanon

関連記事

Cloudflare・CDN活用CDNとは何か、Cloudflareを挟む理由【入門】無料で何ができる？Cloudflare・CDN活用Cloudflare WorkersでWordPressの重い処理をエッジにオフロードするCloudflare・CDN活用HTTPステータスコードとヘッダの基礎 — 2xx/3xx/4xx/5xxとキャッシュ制御
記事一覧に戻る