CloudflareでWordPress高速化｜失敗を防ぐ設定

2026年8月22日
Cloudflare

こんにちは。Osukeラーニング、運営者の「osuke」です。

WordPressへCloudflareを導入したのに、PageSpeed Insightsの点数やページの体感速度があまり変わらず、「設定が間違っているのでは」と迷っていませんか。Cloudflareは画像・CSS・JavaScriptなどを既定でキャッシュしますが、WordPressが生成するHTMLはそのままではキャッシュしません。反対に、何でもキャッシュすると管理画面、ログイン、フォーム、カートなどを壊す恐れがあります。

この記事では、CloudflareでWordPressを高速化する設定を、計測、既定キャッシュ、無料機能、Cache Rules、有料のAPO、更新反映、効果確認まで順番に解説します。osuke本人の体験としては書かず、2026年8月22日時点のCloudflare公式資料と、Xで公開された利用者・開発者8件の改善例、注意喚起、反対事例を照合しました。Xの数値は投稿者の環境における結果であり、Cloudflare全体の効果を保証するものではありません。

Cloudflare側の設定へ進む前に、対象DNSレコードがProxiedかをCloudflareのDNS設定方法で確認し、通信経路をCloudflareのSSL設定方法に沿ってFull (strict)へ整えてください。サービスの役割を整理したい方はCloudflareとは何かを解説した記事から読むとつながります。

記事のポイント

Cloudflare導入前後を同じ条件で計測する
既定ではHTMLがキャッシュされないことを理解する
管理・ログイン・フォーム等を先に除外する
無料のCache Rulesと月額APOを比較して選ぶ
CF-Cache-StatusとAgeで効果を確認する

CloudflareでWordPressを高速化する基本設定

高速化で最初に行うのは、設定を全部ONにすることではありません。現在の遅い場所を測り、Cloudflareが処理できる範囲と元サーバー側で直す範囲を分けます。そのうえで静的資源、通信方式、HTMLの順に対象を広げると、表示崩れや古いページの配信を避けやすくなります。

変更前に表示速度を計測する

設定前の数値がなければ、高速化できたか判断できません。まずトップページ、代表的な記事、画像が多い記事の3URLを選び、同じ端末・同じ回線・同じ時間帯で計測します。PageSpeed Insightsの点数だけでなく、最初の応答を待つTTFB、主要コンテンツの表示、操作への反応、転送量を記録してください。Cloudflare公式の遅いサイトの調査手順は、TTFBの目安を800ミリ秒未満とし、ObservatoryやRUMで遅い資源を特定する流れを示しています。

Xでは、WordPressとCloudflare、同一オリジン化、CDN最適化などを組み合わせ、デスクトップ性能88を報告した公開事例がありました。一方、Cache EverythingでTTFBが90%改善したという記事紹介もあります。どちらも改善例ですが、複数施策の内訳、元サーバー、訪問地域、ページ内容が同一ではないため、「Cloudflareを使えば90%速くなる」という再現値にはできません。

計測は各URLを1回だけ開いて終わらせず、キャッシュがない初回と、同じ場所から再取得した2回目を分けます。初回はCloudflareが元サーバーから資源を取りに行くためMISS、2回目以降はHITになる可能性があります。匿名ウィンドウとログイン中の管理者でも結果を分け、管理者だけ遅い場合に「高速化に失敗した」と誤認しないようにします。

目標は100点ではなく、読者が多いページで遅い原因を1つ減らすことです。たとえばTTFBが遅いならHTMLキャッシュ、画像転送量が大きいなら画像圧縮、JavaScriptが描画を止めるならスクリプトの整理が候補です。変更前の日時、URL、TTFB、表示指標、転送量、Cloudflareキャッシュ状態を表にしてから、設定を1つだけ変えます。

変更前に記録する6項目

計測日時・端末・回線
トップ・代表記事・画像の多い記事
TTFBと主要表示指標
総転送量と重い資源
初回と2回目の差
CF-Cache-StatusとAge

DNS・SSL・元サーバーを確認する

Cloudflareのキャッシュが働くのは、対象ホストのDNSレコードがProxied、つまりオレンジ色の雲になっている場合です。DNS onlyでは名前解決だけをCloudflareが担当し、Web通信は元サーバーへ直接進みます。HTML、画像、CSSのURLが同じドメインでも、サブドメイン側だけDNS onlyなら、その資源はCloudflareのキャッシュや速度機能の対象になりません。

