WordPressのダッシュボードでサイトヘルスという項目があり赤①がついてました。
見てみると以下の問題が起きていました。
1件の致命的な問題
・ページキャッシュが検出されず、サーバーのレスポンスが遅くなっています
4件のおすすめの改善
1、停止中のテーマを削除してください
2、REST API で予期しない結果が発生しました
3、永続オブジェクトキャッシュを使用してください
4、サイトでループバックリクエストが完了できませんでした
対策した方法をご紹介します。
なお当ブログは一般的なレンタルサーバーではなくVPSを使ってます。
詳細は↓
2024/4お名前.comのレンタルサーバーからVPSへ移行したときの記録になります。
ページキャッシュが検出されず、サーバーのレスポンスが遅くなっています（パフォーマンス）
パフォーマンスをクリックすると
ページキャッシュは、ユーザーがアクセスするたびにページを読み込むのではなく、静的なページを保存して提供することで、サイトの速度とパフォーマンスを向上させます。
ページキャッシュの検出は、有効化されたページキャッシュプラグインの検索のほか、ホームページへのリクエストを3回行い、以下のHTTPクライアントキャッシュレスポンスヘッダーのうち1つ以上の検索で行います:cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status.
・サーバーの応答時間の中央値は1,110ミリ秒でした。推奨されるしきい値600ミリ秒以下の時間でなければなりません。
・クライアントキャッシュレスポンスヘッダーを検出できませんでした。
・ページキャッシュプラグインは検出されませんでした。
私のVPSで構築した環境はDockerでNginx（Modesecurity付き）+WordPress（Nginx）です。
クライアントのリクエストを前段のNginxで受けてWordPressのNginxに渡す構成になっています。
こちら↓に書きましたがNginxと後段のNginxでデータ送受信するときに
バッファがいっぱいになって一時的にファイルに書き込むような処理が行われてます。
なのでスピードを重視したページキャッシュにするなら前段のNginxで
静的ファイルをキャッシュする形がいいと思います。
しかし難しくて失敗しそうなのでWordPressのプラグイン（WP Super Cache）で対応することにしました。
その結果WordPressのヘルスチェックはクリアしたけど表示スピードは
変わらないか、メモリに余裕がないから遅くなってるかもしれません。
目次へ
対策→WP Super Cache導入
対策前PageSpeed Insightsは携帯で55、デスクトップで93
WordPressのプラグインWP Super Cacheを使うことにした。
WordPressダッシュボードにログイン→「プラグイン」->「新規追加」
→「WP Super Cache」を検索し、「今すぐインストール」をクリック
→インストール後、「有効化」をクリック
プラグインに戻ってWP Super Cacheの設定をクリックするとエラーがいっぱい出た。
Error: Configuration file /var/www/html/wp-content/wp-cache-config.php is missing. Please reload the page.
→以下の対策をしているうちに消えた。
具体的にはwp-contentのパーミッションを一時的に変更（後述）
CRON システムは停止中
WordPress CRON ジョブシステムは停止しています。ガベージコレクションシステムは手動で CRON システムを動かさない限り動作しません。
→別件↓でWP-Cronは停止させたので、それを検出してると思われる。このまま。
警告! /var/www/html/wp-config.php を更新できません! 構成ファイルで WPCACHEHOME を設定する必要があります。
→Nginxの以下の設定で、このファイルへのアクセスを拒否してるので
一旦コメントアウト（自分で拒否するように設定していた。）
location ~ /(xmlrpc\.php|wp-config\.php|wlwmanifest\.xml|license\.txt|readme\.html|wp-config-sample\.php) {
deny all;
return 403;
}
WordPressのコンテナの中に入って
現状確認→644だった。
ls -l
-rw-r--r-- 1 1001 1001 5681 Apr 2 04:34 wp-config.php
chmod 646 /var/www/html/wp-config.phpを実行
Nginxの設定更新
sudo docker restart コンテナ名警告! /var/www/html/wp-content/advanced-cache.php を更新できません。
ftp やサーバーソフトウェアで chmod コマンドを使用して /var/www/html/wp-content を書き込み可能にし (chmod 777 /var/www/html/wp-content)、次にこのページを再読込みします。これは一時的な処理で、この後、再度読み込みのみの設定 に戻す必要があります (前述のコマンドで 777 を 755 に変更します)。
このページを再読込みして /var/www/html/wp-content/advanced-cache.php を更新します。
もし動作しなければ /var/www/html/wp-content/advanced-cache.php ファイルが存在するか確認してください
→WordPressのコンテナの中に入って設定値確認
ls -lで見ると現状755
drwxr-xr-x 14 www-data www-data 4096 May 26 06:14 wp-content
chmod 777 /var/www/html/wp-contentを実行
drwxrwxrwx 14 www-data www-data 4096 May 26 06:14 wp-content
参考：https://enjoy-pcworks.com/infotech/wordpress/518
WP Super Cacheの設定ができるようになったら、
今、変更した設定はすべて戻しても問題なかったので戻した。
Nginxの設定でwp-config.phpをアクセス拒否に戻し（私の場合）
WordPressのコンテナの中に入って
chmod 644 /var/www/html/wp-config.php
chmod 755 /var/www/html/wp-content
Nginxの設定更新
sudo docker restart コンテナ名
で戻した。以上対策で簡単設定の画面が表示されました。
- 「キャッシング利用（推奨）」
- 「ステータスを更新」
これでサイトヘルス良好になりました。
その後、少し設定値をいじって。
PageSpeed Insightsは携帯で50、デスクトップで81と前より悪くなってますが
PageSpeed Insightsは、ばらつきが大きいので参考程度に。
でも、極端によくはなっていないことは確かだと思います。
サイトヘルスのテスト通過の「ページキャッシュが検出され、サーバーのレスポンスは良好です」を開いて見ると合格した理由がかいてありました。
- サーバーのレスポンスの中央値は382ミリ秒でした。推奨される600ミリ秒のしきい値を下回っています。
- 1個のクライアントキャッシュレスポンスヘッダーを検出しました:
cache-control. - ページキャッシュプラグインを検出しました。
上記、青下線のサーバーレスポンスは測り方が、どういうものか未調査だが
私の環境の実態にあっていない感じがしてます。
表示スピードの改善には、WP Super Cacheの設定値の調整や根本的な見直しが必要と考えます。
取り合えず、このまま運用して暇なときに見てみようと思ってます。
目次へ
停止中のテーマを削除してください（セキュリティ）
テーマはサイトのデザインを決定します。ブランドの一貫性とサイトの安全性の維持のため、常に更新することが重要です。
サイトのインストール済みテーマ5個はすべて最新版です。
サイトには2個の停止中のテーマがあります。 サイトのセキュリティ向上のため未使用のテーマの削除を検討してください。WordPress のデフォルトテーマ Twenty Twenty-Four(2025/2/6追記Twenty-Fourは削除してTwenty-Fiveのみ残した)、現在有効なテーマ Cocoon Child、親テーマ Cocoon は削除しないでください。
対策→不要なテーマ削除
Twenty Twenty-Three とTwenty Twenty-Two を削除した。
Twenty Twenty-Fourは消さない。
外観→テーマで対象のテーマをクリックすると削除が選択できます。
目次へ
REST API で予期しない結果が発生しました（パフォーマンス）
REST API は WordPress や他のアプリケーションがサーバーと通信する手段の1つです。たとえば、ブロックエディターの画面は投稿や固定ページの表示や保存のために REST API を使用しています。
REST API のテスト時に、予期しない結果が返されました:
REST API エンドポイント: https://kikuichige.com/wp-json/wp/v2/types/post?context=edit
REST API レスポンス: (403) Forbidden
対策→Nginxでアクセス拒否していたものを許可
エラーログで/wp-json/wp/v2/types/post?context=editで検索してみると
Nginx（Modesecurity）でアクセス拒否されてた。
そういえば自分以外のIPは/wp-json以下のアクセス拒否に設定していた。
そこで拒否されてるIP（ループバックアドレス）をNginx（Modesecurity）でアクセス許可した。永続オブジェクトキャッシュを使用してください（パフォーマンス）
永続オブジェクトキャッシュは、サイトのデータベースの効率を上げます。その結果、WordPress がサイトのコンテンツや設定を迅速に取得できるようになるため、読み込み時間を短縮できます。
ホスティングサービスに問い合わせれば、サイトで永続オブジェクトキャッシュを有効化できるかどうかがわかります。
未対策。
致命的な問題ではないし。
ちょっと調べるとキャッシュサーバーを使う必要がありそう。
VPSのメモリ使用量が気になるので、あまりポンポン処理を追加したくないため放置してます。
さらに以下Geminiに聞いたが、VPSのメモリ1Gでは、逆効果になりそうなので止めた。
プロンプト：
以下のようにnginxのコンテナのうしろでWordPressのコンテナを動かしている。WordPressのヘルスチェックで「永続オブジェクトキャッシュを使用してください」と出る。Redis（レディス）を導入した場合のデメリットは？コンテナを増やすことで逆にメモリ使用量が増えるとか？ちなみに今1Gのメモリでnginxのコンテナ、Django複数とWordPress関係のコンテナ合わせて全部で7個稼働中です。さらにRedisが増えても大丈夫か
docker-compose.yml
wp_first:
image: wordpress:php8.3-fpm-alpine
volumes:
– ./html:/var/www/html
depends_on:
– db
nginxのconfファイル
location / {
try_files $uri $uri/ /index.php$is_args$args;
}
location ~ .php$ {
fastcgi_pass wp_fastcgi_passes;
fastcgi_index index.php;
include fastcgi_params;
Geminiの回答
1GBの限られたメモリ環境で、すでに7個ものコンテナ（Nginx、Django複数、WordPress、DBなど）をやりくりされているのは、かなり上手にリソースを管理されていますね！
結論から言うと、Redisコンテナを追加することは可能ですが、1GBメモリの状況を考えると、何も対策せずに入れるのは少しリスクがあります（メモリ不足で既存のDjangoやWordPressが落ちる可能性があります）。
Redisを導入するデメリットや、現在の環境で安全に導入するためのポイントを整理しました。
Redisを導入するデメリットとメモリへの影響
1. メモリ使用量は「確実に」増える（最大の懸念点）
ご想像の通り、コンテナが増える（プロセスが増える）分、ベースのメモリ消費が上がります。
- 起動直後: Redis自体は非常に軽量なため、中身が空なら 30MB〜50MB 程度しか消費しません。
- 運用中: Redisはすべてのキャッシュデータをメモリ上に保持する仕組みです。WordPressのプラグイン（Redis Object Cacheなど）を入れて運用を始めると、記事数やアクセス数に応じて、100MB、200MBとメモリを消費していきます。
2. 現在の「1GBで7コンテナ」はかなりギリギリ
すでにWordPress（PHP-FPM）、Django（Pythonプロセス×複数）、MySQL/MariaDBなどのデータベースが動いている状態です。
PHPやPython、DBはアクセスが集中した瞬間にメモリ使用量が跳ね上がる特性があるため、現状でも空きメモリ（Buffer/Cacheを除くFree領域）は残り少ないはずです。ここに制限なしでRedisを入れると、メモリ上限に達してOSの OOM Killer が作動し、一番重いDBコンテナやDjangoコンテナが強制終了させられるリスクがあります。
3. 管理の手間（プラグインの導入と運用）
WordPress側に「Redis Object Cache」などのプラグインを入れる必要があります。また、WordPress側で記事を更新したのに古いキャッシュが残って表示が変わらない、といったキャッシュ特有のトラブル対応がたまに発生します。
それでも「永続オブジェクトキャッシュ」を入れるメリットはある？
WordPressのヘルスチェックがこれを推奨するのは、データベース（MySQL）の負荷を劇的に減らせるからです。
WordPressはページを1枚表示するたびに、同じようなSQLクエリを何度もDBに投げます。Redisを入れると、その結果をメモリに保存（キャッシュ）しておくため、2回目以降のアクセスが高速になり、DBコンテナのCPU・メモリ負荷が下がります。
対策：この環境で安全にRedisを導入する方法
もしヘルスチェックの警告を消し、サイトを高速化するためにRedisを入れるなら、docker-compose.ymlでRedisのメモリ使用量に「絶対的な上限」をかける設定が必須です。
以下のように、Redisコンテナの設定で最大メモリを「64MB」などに制限し、溢れたら古いキャッシュから消す設定（volatile-lru または allkeys-lru）に指定すれば、1GBの環境でも安全に共存できます。
docker-compose.yml への追加例
YAML
redis:
image: redis:7-alpine
command: redis-server --maxmemory 64mb --maxmemory-policy allkeys-lru
# コンテナ自体のメモリ上限も設定しておくとより安全です
deploy:
resources:
limits:
memory: 96m
--maxmemory 64mb: Redisが使うキャッシュの上限を64MBに縛ります（これ以上は増えません）。--maxmemory-policy allkeys-lru: 64MBに達したら、使われていない古いキャッシュから自動で削除して隙間を作ります。
結論：どうするべきか？
- 現状、サイトの重さに不満がない場合ヘルスチェックの警告は「おすすめ」程度のもので、必須エラーではありません。1GBメモリを限界まで攻めるリスクを避けるため、今回は見送る（Redisは入れない） のが一番安全です。
- WordPressの表示を速くしたい・DB負荷を下げたい場合上記の通り 「メモリ上限（64MB等）を厳しく設定したRedis」 を導入してください。導入後は、サーバー内で
free -mコマンドなどを叩き、全体の空きメモリに余裕があるか（Swapが激しく発生していないか）を確認することをおすすめします。
予約したイベントが遅れています（パフォーマンス）
予約したイベント puc_cron_check_updates_theme-wp-cocoon-theme の実行が遅延しています。サイトは動作しますが、予約した投稿や自動更新は正しく動作しないかもしれません。
対策→Nginxでアクセス拒否したいたものを許可
恐らくこのアクセスがNginx（Modesecurity）で拒否されているのが原因。
access forbidden by rule, client: IP（ループバックアドレス）, server: kikuichige.com, request: "POST /wp-cron.php HTTP/1.1"
これも/wp-jsonと同じく、自分以外のIPは/wp-cron.phpへアクセス拒否に設定していた。
そこで拒否されてるIP（ループバックアドレス）をNginx（Modesecurity）でアクセス許可した。サイトでループバックリクエストが完了できませんでした（パフォーマンス）
ループバックリクエストは予約イベントの実行に使用されます。またテーマやプラグインの組み込みエディターでは、コードの安定性の確認に使用されます。ループバックリクエストは予期しない HTTP ステータスコード 403 を返しました。これが機能の想定どおりの動作を妨げてるかは判断できませんでした。
対策→他の対策で改善された
上で実行したどちらかの対策が効いた。
「REST API で予期しない結果が発生しました」の対策
/wp-jsonにIP（ループバックアドレス）のアクセス許可
「サイトでループバックリクエストが完了できませんでした」の対策
/wp-cron.phpにIP（ループバックアドレス）のアクセス許可
所感
今回とったページキャッシュのやり方は、WP Super Cache導入にしたが
私の環境ではベストな選択肢ではない気がしています。
WP Super Cache設定で改善できる可能性も0ではないので
おいおい調べていきます。
イチゲをOFUSEで応援する(御質問でもOKです）Vプリカでのお支払いがおすすめです。
MENTAやってます（ichige）
目次へ
