WordPressの管理画面だけが遅いとき｜操作・通信・サーバーを切り分ける

WordPressの管理画面が遅くても、公開ページの画像圧縮だけでは解決しないことがあります。一覧を開く、編集画面を表示する、保存するという操作を分け、どの条件で待つのかを記録するのが出発点です。

この記事では、企業の更新担当者が安全に集められる情報と、制作担当が調べる通信・処理を分けます。特定のプラグインやホストを原因と決めつけず、原稿を守りながら、変更後も編集と保存が続く状態を確認します。

1. 公開ページと管理画面、表示と保存を分ける

最初に「サイト全体が遅い」から一歩進めて、待っている操作を一つ選びます。公開ページは快適でも、ログイン後の一覧や編集処理だけが遅い場合があります。反対に、管理画面へ入る前から通信が遅いなら、回線や接続先も比較対象です。

管理画面の待ち時間を、公開ページのCore Web Vitalsの結果だけで説明しないでください。必要な確認が違います。ページが表示されず受付にも影響する場合は、通常の速度改善よりサイト停止時の初動確認を優先します。

2. 編集者がそろえる再現条件

大きな設定を変える前に、同じ操作を限られた回数で確かめます。誰が、いつ、どの端末と回線で、何を押したかを残してください。「昨日から遅い」なら、昨日行った更新や連携変更も、原因とは断定せず関連する事実として記録します。

比較で変える条件は一つにする

同じ記事を同じ役割のユーザーで開き、別のブラウザーで違いを見ます。次に別の回線や端末を試す、と条件を分けます。ユーザーごとに見える画面や権限が違うなら、それも書いてください。大量の同時テストは、かえって処理を増やすため避けます。

ブラウザー拡張の影響を確かめる場合は、社内ルールの範囲で別プロファイル等を使います。認証できない画面を「改善した」と数えないことが大切です。開いている編集タブも整理しますが、未保存の文章を失わないよう、先に原稿を手元へ残します。

変更しないまま残せる記録

URL、操作名、時刻と時間帯、正常だった時点、待ち時間の大まかな長さ、エラー文言、影響する担当者をまとめます。画面の記録では顧客情報を隠し、外部へ渡す範囲を確認してください。管理者アカウントを増やしたり、パスワードを問い合わせ欄へ貼ったりする必要はありません。

3. 通信のどこで待っているかを見る

制作担当はブラウザーの開発者ツールで対象操作の通信を確認します。接続が遅いのか、応答の最初のデータを待っているのか、データ受信後に画面が動かないのかを分けると、ホストへ何を尋ねるかが明確になります。

ChromeのNetwork公式説明は、対象要求のTimingで通信の内訳を確認する方法を示しています。応答待ちのTTFBには往復の遅延とサーバー側の準備時間が含まれます。数字が大きいだけで、データベースやPHPが原因と確定するわけではありません。

通信記録には入力内容や認証情報が含まれ得ます。HAR等を渡す場合は共有内容を確認し、必要な要求と時刻に絞ります。遅いからという理由だけで、本番のキャッシュや防御設定を全体停止しないでください。

4. 保存待ちは、再送する前に原稿と保存値を確認する

保存ボタンが回り続けると、何度も押したくなります。しかし、処理は完了していて画面だけ更新されない場合も、保存自体が失敗した場合もあります。未保存の文章を残し、応答と保存内容を確かめてから次の操作を決めます。

別の画面で同じ記事の編集値やリビジョンを確認する際は、同時編集の担当と調整してください。原稿を上書きしない確認方法を使い、表示されたメッセージだけを成功の証拠にしません。保存値を確認できない場合は、未確認のまま担当へ渡します。

要求先がREST APIで、JSONや認証のエラーが出ているなら、保存・連携が失敗するときの確認表で要求と応答を調べます。処理の遅さと拒否、保存後の公開表示は別の確認です。管理画面を速くするために認証や権限を緩める対応は避けましょう。

5. Heartbeatと追加機能を、必要性から調べる

管理画面を開いている間には、画面の背後で通信が動くことがあります。通信の件数が多いこと自体を不具合とせず、どの要求がどの機能に使われているか、待ち時間やホストの制限と関係するかを確かめます。

WordPress公式のHeartbeat APIは、ブラウザーから定期的にデータを送り、admin-ajaxの処理から応答を受ける仕組みです。プラグインが独自の情報をやり取りすることもできます。admin-ajaxという名前だけで、すべての要求を同じ機能と判断しないでください。

停止を検討するなら、利用する画面と依存機能、共同編集などへの影響を担当が確認します。追加プラグイン、外部連携、一覧の付加情報、定期処理も対象にし、必要な機能を説明なく消しません。ホストには発生時刻、対象操作、利用プランで確認できる使用量や制限を添えて相談します。公開ページのアクセス数だけでは管理処理の負荷は説明しきれません。

6. 改善は保存と検証を伴う一つの変更から

原因候補が出たら、変更前の構成と設定を残し、戻す条件を決めます。追加機能を止める、設定を変える、処理を修正する、ホストへ相談するという候補を、必要な業務への影響で選んでください。

本番へ反映する前に決めること

検証環境があれば、対象操作と重要な機能をそこで比較します。本番でしか再現しない場合は、実行する人、時間、影響、保存先、戻し方を合意します。すべてのプラグインを一度に停止すると、何が変わったか分からず、フォームや会員機能も止まる場合があります。

同じ操作で結果を確かめる

変更前と同じ条件で一覧、編集、保存を試し、改善した点と変わらない点を記録します。保存値と公開ページも確認してください。待ち時間が短くなっても、権限や入力欄が欠けているなら完了ではありません。削減時間は実測し、ホスト変更や作業費に見合うかを別に評価します。

データ削除や全体設定の変更を、原因を調べる代わりに行わないことが大切です。バックアップの比較と復元条件を先に確認し、現在の受付データを無条件に巻き戻す復元は避けます。

7. Acquaへ依頼する際は、編集の困りごとを資料にする

自社で再現条件をそろえられれば、それだけでも調査を進めやすくなります。通信や追加機能の調査、WordPress実装の修正が必要な場合は、サイトURL、止まる操作、発生時刻、直前の変更、現在の管理先をまとめて相談してください。

企業の担当者には、Web運用の相談として、調査する画面、必要な編集機能、修正後の確認と担当を整理します。制作会社には、実装・検証の相談として、テーマや追加コード、再現手順、検収条件を受け渡す方法を相談できます。

対応の可否、必要な権限、調査と修正の範囲、ホスト側へ頼む作業、費用は構成を見て個別に確認します。必ず速くなる、決まった時間内に復旧するといった約束はせず、分かった点と未確認を分けて返すことが必要です。相談窓口には、最初は機密情報を含めない概要を送ってください。

8. 待ち時間と、更新が続く状態を検収する

最終的に確かめるのは、担当者が必要な画面を開き、文章や画像を編集し、保存内容と公開結果を判断できることです。速度の測定値と、入力・保存・公開が正常なことを別々に記録します。

確認できなかった操作、残る制限、次に調べる担当を残してください。操作が短くなった後の空き時間は、古い案内の修正や受付の確認など、必要な運用へ使えます。日付だけの更新や大量投稿を目的にしません。

参考にした一次資料：

• WordPress：Heartbeat API
• Chrome DevTools：Networkの確認方法