SSL/TLSはFull (strict)を基本にし、元サーバーの443番、証明書の期限、ホスト名、証明書チェーンを確認します。Flexibleのまま高速化設定を増やすと、WordPressのHTTPS強制と衝突してリダイレクトループが起きる可能性があります。速度計測の前にDNSとSSLを安定させるのは、キャッシュされたエラーページや古い転送を評価対象へ混ぜないためです。

Cloudflareは元サーバー自体を高速なサーバーへ交換する機能ではありません。キャッシュMISS、WordPress管理画面、検索結果、ログイン利用者、APIなどは元サーバーへ到達します。PHPの実行、データベース問い合わせ、遅いプラグイン、巨大画像が原因なら、Cloudflareだけでは解決しません。元サーバーのTTFBが遅いと、各Cloudflare拠点で最初にキャッシュを作る処理も遅くなります。

確認時はCloudflareを一時停止して比較するのではなく、まずCloudflare経由の応答ヘッダーと元サーバーの管理画面を使います。HSTSを有効にしているサイトでCloudflareを止めると、元サーバー証明書の状態によってアクセス不能になる恐れがあります。DNS、SSL、PHP、データベースを別々の層として記録し、Cloudflareで直せる範囲を明確にしてください。

高速化前に止める条件

対象レコードがDNS only
SSLモードがFlexibleまたはエラー発生中
525・526・リダイレクトループが残る
元サーバーのPHPやDBが常に遅い
画像・動画自体が過大なまま

Cloudflareの既定キャッシュを理解する

CloudflareをProxiedにすると、一般的な画像、CSS、JavaScript、フォントなどは既定のキャッシュ対象になります。しかしCloudflare公式の既定キャッシュ仕様では、対象をMIMEタイプではなくファイル拡張子で判断し、HTMLとJSONは既定ではキャッシュしないと説明されています。WordPressの記事URLは拡張子なしのHTMLを返すことが多いため、Cloudflareを導入しただけではページ本体が毎回元サーバーで生成される場合があります。

Xでも、Cloudflareへ料金を払っていてもHTMLが一切キャッシュされていない可能性を指摘した公開投稿がありました。これは公式仕様と一致します。画像・CSS・JSがHITでも、ドキュメントHTMLがDYNAMICなら、静的資源の転送は減ってもTTFB改善が限定的になることがあります。まず「Cloudflareが動いていない」のではなく、「どの種類が対象か」を分けます。

既定キャッシュには安全上の利点もあります。WordPress管理画面、ログイン後の表示、コメント確認、検索、プレビュー、フォーム結果などのHTMLを無条件で保存しないため、利用者ごとの内容が他人へ配信される事故を避けやすいからです。HTMLを高速化したい場合は、APOまたはCache Rulesを使い、匿名の公開ページだけを明示的に対象へ加えます。

ブラウザの開発者ツールでトップページHTMLと画像を選び、応答ヘッダーのCF-Cache-Statusを比較してください。画像がHIT、HTMLがDYNAMICなら既定動作として自然です。CSSや画像までDYNAMICなら、DNSがProxiedか、拡張子、元サーバーのCache-Control、Set-Cookie、Development Modeを確認します。

方式	主な対象	更新反映	料金・条件	向く人
既定キャッシュ	画像・CSS・JS等	TTLまたは手動パージ	全プラン・Proxied	最初の安全な設定
Cache Rules	条件指定したHTML等	自分で除外・TTL・パージ設計	Freeは10ルール	仕組みを理解して調整したい人
APO	WordPressのHTMLと静的資源	プラグインが更新を通知	Freeは月5ドル、Pro以上に含む	安全な自動化を優先する人

既定キャッシュの判断

画像・CSS・JS：既定で対象になり得る
HTML・JSON：既定では対象外
DNS only・第三者ドメイン：Cloudflareキャッシュ対象外
HTMLを対象にするなら除外と更新運用を先に設計

WordPressプラグインを安全に設定する

