WordPress の管理画面で「ツール → サイトヘルス」を開いたとき、こんなメッセージを目にしたことはありませんか？
永続オブジェクトキャッシュは、サイトのデータベースの効率を上げます。その結果、WordPress がサイトのコンテンツや設定を迅速に取得できるようになるため、読み込み時間を短縮できます。
初めてこの表示を見たとき、「エラー？ 何かまずいことが起きた？」と焦った方も少なくないでしょう。私自身、エックスサーバーで運用しているこのブログ（Rapls Works）で初めてこの警告を見たときは、何か深刻な問題が起きたのかと身構えました。
しかし結論から言えば、これはエラーではなく「おすすめの改善」にすぎません。個人ブログや小規模サイトであれば、放置しても動作に支障はありません。
とはいえ、対処すればデータベースクエリの削減やサーバー負荷の軽減といったメリットが得られます。本記事では、この警告の正体から具体的な対処法まで、エックスサーバーでの実体験を中心にレンタルサーバー別に徹底解説します。
この記事の結論
エックスサーバー・ConoHa WINGなどAPCu対応サーバーなら、「APCu Manager」や「Powered Cache」プラグインをインストールして設定するだけで解決します。Redis/Memcached/APCuすべて非対応のサーバーなら、functions.phpに1行追加して警告を非表示にするのが現実的です。
永続オブジェクトキャッシュとは何か
永続オブジェクトキャッシュとは、WordPressがデータベースから取得したデータを「リクエストをまたいで」保持し続ける仕組みのことです。通常のキャッシュはページ読み込み完了時に破棄されますが、永続キャッシュは次のアクセス時にも再利用できます。
WordPress はリクエストのたびにデータベースを叩いている
WordPress は「動的 CMS」です。ユーザーがページにアクセスするたびに、PHPがデータベース（MySQL / MariaDB）から投稿データ、サイト設定、ウィジェット情報、ユーザー情報などを取得し、HTMLを生成して返しています。
このとき、たった1ページを表示するだけでも数十〜数百回のデータベースクエリが走ることがあります。プラグインを多く使っているサイトではその数がさらに増えます。
私のブログ（エックスサーバー環境）で Query Monitor プラグインを使って計測したところ、トップページだけで約120回のデータベースクエリが発生していました。アクセスが集中すれば、データベースサーバーに大きな負荷がかかり、表示速度が低下します。
Query Monitor プラグインで表示されるデータベースクエリ数の画面
標準のオブジェクトキャッシュは「使い捨て」
WordPress にはこの問題を軽減するための仕組みとして、WP_Object_Cache というクラスが標準で組み込まれています。一度データベースから取得したデータをPHPのメモリ上に一時保存し、同じリクエスト内で同じデータを再度取得する際にはデータベースを叩かずにメモリから返します。
しかし、ここに大きな制約があります。デフォルトのオブジェクトキャッシュは「非永続（non-persistent）」です。1回のページ読み込みが完了した瞬間にキャッシュデータはすべて破棄されます。
つまり、次のユーザーが同じページにアクセスしたとき、WordPress はまた一からデータベースに問い合わせます。せっかくキャッシュしたのに、リクエストごとに毎回リセットされてしまうのです。
イメージで理解する
非永続オブジェクトキャッシュは、毎回ホワイトボードに書いて、帰るときに全部消すような状態です。翌日（次のリクエスト）にはまた最初から書き直しになります。永続オブジェクトキャッシュは、ノートに書いて残しておくようなものです。翌日もノートを見ればすぐに情報を参照できます。
「永続」の意味 ― リクエストをまたいでキャッシュを保持する
永続オブジェクトキャッシュ（Persistent Object Cache）とは、ページの読み込みが完了してもキャッシュデータを保持し続け、複数のリクエストにまたがってキャッシュを再利用できる仕組みのことです。
WordPress 公式ドキュメントでは、永続オブジェクトキャッシュはWebサーバーからデータベースへの移動時間を短縮し、ページの読み込み時間を改善する手段として説明されています。キャッシュがない場合、ページビューごとにデータベースからオプションデータを読み込む必要がありますが、永続キャッシュを使えばその負荷を大幅に削減できます。
永続オブジェクトキャッシュを実現する5つのバックエンド
永続オブジェクトキャッシュを機能させるには、キャッシュデータを保存するための外部キャッシュストレージ（バックエンド）が必要です。代表的なバックエンドを以下にまとめます。
| バックエンド | 種類 | 特徴 | 公式推奨 |
|---|---|---|---|
| Redis | インメモリ KVS | 高速・多機能。レプリケーション・永続化対応。最も広く使われている | ✅ |
| Memcached | インメモリ KVS | シンプル・高速。分散キャッシュ向き | ✅ |
| APCu | PHP ユーザーキャッシュ | PHP の共有メモリを利用。共有サーバーで利用しやすい | — |
| SQLite | ファイルベース DB | Redis / Memcached が使えない環境向けの代替 | — |
| OPcache | PHP OPコードキャッシュ | PHP スクリプトのコンパイル結果をキャッシュ。Docket Cache が活用 | — |
WordPress のサイトヘルス画面では、使用しているサーバーで利用可能なキャッシュサービスが自動検出され、「お使いのホスティングサービスでは、次のオブジェクトキャッシュサービスをサポートしているようです: APCu」のように表示されます。この表示を手がかりに、どのバックエンドを利用するか判断できます。
サイトヘルスで「APCu」が検出されている画面（エックスサーバー環境）
なぜこの警告が表示されるのか
この警告はWordPress 6.1（2022年11月）から追加された「推奨」レベルの表示であり、エラーではありません。サイトの動作・表示・SEOに直接的な悪影響はないため、焦って対処する必要はありません。
WordPress 6.1 で追加された推奨項目
この推奨項目は WordPress 6.1（2022年11月リリース）から、サイトヘルスチェックに追加されました。WordPress のコアチームがデータベース負荷の軽減とパフォーマンス向上のために、永続オブジェクトキャッシュの導入を広く推奨する方針をとったことがきっかけです。
つまり、WordPress 6.0 以前を使っていた方は見たことがない表示であり、アップデート後に突然表示されて驚くケースが多いのです。私も WordPress をアップデートした直後に「え、昨日まで何もなかったのに？」と困惑した記憶があります。
すべてのサイトに表示されるわけではない
この警告は WordPress をインストールした直後には表示されません。サイトの規模がある程度大きくなった段階（投稿数やオプションデータの増加など）で初めて表示されます。具体的な閾値は公開されていませんが、数十記事以上を公開しているサイトで表示されるケースが多いようです。
重要度は「推奨」レベル ― エラーではない
「永続オブジェクトキャッシュを使用してください」は「おすすめの改善」であり、エラーや致命的な問題ではありません。サイトヘルスでの分類は「推奨」レベルです。この表示があっても、サイトの動作・表示・SEO に直接的な悪影響はありません。
対処すべき？ 判断基準チェックリスト
月間PVが数万以上、ECサイトや会員制サイト、プラグイン20個以上といった条件に該当しなければ、対処しなくても問題ありません。個人ブログや小規模サイトなら放置でOKです。
以下のチェックリストで、あなたのサイトに対処が必要かどうかを判断してみましょう。
対処したほうが良いケース
| ✓ | 該当する条件 |
|---|---|
| □ | 月間 PV が数万以上のサイト |
| □ | WooCommerce などのECサイトで動的コンテンツが多い |
| □ | 会員制サイトでログインユーザーが多い |
| □ | プラグインを20個以上使っており、データベースクエリ数が多い |
| □ | サーバーの応答速度が体感で遅いと感じている |
| □ | Query Monitor で確認したところデータベースクエリが200回以上あった |
放置しても問題ないケース
一方、以下に該当するなら無理に対処する必要はありません。個人ブログや小規模サイト、すでにページキャッシュプラグイン（WP Super Cache 等）を導入済みのサイト、PageSpeed Insights のスコアに問題がないサイト、レンタルサーバーが Redis / Memcached / APCu に対応していない環境、技術的な設定に不安がある場合――これらはいずれも放置で問題ありません。
実際の効果は？（エックスサーバーでの実測）
私のブログ（エックスサーバー・スタンダードプラン）で APCu Manager 導入前後を比較したところ、PageSpeed Insights のスコアには目立った変化はありませんでした。一方で、Query Monitor で計測するとメモリ使用量やデータベースクエリ数の改善は確認できました。体感速度への影響は限定的ですが、サーバーへの負荷軽減には確実に貢献します。
【方法①】プラグインで解決する（最も手軽）
エックスサーバーやConoHa WINGなどAPCu対応サーバーなら「APCu Manager」や「Powered Cache」、VPS/クラウド環境でRedis対応なら「Redis Object Cache」をインストールするだけで解決します。
利用しているサーバー環境で使えるバックエンドに応じて、適切なプラグインを選びます。
APCu Manager ― 最も簡単な方法（APCu 対応サーバー向け）
対象サーバー：エックスサーバー、ConoHa WING、さくらのレンタルサーバーなど、APCu が利用可能なサーバー
サイトヘルスの画面で「APCu」の名前が表示されている場合、このプラグインが使えます。私のエックスサーバー環境でもこの方法で解決しました。
導入手順（エックスサーバーでの実際の操作）
- WordPress 管理画面 →「プラグイン」→「新規追加」を開く
- キーワード検索欄に「APCu Manager」と入力して検索
- 「今すぐインストール」をクリック → 完了後「有効化」をクリック
- 有効化後、左メニューに表示される「Settings」をクリック
- 設定画面の一番上にある「Object cache」にチェックを入れる
- 他の項目はすべてチェックを外したままで問題ありません
- 最下部の「変更を保存」をクリック
APCu Manager の設定画面（Object cache にチェックを入れた状態）
これだけで完了です。サイトヘルスを再確認すると、「永続オブジェクトキャッシュを使用してください」の表示が消えているはずです。エックスサーバーでは作業時間わずか2分ほどで、特にトラブルもなく完了しました。
APCu は単一サーバー・単一プロセス向けのキャッシュです。複数サーバーで負荷分散を行っている環境では、サーバー間でキャッシュが共有されないため適しません。その場合は Redis や Memcached を検討してください。
W3 Total Cache ― 多機能キャッシュプラグイン
W3 Total Cache はオブジェクトキャッシュだけでなく、ページキャッシュ・ブラウザキャッシュ・データベースキャッシュ・CDN連携なども統合的に管理できる定番の高機能キャッシュプラグインです。
導入手順
- WordPress 管理画面 →「プラグイン」→「新規追加」
- 「W3 Total Cache」を検索 → インストール → 有効化
- 左メニュー「Performance」→「General Settings」を開く
- 「Object Cache」セクションを見つけ、「Enable」にチェックを入れる
- Object Cache Method で、サーバーが対応している方式を選択（APCu が使えるなら「Opcode: Alternative PHP Cache (APCu)」、Redis が使えるなら「Redis」、どちらも使えないなら「Disk」）
- 右上の「Save Settings」をクリック
W3 Total Cache の General Settings 画面（Object Cache セクション）
W3 Total Cache を使う場合のコツ
W3 Total Cache は非常に多機能なため、設定項目が多く初心者には少しハードルが高いです。オブジェクトキャッシュ目的だけなら、Object Cache の Enable 以外はすべてデフォルトのままで問題ありません。他の機能は必要に応じて後から有効化しましょう。
Powered Cache ― キャッシュ機能を丸ごと置き換えたい人向け
対象サーバー：エックスサーバー、ConoHa WING、さくらのレンタルサーバーなど、APCu が利用可能なサーバー
Powered Cache は日本ではまだマイナーなキャッシュプラグインですが、設定画面内に明確に「APCu」の選択肢があるのがポイントです。オブジェクトキャッシュだけでなく、ページキャッシュやブラウザキャッシュなど他のキャッシュプラグインに内包される機能も一通り備えているため、既存のキャッシュプラグインをこれ1つに置き換えたいという方に向いています。
導入手順
- WordPress 管理画面 →「プラグイン」→「新規追加」
- 「Powered Cache」を検索 → インストール → 有効化
- 左メニュー「Powered Cache」の設定画面を開く
- 「Object Cache」の項目で「APCu」を選択
- 「設定を保存」をクリック
W3 Total Cache と同様に多機能プラグインですが、設定画面がよりシンプルで直感的に操作できます。「APCu Manager だとオブジェクトキャッシュ専用すぎるし、W3 Total Cache は設定が多すぎる」という方にとって、ちょうど良い選択肢と言えます。
Powered Cache の Basic Option 画面（Object Cache セクション）
Redis Object Cache ― 本格的な高速化（Redis 対応環境向け）
対象環境：VPS、専用サーバー、Cloudways、Kinsta、KUSANAGI など Redis が利用可能な環境
導入手順
- WordPress 管理画面 →「プラグイン」→「新規追加」
- 「Redis Object Cache」を検索 → インストール → 有効化
- 左メニュー「設定」→「Redis」に移動
- 「Enable Object Cache」をクリック
- Status が「Connected」と表示されれば成功
Redis Object Cache の設定画面（Status: Connected の状態）
前提条件として、サーバー上で Redis が稼働している必要があります。共有レンタルサーバーでは Redis が利用できないことが多いため、事前にホスティング会社に確認してください。Status が「Not Connected」のままの場合、Redis サーバーが起動していないか、接続設定に問題があります。
Docket Cache ― Redis / Memcached が使えない環境の救世主
Docket Cache は、PHP の OPcache を利用して永続オブジェクトキャッシュを実現するプラグインです。Redis も Memcached も APCu も使えないレンタルサーバーでの最後の手段として検討できます。
WordPress の公式ドキュメントでも「Redis サーバーや Memcached を使用できない人のための代替オプション」として言及されています。導入はWordPress管理画面からインストール・有効化し、プラグインの設定画面でキャッシュを有効化するだけです。
LiteSpeed Cache ― LiteSpeed サーバー利用者向け
ロリポップ（ハイスピードプラン以上）などの LiteSpeed Web サーバーを搭載した環境では、LiteSpeed Cache プラグインにオブジェクトキャッシュ機能が含まれています。
ただし注意点があります。LiteSpeed Cache はオブジェクトキャッシュのバックエンドとして Memcached または Redis を利用しますが、サーバー側でこれらが有効になっていない場合、プラグインが「有効化」されてもバックエンドが実際には動作しない状態になることがあります。
たとえば mixhost では、LiteSpeed Cache のオブジェクトキャッシュ設定画面を確認すると「Memcached 拡張機能が無効」「Redis 拡張機能が無効」と表示されるケースが報告されています。
【方法②】functions.php で警告だけ非表示にする
実際にキャッシュを導入するほどではないが警告が気になる場合、子テーマの functions.php に1行追加するだけで非表示にできます。パフォーマンス改善効果はありませんが、副作用もありません。
コードの追加手順
子テーマの functions.php（または Code Snippets プラグインなど）に、以下の1行を追記してください。
|
1 |
<span style="color: #569cd6;">add_filter</span>( <span style="color: #ce9178;">'site_status_should_suggest_persistent_object_cache'</span>, <span style="color: #ce9178;">'__return_false'</span> ); |
このフィルターフックは、WordPress が永続オブジェクトキャッシュの提案を表示するかどうかを制御しています。__return_false を返すことで、提案そのものを無効化します。
この方法のメリット・デメリット
| ✅ メリット | ❌ デメリット |
|---|---|
|
1行のコードを追加するだけで完了。 プラグイン不要で副作用のリスクもない。 |
パフォーマンスの改善は一切なし。 あくまで「表示を消すだけ」の対症療法であり、根本的な解決にはならない。 |
この方法は警告メッセージを「消す」だけです。永続オブジェクトキャッシュが有効になるわけではないため、パフォーマンスの改善効果はありません。「サイトヘルスの画面をすっきりさせたい」という目的に限って使ってください。
【方法③】サーバーに Redis をインストールして本格導入する
SSH接続が可能な環境で、Redis をサーバーに直接インストールする方法です。最も高い効果が期待できますが、コマンドライン操作が必要な中〜上級者向けの手順になります。
全体の流れ
手順は大きく4つのステップに分かれます。まず WordPress に Redis Object Cache プラグインをインストールし、次に SSH でサーバーに接続して Redis をインストール・起動、プラグインから Redis への接続を確認し、最後にサーバー再起動時の自動起動を設定します。
Step 1：プラグインのインストール
WordPress 管理画面から「Redis Object Cache」をインストール・有効化し、「Enable Object Cache」をクリックします。この時点では Status が「Not Connected」と表示されますが、これは正常です。Redis がまだ起動していないためです。
Step 2：SSH でサーバーに接続し Redis を起動
|
1 2 3 4 5 6 7 8 |
<span style="color: #608b4e;"># エックスサーバーにSSH接続</span> ssh ユーザー名@サーバー名.xserver.jp -p 10022 <span style="color: #608b4e;"># Redis がインストールされているか確認</span> redis-server --version <span style="color: #608b4e;"># インストールされていない場合はソースからビルド</span> <span style="color: #608b4e;"># ※ サーバーによって手順が異なります</span> |
Step 3：Redis の起動
|
1 2 3 4 5 6 |
<span style="color: #608b4e;"># Redis をバックグラウンドで起動</span> redis-server --daemonize yes --port 6379 <span style="color: #608b4e;"># 起動確認</span> redis-cli ping <span style="color: #608b4e;"># → PONG と返ってくれば成功</span> |
エックスサーバーでのSSH接続やサーバー操作については「WP-Cronが動かない…Xserverのcronで”時間通りのメール送信”を取り戻した話」でも触れています
Step 4：自動起動の設定
レンタルサーバーでは管理者権限がないため systemctl が使えないことがほとんどです。Cron ジョブで Redis の起動を管理します。
|
1 2 3 4 5 |
<span style="color: #608b4e;"># crontab にサーバー起動時の自動起動を追加</span> crontab -e <span style="color: #608b4e;"># 以下の行を追加（5分ごとに Redis の生存確認と起動）</span> */5 * * * * pgrep redis-server || redis-server --daemonize yes --port 6379 |
Redis が正常に起動していれば、WordPress のプラグイン設定画面で Status が「Connected」に変わります。サイトヘルスの警告も消えます。
補足：エックスサーバーでプラグインなしで APCu を使う方法
エックスサーバーでは APCu が標準で利用可能です。プラグインを一切使わず、ドロップインファイルを直接配置する方法もあります。
手順は3ステップです。まず GitHub から APCu 用の object-cache.php を取得し（l3rady/WordPress-APCu-Object-Cache など）、次に wp-content/object-cache.php として配置（FTP でアップロード）し、最後に wp-config.php に以下を追記します。
|
1 |
<span style="color: #569cd6;">define</span>(<span style="color: #ce9178;">'WP_APCU_KEY_SALT'</span>, <span style="color: #ce9178;">'your-unique-salt-here'</span>); |
この方法はプラグインの管理画面が不要な分シンプルですが、手動での管理が必要です。エックスサーバーで「プラグインを増やしたくない」という方にはおすすめですが、初心者の方には前述の APCu Manager プラグインの方が安全です。
レンタルサーバー別 対応早見表
日本で人気の主要レンタルサーバーごとに、利用可能なバックエンドと推奨対処法を一覧表にまとめました。自分のサーバーに該当する行を見れば、最適な方法がすぐにわかります。
| レンタルサーバー | 利用可能バックエンド | 推奨対処法 |
|---|---|---|
| エックスサーバー | APCu ✅ | APCu Manager / Powered Cache / W3 Total Cache （実証済み） |
| ConoHa WING | APCu ✅ | APCu Manager |
| さくらのレンタルサーバー | APCu（プランによる） | APCu Manager |
| ロリポップ | ❌ 非対応 | functions.php で非表示 / LiteSpeed Cache |
| mixhost | ❌ 非対応 | functions.php で非表示 / Docket Cache |
| Cloudways | Redis ✅ | Redis Object Cache |
| Kinsta | Redis ✅ | Redis Object Cache |
| KUSANAGI | Redis / Memcached ✅ | Redis Object Cache（bcache 競合注意） |
主要サーバーの補足情報
エックスサーバーの場合（実体験）
エックスサーバーでは APCu が標準で有効になっています。私のブログでも APCu Manager プラグインを使って2分ほどで設定完了しました。スタンダードプラン以上であれば問題なく動作します。SSH接続が可能なプランであれば、前述のRedisインストールやドロップインファイルによる方法も選択肢に入ります。
ロリポップの場合
ロリポップの公式サポートでは「永続オブジェクトキャッシュは使用できない」と明記されています。代替として「ロリポップ！アクセラレータ」や「LiteSpeed Cache」の利用が案内されています。ハイスピードプラン以上であれば LiteSpeed Cache が利用可能です。
mixhost の場合
mixhost では Memcached と Redis がともに無効化されているため、実質的に永続オブジェクトキャッシュは利用できません。LiteSpeed Cache をインストールしても、バックエンドが動作しないため実際のキャッシュ効果は得られません。functions.php での非表示が現実的な対処法です。
KUSANAGI の場合
KUSANAGI は独自の bcache（ページキャッシュ）を備えています。永続オブジェクトキャッシュのプラグインを追加すると bcache と競合する可能性があるため、安易な導入は推奨されていません。まずは kusanagi dbinit コマンドでデータベースキャッシュサイズを再設定し、ボトルネックを特定するのが先です。
導入時の注意点とリスク
永続オブジェクトキャッシュの導入には「キャッシュの不整合」「プラグイン競合」「データリーク」「逆に遅くなる」という4つのリスクがあります。導入前のバックアップと導入後のパフォーマンス計測は必須です。
① キャッシュの不整合（古い情報が表示される）
オブジェクトキャッシュを有効にすると、キャッシュされた古いデータがそのまま表示される可能性があります。記事を更新しても反映されない、設定を変更しても画面に反映されないといった現象が起きた場合は、プラグインの管理画面からキャッシュのフラッシュ（クリア）を行ってください。
WordPressのキャッシュ関連トラブルについては「WordPressでCSS更新が反映されない｜キャッシュ5層の切り分け」で詳しく解説しています
② プラグインの競合
複数のキャッシュ系プラグインを同時に有効化してはいけません。たとえば、APCu Manager と W3 Total Cache のオブジェクトキャッシュを同時に有効にすると、競合が発生してサイトが正常に動作しなくなることがあります。オブジェクトキャッシュ系のプラグインは必ず1つだけに絞りましょう。
③ データリークのリスク
これは特に EC サイトや会員制サイトで重要です。オブジェクトキャッシュの設定を誤ると、あるユーザーに別のユーザーの個人情報が表示される「データリーク」が発生するリスクがあります。大規模なオンラインショップでこの事故が発生した実例も報告されています。
EC サイトや会員制サイトでオブジェクトキャッシュを導入する場合は、必ずテスト環境で十分に検証してから本番環境に反映してください。ログインユーザーが異なるデータを閲覧できてしまわないか、慎重に確認する必要があります。
④ 逆にサイトが遅くなるケース
一部のプラグインがオブジェクトキャッシュとの相性が悪く、導入前よりもサイトが遅くなるケースが報告されています。導入後は必ずパフォーマンスを計測し、問題があればプラグインを速やかに無効化してください。
⑤ 導入前後の確認チェックリスト
| タイミング | 確認項目 |
|---|---|
| 導入前 | PageSpeed Insights のスコアを記録 / Query Monitor でデータベースクエリ数・メモリ使用量を計測 / サイトのバックアップを取得 |
| 導入後 | 同条件で再計測し、改善されているか比較 / サイトの各ページが正常に表示されるか確認 / ログイン状態で異常がないか確認 |
| 問題発生時 | プラグインを無効化 / wp-content/object-cache.php を削除（FTP接続） / 必要に応じてバックアップから復元 |
まとめ：あなたに最適な対処法はこれだ
エックスサーバー・ConoHa WINGユーザーは「APCu Manager」か「Powered Cache」が手軽。非対応サーバーなら「functions.phpで非表示」が最も現実的。本格的な高速化が必要なVPS/クラウド環境なら「Redis Object Cache」を導入しましょう。
WordPress サイトヘルスの「永続オブジェクトキャッシュを使用してください」は、WordPress 6.1 以降に追加された推奨項目です。対処しなくてもサイトの動作に支障はありませんが、対処すればサーバー負荷の軽減やデータベースクエリの削減に貢献します。
あなたの状況に合わせて、以下のフローチャートで最適な方法を選んでみてください。
対処法フローチャート
Q1. サイトの表示速度に不満がある？
→ NO：放置でOK（または functions.php で警告非表示）
→ YES：Q2 へ
Q2. サーバーは Redis / Memcached に対応している？
→ YES：Redis Object Cache プラグインを導入
→ NO：Q3 へ
Q3. サーバーは APCu に対応している？（サイトヘルスで確認）
→ YES：APCu Manager または Powered Cache プラグインを導入
→ NO：Docket Cache を検討、または functions.php で警告非表示
対処法まとめ一覧
| 目的 | 方法 | 難易度 | 効果 |
|---|---|---|---|
| 手軽に対応したい | APCu Manager / Powered Cache / W3 Total Cache | ⭐ | ⭐⭐ |
| 警告を消したいだけ | functions.php にフィルター追加 | ⭐ | — |
| 本格的に高速化したい | Redis + Redis Object Cache | ⭐⭐⭐ | ⭐⭐⭐ |
| サーバーが対応していない | Docket Cache / 放置 | ⭐ | ⭐ |
いずれの方法をとる場合も、導入前後でのパフォーマンス計測を忘れずに行いましょう。問題が発生したらすぐに元に戻せるように、事前のバックアップも忘れずに。
サイトヘルスの警告は気になるものですが、過度に恐れる必要はありません。この記事を参考に、あなたのサイトに合った最適な方法で対処してみてください。
コメント