※本記事には広告・アフィリエイトリンクが含まれています。
WordPress高速化でキャッシュを「多く入れる」ほど良いわけではありません。ブラウザ、Cloudflare、サーバー、WordPressプラグインのどこで何をキャッシュするかを決め、更新時にどの層をpurgeするか説明できる構成が正解です。
WordPressで表示速度を改善しようとすると、レンタルサーバーのキャッシュ、Cocoonやプラグインの高速化、Cloudflare CDNなど複数の設定が重なります。うまく動けば速くなりますが、役割が重複すると「記事を更新したのに古い」「管理画面では正しいのに一般ユーザーだけ違う」といった症状が起きます。
本記事は一般的な速度改善記事ではなく、複数キャッシュ層をどう分担させるかに絞ります。Cloudflare公式も、APO導入時に他キャッシュプラグインとの併用で予期しない挙動が起こる可能性を案内しており、最初は単純な構成から検証することが重要です。
WordPress周辺のキャッシュは少なくとも5層ある
| 層 | 保存場所 | 主な対象 | 更新時の注意 |
|---|---|---|---|
| ブラウザ | ユーザー端末 | 画像/CSS/JS等 | 端末側に古い資産が残る |
| Cloudflare/CDN | エッジ | 静的資産、設定によりHTML | エッジpurgeが必要 |
| サーバーページキャッシュ | ホスティング側 | 生成済みHTML | WordPress更新との連携を確認 |
| WordPressプラグイン | WordPress側 | ページ/最適化済み資産 | 他層と重複しやすい |
| オブジェクト/DBキャッシュ | サーバー内部 | クエリ結果等 | ページキャッシュとは別物 |
まず「誰がHTMLをキャッシュするか」を1つずつ決める
画像やCSSのブラウザキャッシュと、ページHTMLのキャッシュは分けて考えます。問題が起きやすいのはHTMLです。ログイン状態、プレビュー、コメント、会員、ECなどユーザーごとに表示が変わるWordPressで、複数レイヤーが同じHTMLをキャッシュすると除外条件のズレが出やすくなります。
最初はサーバー側ページキャッシュだけ、またはCloudflare側だけなど、主担当を決めます。正常動作を確認してから補助キャッシュを追加し、効果がないレイヤーは増やしません。
キャッシュ層の役割を分ける
Cloudflare標準キャッシュとHTMLキャッシュを分ける
Cloudflareは画像・CSS・JavaScriptなど静的ファイルを標準でキャッシュします。これはWordPress HTMLをすべてキャッシュすることとは違います。Cache RulesやAPOでHTMLまで対象にする場合は、ログイン・管理・プレビュー等の除外が重要です。
「Cloudflareを入れたからCache Everything」と一括設定するより、静的配信→必要なら匿名HTMLという順に広げます。ECや会員サイトは特に個別確認が必要です。
サーバーキャッシュとプラグインキャッシュの重複
レンタルサーバー側にWordPress向けキャッシュがある状態で、同じ目的のプラグインを追加すると、更新時のpurge順序が分かりにくくなります。プラグインは「入れたら速くなるもの」ではなく、現行サーバーで不足している機能だけ補うものとして考えます。
また画像最適化、CSS結合、JavaScript遅延はページキャッシュとは別機能です。1つの高速化プラグインが複数機能を持つため、「キャッシュを切ったつもりでもCSS最適化は残っている」ことがあります。
症状からキャッシュ層を逆引きする
| 症状 | 疑う層 | 確認方法 |
|---|---|---|
| 自分だけ古い表示 | ブラウザ | シークレット/別端末で確認 |
| 全員が古い表示 | CDN/サーバーページキャッシュ | レスポンスヘッダー、purge |
| ログイン時だけ新しい | 匿名向けHTMLキャッシュ | Cookie除外の確認 |
| CSSだけ古い | ブラウザ/CDN/最適化資産 | ファイルURLとcache statusを確認 |
| 管理画面までおかしい | 過剰なキャッシュルール | /wp-admin除外を確認 |
| フォーム送信後の表示がおかしい | HTMLキャッシュ | POST/動的ページの除外を確認 |
Automatic Cache Managementを使う意味
Cloudflare WordPressプラグインには、投稿・ページ・添付・コメントの追加/編集/削除やテーマ変更時に関連キャッシュをpurgeするAutomatic Cache Managementがあります。これにより「更新したら自分で全キャッシュ削除」という手作業を減らせます。
ただし自動purgeがあるから何でもキャッシュしてよいわけではありません。動的ページをそもそもキャッシュ対象から外す設計と、更新時に対象URLを正しくpurgeする仕組みの両方が必要です。
ログイン・カート・会員ページは「キャッシュしない」が正解になる
HTMLキャッシュを広げるほど速くなるわけではありません。WordPress管理画面、ログイン済み画面、プレビュー、ECのカート/決済、会員専用ページなどはユーザーごとに内容が変わるため、キャッシュ除外が必要です。WooCommerce等ではCookieやURL条件を使ってbypassする設計が一般的です。
確認のコツは、未ログインではHITしても、ログイン時やカート操作時には意図どおりBYPASS/DYNAMICになるかを見ることです。匿名ユーザーの表示速度だけを見て、個別セッションまでキャッシュしてしまう設定は避けます。
キャッシュを増やす前にオリジンサーバーを見る
キャッシュHIT時だけ速く、MISS時に極端に遅い場合は、PHP/DBやサーバー性能の問題が隠れている可能性があります。編集者や検索エンジン、初回訪問、ログインユーザーは常に同じキャッシュを使うとは限りません。
オリジン自体が不安定なら、キャッシュ設定を複雑化するよりサーバー・プラグイン・DBの見直しを先に行います。
サーバーキャッシュ、バックアップ、容量、管理性までまとめて不満があるなら、設定を積み重ねるよりホスティングの見直しがシンプルな場合があります。最新条件は各公式で確認してください。
僕ならこの順番でキャッシュを設計する
- キャッシュなし/最小構成のオリジン速度を測る
- レンタルサーバー標準キャッシュを確認する
- 画像・CSS・JSのブラウザ/CDNキャッシュを確認する
- 更新・フォーム・ログインが正常かテストする
- 必要な場合だけHTMLキャッシュを追加する
- purge方法を1つの運用手順にまとめる
- 月1回、古い表示・フォーム・APIを確認する
公開・更新時のQA
- 公開直後に一般ブラウザで新本文が見える
- スマホでも同じ内容が見える
- アイキャッチ・CSS・JSが旧版のまま残っていない
- wp-adminとプレビューがキャッシュされていない
- フォーム送信が正常
- REST APIや外部連携が正常
- purge手順を担当者が説明できる
「全部のキャッシュを削除」が毎回の解決策になっているなら、構成が複雑すぎるサインです。どの変更でどのキャッシュを消すべきか特定できる形へ整理します。
古い表示を切り分ける実務
レスポンスヘッダーで「どこから返ったか」を確認する
キャッシュ問題を感覚で判断せず、ブラウザの開発者ツールやcurlでレスポンスヘッダーを確認します。Cloudflareではcf-cache-statusが基本の手掛かりです。HITならCloudflareキャッシュから配信、MISSならキャッシュに無くオリジン等から取得、BYPASSならキャッシュ可能性はあっても設定やレスポンス条件で迂回した状態です。
APOを使っている場合、Cloudflare公式はCF-Cache-Status、cf-apo-via、cf-edge-cacheの3つを確認する方法を案内しています。典型的な正常例はCF-Cache-Status: HIT、cf-apo-viaがキャッシュ経路を示し、cf-edge-cache: cache, platform=wordpressがWordPress連携を示す状態です。
| ヘッダー | 見ること |
|---|---|
CF-Cache-Status |
HIT/MISS/BYPASS/DYNAMIC等。どの層へ取りに行ったかの切り分け |
cf-apo-via |
APOがそのリクエストをどう扱ったか |
cf-edge-cache |
WordPressプラットフォームのエッジキャッシュ連携 |
同じURLを未ログイン・ログイン・シークレットウィンドウで比較すると、Cookieによる除外が正しく効いているか確認しやすくなります。更新が反映されない時に「とりあえず全部削除」ではなく、どの層が古いレスポンスを返しているかを特定します。
CSS・JavaScriptはファイル名のバージョン管理も重要
ページHTMLだけ更新されても、同じURLのCSSやJavaScriptに長いブラウザキャッシュが付いていると、古い見た目や挙動が残ることがあります。テーマやビルド環境がクエリ文字列やハッシュ付きファイル名でバージョンを変える仕組みを持っている場合は、それを壊さないようにします。
キャッシュTTLを極端に短くするより、静的資産は長くキャッシュし、変更時にURLが変わる設計の方が効率的です。ただしWordPressテーマ・プラグインがどの方法を採用しているか確認してから調整します。
緊急時の「キャッシュ無効化手順」を1枚にする
公開直後に重大な誤りを修正したのに古いページが残る場合に備え、Cloudflare purge、サーバーキャッシュ削除、WordPressプラグインキャッシュ削除、ブラウザ確認の順番を決めておきます。複数サイトではサイトごとに使っているキャッシュ層が違うため、共通手順と例外を分けます。
緊急時に管理画面を探し回らないよう、どの画面でpurgeできるかを運用台帳へ記録しておくと復旧が速くなります。
公式情報・参考資料
仕様確認日：2026年10月1日。設定画面・料金・提供機能は変更されるため、実作業前にリンク先の最新版も確認してください。
- Cloudflare Cache：Get started
- Cloudflare Cache Rules
- Cloudflare：Automatic Cache Management
- Cloudflare：APO WordPress plugin
- Cloudflare：APOのレスポンスヘッダー確認
- Cloudflare：MISS/BYPASSの切り分け
あわせて読みたい
まとめ
WordPressキャッシュは数ではなく役割分担です。静的ファイル、HTML、DB/オブジェクトを分け、Cloudflare・サーバー・プラグインの主担当を決めてください。更新時にどこをpurgeするか分からない構成は、速度改善より保守負担を増やします。
コメント