ダッシュボードが極端に重いときの確認ポイント

公開：2025.09.20

この記事はこんな人向けです

WordPressのダッシュボード（管理画面）がやたら重い／固まる／タイムアウトで仕事にならない
投稿やメディアの画面、プラグイン更新、ユーザー管理など管理系の操作だけが遅いと感じる
原因がサーバー負荷なのか、プラグイン／テーマ／WP-Cron／データベースなのか、切り分けの道筋が知りたい

WordPressレベル別対応難易度

Lv1 Lv2 Lv3 Lv4 Lv5 Lv6 Lv7

レベル判断は、右のレベル表（スマホは画面下）を参考にしてください。

赤：外注推奨オレンジ：条件付き自力可緑：自力対応可

ダッシュボードが極端に重いときの全体像と対応方針

管理画面の遅さは、プラグインの高負荷処理・WP-Cronの詰まり・admin-ajax/Heartbeatの過負荷・データベースの肥大化・外部API待ちなど、原因が複合しがちです。
「症状の再現条件→負荷の発生箇所→影響範囲」の順に切り分け、いじる前にバックアップという安全策を徹底しましょう。
本記事はレベル別に、最低限の安全確認→負荷源のあたりを付ける→恒久対策の流れで案内します。

ダッシュボードが重いとき～WordPressレベルごとのおすすめ対応

「今日は作業できない…」を防ぐための初動と判断

まずは「本当に管理画面だけが遅いのか」を軽く検証します。
フロント（サイト閲覧）は普通に開けるのに、/wp-admin や投稿編集だけが極端に遅いなら、admin-ajaxやダッシュボードウィジェット、バックグラウンド処理（WP-Cron）が疑わしいサインです。

作業前に「今やっていることを止められるか」を検討してください。画像最適化・バックアップ・セキュリティスキャンなど重いタスクを同時に走らせないだけでも体感は変わります。サイトヘルス（ツール→サイトヘルス）で重大項目が出ていないかも眺めておくと状態把握に役立ちます。

ここで無理してプラグインを大量に停止すると、フォーム送信やスパム対策など重要機能が動かなくなることがあります。
迷ったらスクリーンショット＋直前操作のメモを取って、早めに修正を外注することをおすすめします。復旧のスピードを優先したい場合も、赤レベル方は専門家に任せるのが近道です。

負荷の「当て」を付けてから触る

普段からプラグインの有効化・無効化やテーマ切り替え、簡単な設定変更に慣れているオレンジレベルの方向け。
直近で入れた／更新したプラグインを思い出し、該当の設定画面（ダッシュボードウィジェット、SEO/分析、バックアップ、画像最適化、セキュリティ、キャッシュ等）を開き、管理画面で動く重い処理（自動スキャン・サムネイル生成・同期）がオンになっていないか確認します。

次に「いつ（どのページが）重いか」を絞ります。ログイン直後／投稿一覧表示／投稿編集画面／プラグイン更新／ユーザー一覧など、画面単位で遅くなるかをチェックしていきます。
例えば、投稿編集で重いなら、自動保存（autosave）や外部連携ブロック、クラウド画像参照が影響することがあります。
ダッシュボードだけなら、ウィジェットの非表示で一時緩和できるケースもあります。

さらに、WP-Cronの詰まりも要注意です。大量の予約投稿、画像一括最適化、バックアップの同時実行などでスケジュールが渋滞すると、管理画面の操作がワンテンポ遅くなったりします。重いタスクの頻度を落とす、夜間に寄せる、一時停止する、といった調整が効く場合があります。

最後に、プラグインの一時的な無効化テストは、影響範囲が小さいものから1つずつ行いましょう。フォーム／決済／会員・認証などビジネス直結のプラグインを利用している場合は、営業時間外や検証環境で行うのが鉄則です。
改善が見えたら、該当プラグインの設定最適化・代替の検討・サポートへの問い合わせ、まで進めましょう。

恒久対策の設計：計測→特定→最適化を回す

ここからはサーバー／DB／キャッシュの知識や実績がある緑レベルの方向け。
計測なしの対処は非効率なので、まずは実測。

1) パス別計測：/wp-admin/index.php、/wp-admin/edit.php、/wp-admin/post.php などで TTFB を取り、管理画面限定の遅さを数値で把握。ブラウザのネットワークタブでadmin-ajax.php と Heartbeat（/wp-admin/admin-ajax.php）の頻度・待ち時間・ペイロードを確認します。
2) プロファイル：負荷系プラグイン（バックアップ、セキュリティスキャン、画像最適化、外部API連携、統計）を中心に、管理画面ロード時のフックで重い処理が走っていないかを洗い出し。
3) DB確認：wp_options の autoload合計（数MB超）や巨大な transients、孤児オプションがないか。postmeta の肥大化（ページビルダー・旧プラグイン残骸）も編集画面の遅延要因になります。

対策は、
（A）重い処理の発火条件を絞る／無効化（ダッシュボードウィジェット停止、リアルタイム統計を遅延、画像最適化のバッチ頻度変更、セキュリティ全スキャンの夜間集中）
（B）WP-Cronの整流化（キュー詰まりの解消、サーバークーロンへの切替、同時実行の制御）
（C）DBのスリム化（autoload見直し、不要トランジェントの掃除、メタの圧縮）
（D）オブジェクトキャッシュ（Redis/Memcached）
（E）PHP周り（PHPメモリ制限・OPcache・拡張の適正化）など、
効果の大きい順で着手します。

フロントは速いのに管理だけ著しく遅い場合、外部API待ち（ライセンス認証／更新チェック／フォント／解析SDK）や、管理画面へだけ適用されるフィルターが真犯人なことも。タスク実行中のユーザー体験を守るため、バックグラウンド化／非同期化／定期処理の間引きを設計に組み込みましょう。

最後に、恒久策の定着として、運用ルール（更新ウィンドウ／重いジョブの時間帯／検証環境でのテスト）を明文化。定期的なDB点検とジョブ監視（予約投稿・サムネイル生成・バックアップ・メールキュー）をチェックリスト化すると、再発の芽を早期に潰せます。

ダッシュボードが重いときに外注する場合のポイント

「編集画面が固まって作業が止まる」「今日中の更新に間に合わせたい」といったケースは、計測→原因特定→応急処置→恒久対策の設計まで一括で任せると早いです。費用感・流れ・準備物を押さえておきましょう。

項目	ポイント
費用の目安	・一次切り分けと応急処置で 15,000～30,000円・恒久対策（DB整理・WP-Cron整流・設計調整）まで含めると 30,000～80,000円程度が目安・緊急対応は割増しになるケースあり
依頼の流れ	1. 症状の共有（どの画面／時間帯／操作で重いか） 2. 事前見積り 3. バックアップ取得 4. 計測と一時緩和 5. 原因別の恒久策提案 6. 実装／運用ルール化
準備しておくと便利	・管理画面URLとテスト用アカウント・直近の更新履歴（入れた／更新したプラグイン・テーマ）・エラーメッセージや重い画面のスクショ・サーバー情報（PHPバージョン・メモリ制限・OPcacheの有無）