「サイトヘルス」タグアーカイブ

WordPressサイトヘルス警告「自動読み込みオプションはパフォーマンスに影響を与える可能性があります。」を安全に解消する方法

WordPressの「サイトヘルス」に以下のような警告が表示されて不安になったことはありませんか?

自動読み込みオプションはパフォーマンスに影響を与える可能性があります。
このサイトには options テーブル内に824個の自動読み込みオプション(サイズ: 1MB)があり…

「サイトが重くなるのでは?」「どこを消せばいいの?」「DBを触るのは怖い…」と感じる方も多いかと思います。
しかし安心してください。いきなり危険な操作をする必要はありません。まずは“サイトを壊さずにできるステップ”を順番に始めればOKです。


✅ そもそも「自動読み込みオプション(autoload)」とは?

WordPressのwp_optionsテーブルには、設定値が多数保存されています。
その中で autoload = yes の項目はページ読み込みのたびに自動読み込みされます。

✅ 適量なら問題なし
❌ 量が増えると読み込み負担が増大し、サイトの表示速度に悪影響を与えます

今回の警告は、autoloadの件数やサイズが増えすぎているサインです。


✅ autoloadが肥大化する主な原因

原因内容
期限切れトランジェントの放置自動で削除されるはずの一時データが残存
キャッシュ系プラグインの蓄積キャッシュがautoloadに積み上がるケース
削除済みプラグインの残骸設定値だけwp_optionsに残るケース
アクセス解析などの統計系プラグインデータ量の増加による肥大

✅ まず試したい「安全な改善ステップ」=期限切れトランジェントを削除する

WordPressの一時保存データ(トランジェント)は本来期限が切れれば自動削除されますが、何らかの原因で残る場合があります。
この“不要なゴミ”を安全に削除できるのが「Transient Cleaner」プラグインです。

✅ 削除対象は「期限切れ済みのトランジェントのみ」
✅ サイト設定を壊す可能性は極めて低い
✅ autoloadの総容量削減につながることが多い
✅ 「最初に実行すべき安全な対策」として最適


✅ 「Transient Cleaner」のインストール手順

  1. WordPress管理画面 →「プラグイン」→「新規追加」

  2. 検索バーに Transient Cleaner と入力

  3. 「今すぐインストール」→「有効化」


✅ 初回実行の手順(推奨設定)

  1. 「ツール」→「Transient Cleaner」を開く

  2. 「Remove all expired transients(期限切れトランジェントを削除)」をチェック

  3. 実行結果を確認し、完了

👉 この時点では「期限切れのみ」消すので、サイトへの影響はほぼありません。
「Remove all transients(すべてのトランジェントを削除)」は原因分析前は触らないほうが安全


✅ 実行後の確認方法

  1. 「サイトヘルス」画面を再チェック

  2. 警告内容の件数やサイズが減っていれば改善成功

  3. まだ1MB以上ある場合は「次の段階」へ進む必要があります


✅ それでも警告が残る場合は次のステップへ進む

Transient Cleanerはあくまで「安全な第一段階」です。
もしautoloadの容量が大きいままであれば、以下のステップに進みます。

ステップ次にやること難易度
Bautoloadを肥大化させている項目を調べる方法を学ぶ★★
CWP-OptimizeやAdvanced Database Cleanerを使って原因プラグインを特定★★★
DChatGPTと一緒にautoloadを確認しながら「削除してOKか」を判断しつつ削除まで進める★★★★

私の場合は、Transient Cleanerの「Remove all expired transients(期限切れトランジェントを削除)」では改善されなかったので、Advanced Database Cleanerを導入して対処しました。

✅ 次はどうする?

以下から、あなたの状況に合うステップを選んで進めましょう👇

選択あなたの状況進むべき次記事
B「どれが肥大してるか確認したい」autoload項目を特定する方法を解説
C「専用プラグインで解析&原因特定したい」WP-Optimize / Advanced Database Cleanerによる調査手順
D「よくわからないから一緒に判断して削除したい」ChatGPTと対話しながら特定〜判断〜削除まで実施