Cloudflare公式WordPressプラグインは、WordPressで記事・固定ページ・添付・コメントを更新したとき、関連URLのキャッシュを削除する役割を持ちます。公式のAutomatic Cache Management資料では、投稿の編集・削除、添付削除、テーマ変更、カスタマイザー保存などのWordPressフックを使ってパージすると説明されています。

接続にはGlobal API Keyより、対象ゾーンに必要な権限だけを持つAPI Tokenを使います。トークンをWordPressへ入力するため、管理者アカウント、プラグイン、サーバーの更新と防御も必要です。Cloudflare公式のWordPressテンプレートを基にし、複数ゾーンや不要な編集権限を含めないことが、速度設定より先の安全策になります。

WP Rocket、W3 Total Cache、LiteSpeed Cacheなど別のキャッシュプラグインがすでに動いている場合は、最初から全部を併用しません。Cloudflare公式のAPOプラグイン導入手順も、APO設定時はいったん既存キャッシュプラグインを停止し、APOが動いた後に1つずつ再有効化して不具合を確認するよう勧めています。二重キャッシュは古いページ、ログイン不整合、更新遅延の原因を見えにくくします。

導入後は記事を1件だけ更新し、匿名ブラウザで30秒〜数分以内に新しい内容が出るか確認します。管理者として見える内容と匿名利用者が見るキャッシュは異なるため、ログイン中の画面だけで判定しません。自動パージが失敗したときのために、Cloudflareダッシュボードで単一URLを削除する手順も控えておきます。

プラグイン導入の順番

既存キャッシュ設定とプラグインを記録
対象ゾーン限定のAPI Tokenを作成
Cloudflare公式プラグインを有効化
Automatic Cache Managementを確認
既存プラグインは1つずつ再検証

無料の速度機能を一つずつ試す

無料プランでもHTTP/3、Early Hints、圧縮、Cloudflare Fonts、Rocket Loaderなどを利用できます。ただし「利用できる」と「すべてのWordPressで速くなる」は同じではありません。HTTP/3は通信品質が悪い回線で有利になりやすく、公式資料では訪問者とCloudflare間が対象で、Cloudflareから元サーバーへのHTTP/3は未対応とされています。

Early Hintsは、元サーバーの本応答より先に103応答でpreloadやpreconnect対象を知らせます。公式資料によると、Linkヘッダーを持つ200・301・302などが対象で、HTTP/2またはHTTP/3上で動きます。WordPressテーマが適切なLinkヘッダーを出していなければ、ONにしても効果が見えない場合があります。

Cloudflare FontsはGoogle Fontsを同じCloudflareゾーンから配信し、DNS・TLS接続先を減らせます。ただし公式の制限では、APOと同時には動かず、APO側が類似のGoogle Fonts最適化を行います。Rocket LoaderはJavaScriptを遅延できますが、メニュー、スライダー、計測、決済などが壊れた場合は無効化して再テストします。

Xには、HTTP/3、Brotli、APOなどをWordPress推奨設定として並べた投稿がありましたが、同じ一覧のAuto MinifyはCloudflare公式で2024年8月に廃止済みです。投稿日が新しくても設定一覧を丸ごとコピーせず、現在のダッシュボードと公式資料を確認してください。圧縮は現在プランやブラウザに応じて自動選択されるため、古い「BrotliをONにする」手順がそのまま表示されない場合があります。

無料機能の検証ルール

1回に有効化する機能は1つ
HTTP/3は訪問者→Cloudflare間
Early HintsはLinkヘッダーの有無を確認
Cloudflare FontsとAPOは重複させない
Rocket LoaderでJS不具合が出たら戻す
Auto Minifyは廃止済み

Cloudflareのキャッシュで失敗しない設定

HTMLキャッシュはTTFBと元サーバー負荷を大きく改善できる一方、利用者ごとに変わるページを共有すると重大な不具合になります。ここからは「除外を先に作る」「公開ページだけを対象にする」「更新と検証を運用へ含める」という順番で設定します。

Cache RulesでHTMLを安全にキャッシュする

Cache Rulesは、URLパス、Cookie、ホスト名などの条件で、キャッシュ対象とTTLを決める機能です。Cloudflare公式資料では全プランで利用でき、Freeは10件、Proは25件、Businessは50件と案内されています。WordPressのHTMLを無料でキャッシュしたい場合、最初に除外ルールを作り、その後で匿名の公開ページをEligible for cacheへ設定します。

