WordPress が 6.1 になったことだし、サイトヘルスを確認したら次のお勧め改善が表示されていたから改善してみる。
永続オブジェクトキャッシュを使用してください
ページキャッシュは検出されませんでしたが、サーバーのレスポンスは良好です
永続オブジェクトキャッシュを使用してください
Redis のインストール
次のサイトを参考に Redis をインストールする。専用の仮想マシンを用意しても良いけど、とりあえず公開 Web Server と同じ仮想マシンで 127.0.0.1:6379 に接続することにした。
プラグイン Redis Object Cache のインストール
WordPress の管理画面から Redis Object Cache をインストールして有効化、Redis Object Cache の設定画面で Enable Object Cache をクリック。
これで１つ目のお勧め改善は終了。
ページキャッシュは検出されませんでしたが、サーバーのレスポンスは良好です
もともと SWELL には独自のキャッシュ機能が備わっているからキャッシュ系のプラグインは不要。
それでも、"とりあえず"サイトヘルスステータスからメッセージを消すために WP Super Cache をインストールして有効化した。
結果
サイトヘルスの結果は"すばらしい！"になった。
PageSpeed Insights の結果は改善前後でいまのところ変化なし。そのうちキャッシュがきいてくるだろうか？
問題
Redis Object Cache
カレンダーが１月に固定されてしまい、「今日」を表示しなくなる。カレンダーが不要な場合は無関係だけど。
ということでプラグインを削除する。
WP Super Cache
WP Super Cache を有効化すると、設定画面で wp-cron が停止しているというメッセージが出る。
CRON システムは停止中
WordPress CRON ジョブシステムは停止しています。ガベージコレクションシステムは手動で CRON システムを動かさない限り動作しません。
wp-cron.php はシステムの cron で動作させているから、「手動で CRON システムを動かせばガベージコレクションシステムは動作する」ということ。ならメッセージは放置でいい。
でも、SWELL の高速化で何も不満はないから、WP Super Cache も削除して WordPress のサイトヘルスお勧め改善は無視することにした。
・・・お勧めか？
後日談
やっぱりサイトヘルスにメッセージが出るのは気持ち悪いから方針変更。
永続オブジェクトキャッシュについて
カレンダーウィジェットをなくして Redis を有効化することにした。
なお、同一サーバーで複数の WordPress を運用している場合は、それぞれの database の prefix を異なるものにすること。でないとそれぞれの WordPress の動作がおかしくなる。
WordPress プラグインは Redis Object Cache を削除、サーバーに apt install php-redis で php 拡張モジュールをインストールして、W3 Total Cache で運用することにした。
ページキャッシュについて
wp-cron.php に影響のない W3 Total Cache をインストールした。
ただし、SWELL のキャッシュと重複するから最低限の設定。
コメント