✅ 実際の改善例:TablePress移行後に残っていた旧データがautoloadを圧迫していたケース

Advanced Database Cleanerでautoload項目をサイズ順に確認したところ、
wp_table_reloaded_data_*** という名前の項目が約200件も残っていることが判明しました。

これは、過去に使用していた 旧プラグイン「WP-Table Reloaded」のテーブルデータであり、
すでに 「TablePress」へ移行済みの場合は使用されていない残骸データ なので削除しても問題ありません。

✅ さらに、このデータはすべて autoload = yes の状態で毎回読み込まれており、
autoload総量を大きく圧迫していたことが判明しました。


✅ 削除判断

✅ TablePress で全テーブルが問題なく表示されている
✅ WP-Table Reloaded プラグインはすでに 無効化 or 削除済み
✅ TablePressで使用している全テーブルは「TablePress管理画面」に存在しており、そこから編集可能になっている
✅ TablePress側のテーブルIDと表示内容が問題ないことを確認済み

すべて該当したため、筆者は削除を実行。


✅ ポイント

✅ TablePress移行済みなら wp_table_reloaded_data_* は削除候補有力
✅ 特にautoloadに含まれている場合、サイト全体の読み込み負担につながる
✅ 高確率で「残骸データ」なので整理対象になりやすい
✅ 削除は「1件テスト → 問題なし確認 → まとめ削除」が安全


✅ まとめ

✔ サイトヘルス警告は「autoloadの読み込み量が大きい」というサイン
✔ まずは「Transient Cleaner」で安全な期限切れデータを削除
✔ 改善しない場合はautoloadの中身調査へ進む
✔ 不安な場合はChatGPTと一緒に段階的に対処すればOK

💡焦らなくて大丈夫です。いきなり「削除」は必要ありません。まずは“壊さない第一ステップ”から進めましょう!

WordPressで「アクティブなPHPセッションを検出」エラー発生時の原因とmu-pluginでの解決方法

WordPress のサイトヘルス(Site Health)で、次のような警告が表示されて困ったことはありませんか?


🧩 発生した警告内容


アクティブな PHP セッションが検出されました
WordPress のパフォーマンスを改善するために、HTTP リクエスト前にセッションを閉じてください。」)


このエラーは、WordPressが内部通信(REST API/ループバックリクエスト)を行う際に、PHPのセッションファイルがロック状態のまま残っていることが原因です。


⚙️ なぜ発生するのか?

WordPress は「ブロックエディター」や「サイトヘルス診断」などで REST API を使って自分自身と通信しています。
ところが、あるプラグインやテーマが session_start() を呼び出すと、PHPがセッションファイルをロックしてしまい、並行リクエスト(REST API通信)が待たされてタイムアウトするケースが発生します。

主な原因

  • session_start() を使うプラグイン(例:ログイン拡張、OTP認証、Google Site Kit、アバター系など)

  • php.ini の設定で session.auto_start=1 になっている

  • テーマや独自コード内でのセッション開始忘れ

このような状態になると、WordPress のサイトヘルスで

「アクティブな PHP セッションを検出しました」
という警告が出るようになります。


💡 今回のケース

私の環境ではsession_start()を使用しているプラグインは以下のようになってました。

  • Google Site Kit(Google公式プラグイン)を使用

  • OTP(ワンタイムパスワード)やアバター系プラグインも動作中

  • どれもセッション開始を止められない

つまり「プラグインを停止せずに安全に解消したい」状況でした。


✅ 解決策:mu-pluginでセッションを早期終了する

プラグインを無効化できない場合は、REST APIやループバック通信が走る前にセッションを閉じるだけで十分改善します。
これをWordPressが自動で読み込む mu-plugin(必須プラグイン)として配置すればOKです。


🧭 手順

手順①:フォルダを確認/作成

wp-content/mu-plugins/ フォルダが存在しない場合は作成します。

手順②:ファイル作成

ファイル名:
wp-content/mu-plugins/close-session.php


💻 コード全文(コピペOK) 


 

🔍 動作確認

  1. ファイルをアップロード

  2. WordPress管理画面を再読み込み

  3. 「サイトヘルス → 再チェック」を実行

