「WordPressを速くするならRedis」と聞いて導入したものの、PageSpeedの点数がほとんど変わらない。これは珍しいことではありません。Redisが効く場所と、LCP画像やJavaScriptのようにRedisでは直らない場所が違うからです。
ページキャッシュとRedisは何が違う？
| 仕組み | 何を再利用する | 効きやすい場所 |
|---|---|---|
| ページキャッシュ | 完成HTML | 未ログインの公開ページ |
| Object Cache/Redis | DBクエリ結果・オブジェクト | 管理画面、ログイン、動的ページ |
| Browser Cache | CSS/JS/画像 | 再訪問 |
| CDN Cache | エッジ上の静的/HTML | 遠距離アクセス・オリジン負荷 |
WordPressのObject Cacheは元からある
WordPressにはWP_Object_Cacheがあり、同一リクエスト内でDBアクセスを減らします。Redis Object Cacheなどのdrop-inを使うと、このキャッシュをリクエスト間でも持続させられます。WordPress公式もRedis、Memcachedなどをpersistent object cacheの候補として挙げています。
キャッシュは消えてもDBから再生成できる設計が前提です。Redisをバックアップ代わりにしたり、消せない重要データを入れる発想は避けます。
Site HealthがObject Cacheを勧める基準も参考になる
WordPress Coreは、persistent object cacheを無条件に全サイトへ勧めているわけではありません。Multisiteでは推奨し、通常サイトではautoload option数500超、autoloadデータ約100KB超、comments/options/posts/terms/usersのいずれかが約1,000件以上といった既定閾値を使って「勧めるか」を判定します。
これはRedisの導入義務ではありませんが、「小規模ブログへとりあえずRedis」という考え方より、サイト規模とDB負荷を見て判断するWordPress Coreの考え方に近いです。Site Healthでpersistent object cacheが推奨されているかも判断材料にできます。
※注意：ここで出てくるautoload約100KBは「persistent object cacheを勧めるか」を決めるCore内部の既定条件の1つで、144で扱うautoload総量800KBのSite Health critical閾値とは別物です。同じ数値基準として混同しません。
WP_CACHE=trueだけではRedis/Object Cacheは有効にならない現在のWordPressでは
WP_CACHE定数だけでpersistent object cacheになるわけではありません。Redisサーバーと、Redis Object CacheなどWordPress Object Cache APIへ接続するdrop-in/プラグインが別途必要です。Redisを検討しやすいサイト
- WooCommerceでカート・アカウント・注文管理が重い
- 会員サイトでログイン状態の閲覧が多い
- 投稿数・taxonomy・metaが多く管理画面が遅い
- 同じDBクエリが繰り返されている
- ページキャッシュを使えない動的ページが多い
Redisより先に直すもの
公開記事中心のサイトでは、Redisの前にページキャッシュ、画像、JavaScript、PHP、DBの順でボトルネックを確認します。公開ページが遅いだけなら、Redisよりページキャッシュや画像最適化の方が直接効くことがあります。
Redisは、管理画面・検索・ログイン後・REST APIなどDBを繰り返し読む処理が残っている時に検討します。ここで決めるのは「Redisが不要」ではなく、導入順です。
Redisを導入しない方がいいケース
- 公開記事中心でページキャッシュHIT率が高い
- 管理画面も十分速い
- DBクエリが少ない
- ホストがRedisを正式サポートせず自己管理が必要
- 運用担当が障害時の切り戻しをできない
機能を増やさないことも最適化です。速度差が測れないなら、複雑さを増やさず現状維持する方が長期運用では有利です。
導入判断の具体例
記事中心の月数万PVブログで、公開ページはページキャッシュHIT、管理画面も十分速いなら、Redisを追加しない判断が合理的です。一方、WooCommerceで注文画面・商品管理が遅く、Query Monitorで同じoption/metaクエリが繰り返されるなら、検討価値が高まります。
導入前に確認する5項目
- ホスティングがRedisまたは互換object cacheを提供しているか
- WordPressサイトごとにprefixを分けられるか
- メモリ上限とeviction方針を把握できるか
- 障害時にRedisを無効化してDBへ戻せるか
- 導入前後でadmin/動的ページの時間を測れるか
Object CacheのHIT/MISSをどう考える？
キャッシュに目的の値があればHIT、なければDBなどから再取得して保存します。導入直後やflush直後はMISSが多くて当然です。通常運用で同じクエリを繰り返す画面なのにHITが増えないなら、対象データがキャッシュされていない、TTLが短い、頻繁にflushされているなどを疑います。
ページキャッシュHITのサイトでもRedisが効く場所
公開記事はHTMLキャッシュでPHP自体が動かないためRedisの出番が少ない一方、管理画面、検索、プレビュー、ログイン後、REST API、一部AJAXはPHPとDBを通ります。編集者が多いサイトでは「訪問者のPageSpeedは速いのに運営が遅い」という状態があり、ここでRedisが候補になります。
WooCommerceでの判断
商品一覧の公開ページがキャッシュされていても、カート、マイアカウント、注文管理はユーザーごとのデータを扱います。商品数やtaxonomyが多いとDBクエリも増えます。Redisを検討する前に、遅い画面で同じクエリが繰り返されているかを計測し、導入後に注文・在庫・カートが正常かテストします。
Redisで見るべき運用指標
導入後は「有効になった」だけでなく、hit率、memory usage、evicted keys、接続失敗、平均応答時間を見ます。hit率が低く、ほとんど毎回DBへ行っているなら、キャッシュ対象やサイト構成がRedisに向いていない可能性があります。
evictionが多い場合
Redisのメモリ上限に近づくと古いキーが追い出されます。キャッシュなので消えること自体は異常ではありませんが、頻繁に大量evictionが起きると再生成が増え、期待した高速化が出ません。メモリ量とキャッシュする対象を見直します。
複数WordPressではkey prefixを分ける
複数サイトが同じRedisインスタンスを使う場合は、サイトごとにkey prefixを分けます。prefixが衝突すると、別サイトのoptionsなどが同じキー空間へ入り、誤ったキャッシュを返す危険があります。
マネージドホスティングではサイト単位で自動分離される場合もあるため、自分で設定する前に提供方式を確認します。共有するなら「どのサイトがどのprefixか」を運用台帳へ残します。
Redis障害時のfallbackと切り戻し
理想はRedisが落ちてもWordPressがDBへ戻って表示を続けることです。Redis接続失敗でサイト全体が500になる構成では、速度と引き換えに可用性を落としています。
障害時にRedisを無効化し、必要ならobject-cache.phpを外してDBへ戻す手順を先に確認します。管理画面へ入れない場合も考え、FTPやホスティングのファイルマネージャーなど別経路を把握しておきます。
サーバー選びとの関係
Redisを自分でインストールできない共有サーバーでは、提供状況がホスト依存になります。Redis必須の要件があるなら、契約前に「persistent object cacheの提供」「利用できるプラン」「管理画面から有効化できるか」を確認してください。
Redis導入後のQA
ログイン/ログアウト、記事更新、コメント、検索、REST API、Cron、バックアップを確認します。キャッシュflush後も自動復旧し、DBの正しいデータが再生成されることまで確認できれば、運用上の安心度が上がります。
導入しない判断も記録する
計測した結果、DB待ちが少なくRedisの優先度が低いと分かったら、その判断と測定値を残します。後でトラフィックや機能が増えた時に再検討しやすくなります。
必要になった時だけ追加する方が安全です。
公式情報・参考資料
まとめ
Redisは「速そうだから入れる」機能ではなく、DB再利用がボトルネックの時に使う部品です。公開ブログはページキャッシュを先に、動的サイトはRedisを候補にするという順番なら、複雑さを増やしにくくなります。141〜149を横断した判断は150の全体Hubにまとめています。
コメント