除外候補は/wp-admin/、/wp-login.php、プレビュー、検索、REST API、フィード、フォーム完了URLです。WooCommerceならカート、購入手続き、マイアカウント、注文確認を必ず外します。Cookieを条件にできる範囲はプランとCache Key機能によって異なるため、無料プランで複雑なログイン判定を自作するより、WordPress向けのAPOや実績あるプラグインを選ぶほうが安全な場合があります。

公開ページを対象にするルールは、先に除外をDeployして動作確認してから追加します。ルールは複数が一致し、同じ項目が競合する場合は後に評価される設定が勝つため、順序も重要です。ゾーン全体へ「Cache Everything」を1本だけ作ると、除外漏れが起きたときに管理ページや利用者固有の応答まで保存する恐れがあります。

設定後は、未ログイン、ログイン中、フォーム入力、プレビュー、スマートフォンの5場面で確認します。ログイン中に他人の表示が出る、カート内容が残る、nonceエラーになる、更新が反映されない場合は即座にHTMLキャッシュルールを無効化し、該当URLとCookieを見直します。速さより、利用者固有データを共有しないことを優先してください。

先にキャッシュから除外する場所

/wp-admin/ と /wp-login.php
プレビュー・検索・REST API
問い合わせ完了・会員専用ページ
カート・決済・マイアカウント
個人別内容やnonceを含む応答

Edge TTLとBrowser TTLを分ける

Edge TTLはCloudflareの拠点に資源を置く時間、Browser TTLは訪問者のブラウザが資源を保持する時間です。名前は似ていますが、削除できる場所が違います。Cloudflare公式のTTL資料によると、Freeプランで指定できる最小Edge TTLは2時間、既定のBrowser Cache TTLは全プラン4時間です。

Edge TTLが長ければ元サーバーへの問い合わせを減らせますが、記事更新後に古いHTMLが残る時間も長くなります。Browser TTLが長い場合、Cloudflare側でPurge Everythingを実行しても、再訪問者の端末にある古いCSSや画像は消せません。更新頻度が高いHTMLと、ファイル名へバージョンが付くCSS・JS・画像を同じTTLにしないことが重要です。

WordPressの公開HTMLでは、まず元サーバーのCache-Controlを尊重し、自動パージが動く構成から始めます。静的資源はテーマやプラグイン更新でファイル名が変わるなら長めにできます。反対にstyle.cssのように同じURLへ上書きする運用でBrowser TTLを1年にすると、利用者だけ古いデザインが残る可能性があります。

迷う場合は既定値を尊重し、Edgeで本当にHITするかを先に確認してください。TTLを長くしても、Set-CookieやCache-Control: privateでBYPASSされていれば効果は出ません。TTL変更はキャッシュ対象の確認後に行い、記事更新・テーマ更新・緊急修正の3場面で新しい内容が届くか試します。

TTLの使い分け

Edge TTL：Cloudflare拠点の保存時間
Browser TTL：訪問者端末の保存時間
Freeの最小Edge TTL：2時間
既定Browser TTL：4時間
Cloudflareパージではブラウザキャッシュを消せない

APOを使うべき条件を判断する

Automatic Platform Optimization（APO）は、WordPressのHTMLをCloudflareのエッジへ保存し、プラグインから更新情報を受けて古いページを無効化する仕組みです。Cloudflare公式のAPO概要では、ログイン・管理者利用者はキャッシュを回避し、匿名訪問者へエッジからページ全体を配信すると説明されています。Cache Rulesを自分で組むより、WordPress固有の更新とログインを扱いやすい点が利点です。

料金はFree planでは月5ドルの追加、Pro・Businessではプランに含まれるとCloudflare公式サポート資料に記載されています。価格は変更される可能性があるため、購入前にダッシュボードの表示を確認してください。アクセスが少なく元サーバーも速いサイトなら、既定キャッシュと無料機能だけで十分な場合があります。

公式FAQでは、WordPressプラグイン使用時にAPOはコンテンツを30日キャッシュし、変更時は30秒以内に無効化すると説明されています。ただしクエリ文字列付きURL、他のキャッシュプラグイン、特殊なCookie、CSP、サブドメイン構成などで挙動が変わります。また公式プラグインはWordPress multisiteをサポートしないため、マルチサイトでは購入前に別構成を検討します。