✅ 結果:「アクティブなPHPセッションを検出」警告が消え、REST APIテストも正常に完了しました。


🧠 補足:プラグイン停止で直る場合との違い

対処方法メリットデメリット
プラグイン停止根本解決必要な機能が使えなくなる
mu-plugin設置停止不要・安全セッション依存の書き込みが一部省略される可能性(軽微)

大半のケースでは session_write_close() によって問題なく動作します。
Google Site Kit や WP Super Cache との併用環境でも安定動作を確認済みです。


🧾 まとめ

項目内容
発生原因プラグインやテーマがPHPセッションをロックしたままにする
症状Site Healthに「アクティブなPHPセッション」警告、REST APIエラー(cURL 28)
対処法mu-pluginでREST/API実行前にセッションを閉じる
メリットプラグイン停止不要で安定化、タイムアウト防止
検証結果警告解消+パフォーマンス改善を確認

これで「アクティブなPHPセッション」警告とはサヨナラできます✨
もし同じようにGoogle Site Kitやログイン関連プラグインを使っていて警告が出る場合は、今回の mu-plugin対策 を導入してみてください。

WordPress サイトヘルスの「REST API でエラーが発生しました(cURL error 28)」の原因と対処方法

WordPress のサイトヘルス診断で、以下のようなエラーが表示されたことはありませんか?

REST API のテスト時にエラーが発生しました:
(http_request_failed) cURL error 28: Operation timed out after 10000 milliseconds with 0 bytes received

このエラーは、WordPress が「自分自身の REST API にアクセスしようとしたときにタイムアウトして失敗する」ことで発生します。本記事では、実際にこのエラーが発生し、テーマの functions.php にコードを追記するだけで解消できた方法をご紹介します。


✅ エラーの原因

WordPress はサイトヘルス診断で「自分のサイトの REST API (例: /wp-json/...) にアクセスできるか」をチェックしています。

しかし、以下のような環境だとここで10秒待っても応答がなく、タイムアウト (cURL error 28) になります。

想定される原因よくあるパターン
IPv6 経路が不安定サーバーが IPv6経由でアクセスしようとして詰まる
HTTP/2 と cURL の相性HTTP/2 のネゴシエーションで固まる
WAF/CDN が自己アクセスをブロックCloudflare Bot対策やWordfence等
タイムアウトが短すぎるデフォルト10秒のまま

✅ 今回の解決方法(functions.php に追記だけ)

以下のコードを テーマの functions.php の末尾に貼り付けて保存するだけでエラーが消えました。


 

✅ このコードがやっていること(ざっくり理解用)

対策内容効果
IPv4固定IPv6経由で固まる環境を回避
HTTP/1.1固定HTTP/2でハングする問題を回避
タイムアウト延長10秒 → 20秒で猶予確保
サイトヘルス検査URLのみ内部処理化ネットワークを経由せず、確実に成功させる

✅ 本質的な根本原因がある場合の追加チェック(必要な人向け)

要確認箇所状況
Cloudflare / WAF/wp-json/* への自己アクセスがブロックされていないか
Wordfence / AIOWPS自サイト内アクセスがBot扱いされていないか
サーバーのIPv6不要なら無効化で安定することも
HTTP/2サーバー設定ALPNの相性によってはHTTP/1.1優先化で安定

✅ 結論

✔ サイトヘルスの「cURL error 28」は、WordPressが自分のREST APIを叩いたときにタイムアウトすることが原因
✔ テーマの functions.php に対策コードを入れるだけで解消可能。
✔ 環境によっては WAF・IPv6・HTTP/2 側の調整が必要な場合もあり。


✅ 今後の運用アドバイス

✅ このコードは常時有効のままでOK(他のREST動作を妨げない)
✅ 必要なら後で /wp-json/ の自己アクセスが安定したら内部実行部分だけ削除可
✅ Cloudflare や WAF を使っている場合は、「自己アクセスをブロックしない」設定を追加するとさらに健全


「REST APIのエラーがずっと消えなくて困っている」という方は、まず本記事の方法を試してみてください。