CloudflareをWordPressサイトの前に置いても、HTMLはデフォルトではキャッシュされません。画像・CSS・JavaScriptなどの静的ファイルは自動でキャッシュされますが、ページ本体（HTML）は、毎回サーバーまで取りに行く動きになります。そのため、Cloudflareを入れただけでは、TTFBはあまり縮みません。
この記事では、筆者のブログ（dadblog.fyi）で、CloudflareのCache RulesでHTMLをキャッシュし、TTFBが229ms → 56msになった手順と、途中でハマった3つの落とし穴を紹介します。
🎯 やったこと：ルールを2本作る
Cloudflareの管理画面の「Caching → Cache Rules」で、次の2本のルールを、この順番で作りました。
| 順番 | ルール名 | 条件 | 動作 |
|---|---|---|---|
| 1 | Cache HTML | ホスト名が、自分のサイトと一致 | キャッシュ対象にする（Eligible for cache）、Edge TTLは2時間 |
| 2 | Bypass（除外） | wp-admin、wp-login.php、wp-jsonへのアクセス、またはログイン・パスワード保護・コメント投稿者のCookieがあるとき | キャッシュしない（Bypass cache） |
1本目で「HTMLもキャッシュする」と広く指定し、2本目で、キャッシュしてはいけないもの（管理画面・ログイン中のユーザー・REST API）を例外として外す、という考え方です。除外に使ったCookieは、wordpress_logged_in、wp-postpass、comment_authorです。
⚠️ ハマった落とし穴（3つ）
- ルールの順番が効く。Cache Rulesでは、あとのルールが先のルールを上書きします。除外ルール（Bypass）は、必ず最後に置きます。先に置くと、除外したはずのものがキャッシュされます。
- ホスト名の入力ミスで、ルールが一切当たらなかった。値の欄に、見た目では分かりにくい余計な文字（「›」）が1つ混ざっていて、ルールがどのリクエストにも一致しませんでした。入力し直して解決しました。設定したのに効かないときは、まず値を打ち直すのが早いです。
- 2本目のテンプレートが「すべてのリクエスト」になっていた。除外ルールのテンプレートを選ぶと、条件が「All incoming requests」の状態で始まりました。そのまま保存すると、サイトのすべてが「キャッシュしない」になります。条件をCustom filter expressionに切り替えて、除外したいものだけを指定します。
🔍 効いているかの確認方法
レスポンスヘッダーのcf-cache-statusを見ます。HITならCloudflareのキャッシュから返っています。1回目はMISS、2回目以降がHITになるのが正常です。DYNAMICのままなら、ルールが当たっていません。
ときどきREVALIDATEDと表示されることもあります。これは、キャッシュの有効期限（Edge TTL）が切れたあとに、Cloudflareが「中身は変わっていませんか？」とサーバーに確認し、変わっていなければ手元のキャッシュをそのまま使った状態です。HITの仲間で、サーバーへの確認が1往復ぶん増えるだけなので、正常な動作です。
curl -sI https://example.com/ | grep -i cf-cache-status⏱ 結果
- 設定前：TTFB 約229ms
- 設定後（
HIT）：TTFB 約56ms
測定は筆者の環境での実測で、サイトやアクセス元によって数字は変わります。
📝 運用上の注意
- Edge TTLを2時間にしたので、記事を更新しても、反映まで最大2時間かかることがあります。急ぐ場合は、Cloudflareの管理画面から該当URLのキャッシュを削除（パージ）します。
- ログイン中の自分には、キャッシュされていないページが見えます。キャッシュの効果を確認するときは、ログアウトした状態か、
curlで測ってください。 - WordPress側のキャッシュ（キャッシュプラグイン）や、CDNの選び方によって、そもそもこの設定が要らない場合もあります。実際、QUIC.cloudを使っているサイトでは、最初からHTMLがキャッシュされ、TTFBは約46〜48msでした。