APOが向くのは、匿名閲覧が中心のブログ・メディアで、遠方の訪問者に対するTTFBをそろえたい人です。会員制、WooCommerce、個別表示が多いサイトでは除外テストが増えます。最初に既存キャッシュプラグインを停止し、APOだけでトップ、記事、ログイン、フォーム、更新反映を確認してから、必要な機能だけ戻してください。

APOを選ぶ判断基準

匿名閲覧中心でHTMLのTTFBを改善したい
Freeの月5ドルまたはPro以上を許容できる
公式プラグインで更新パージを自動化したい
WordPress multisiteではない
既存キャッシュプラグインを整理して検証できる

更新反映とキャッシュ削除を運用する

高速化設定は、公開時より記事更新時に問題が出やすくなります。Cloudflare公式はキャッシュ削除の基本として、必要なURLだけを消す単一ファイルパージを推奨しています。Purge Everythingはゾーン全体のキャッシュを空にし、その後のアクセスが一斉に元サーバーへ向かうため、毎回の更新で使う方法には向きません。

Xでは、投稿・固定ページ・カスタム投稿へCache-Tagを付け、変更したタグだけを削除するWordPress実装の公開例がありました。これは「全部消して直ることを祈る」運用から、関係するページだけを無効化する考え方です。コードやプラグイン自体を無条件に推奨するものではありませんが、更新範囲とパージ範囲を合わせる参考になります。

フォームやnonceを含むページでは、キャッシュされたHTMLの有効期限とWordPress側トークンの期限がずれることがあります。キャッシュプラグイン提供元がnonce-safe cachingを新機能として挙げた投稿も、この難しさを示しています。製品宣伝の投稿なので効果の根拠にはしませんが、フォームを一般記事と同じルールで保存しない理由にはなります。

運用手順は、記事更新→関連URLの自動パージ→匿名ブラウザで確認→必要なら単一URLパージ→それでも古ければブラウザキャッシュと元サーバーキャッシュを確認、の順にします。毎回Purge Everythingで直るなら、自動パージまたはルール設計が不足しています。更新日、対象URL、パージ方法、反映までの時間を3回記録し、安定して再現する状態を完成条件にしてください。

更新後の確認フロー

記事を1件更新
自動パージの実行を確認
匿名ブラウザで新内容を確認
必要時だけ単一URLをパージ
古ければEdge・ブラウザ・サーバーを分けて調査

CF-Cache-Statusで高速化を確認する

Cloudflareの効果は、PageSpeedの点数だけでなく応答ヘッダーで確認します。Cloudflare公式のCache Status資料では、HITはキャッシュから提供、MISSはキャッシュ対象だがその拠点に未格納、DYNAMICは要求時点で対象外、BYPASSは対象候補だったものの元サーバーの応答ヘッダー等で保存できなかった状態です。

確認は同じURLを同じクライアントから2回取得します。パージ直後の1回目がMISS、その後がHITなら自然です。AgeヘッダーはHITした資源がキャッシュに置かれてからの時間を示します。連続してBYPASSならCache-Control: private、no-store、Set-Cookieなど、DYNAMICならHTMLを対象化するルール、Development Mode、除外ルールを確認します。

APOをブラウザで調べるときは、開発者ツールの「Disable cache」がONだとChromeがCache-Control: no-cacheを送るため、BYPASSに見えることがあります。公式FAQはDisable cacheを外し、HTMLとして取得してcf-cache-status: HITとcf-apo-via: cacheを確認するよう案内しています。検査ツール自体が結果を変える点に注意してください。

最後に変更前と同じ3URLを再計測し、TTFB、表示指標、転送量、キャッシュ状態を比較します。改善しなければ機能を追加し続けず、遅い資源が第三者スクリプト、巨大画像、PHP、データベースのどれかへ戻って調べます。今日の一歩は、トップページHTMLを2回読み込み、CF-Cache-StatusとAgeを記録することです。速度が安定したら、次はWAFやボット対策などCloudflareのセキュリティ設定へ進みます。

Cache Statusの読み方