WordPress管理画面が重い原因診断と改善手順

WordPressの管理画面が重いと、記事更新、画像差し替え、固定ページ修正、予約投稿、フォーム設定、プラグイン更新が遅れます。

公開ページの表示速度が悪い場合は、画像、キャッシュ、CSS、JavaScript、Core Web Vitalsを中心に見ます。一方で、管理画面だけが重い場合は、管理画面で動くプラグイン処理、DB、autoload、postmeta、wp-cron、Heartbeat、admin-ajax、PHPメモリ、サーバーリソースを切り分ける必要があります。

WordPress公式のOptimizationでは、不要なプラグインの見直しや、プラグインごとのパフォーマンス確認が重要な観点として整理されています。管理画面の診断では、Query MonitorのようにDBクエリ、PHPエラー、フック、HTTP API、読み込みファイルを確認できるツールも役立ちます。

WordPress管理画面の重さは、公開ページ高速化の延長ではなく、投稿運用を止めている管理画面専用の処理を切り分ける問題です。

この記事では、投稿一覧、編集画面、メディア、公開処理が重いときに、Web担当者が制作会社や保守会社へ依頼できる粒度で、診断順と改善手順を整理します。

管理画面だけ重い時に最初に見る症状

最初に確認するのは、公開ページも遅いのか、管理画面だけが遅いのかです。

公開ページも管理画面も遅いなら、サーバー、PHP、DB、キャッシュ、プラグイン全体の問題を疑います。公開ページは普通なのに管理画面だけが遅いなら、ログインユーザー向けの動的処理、管理画面フック、投稿メタデータ、wp-cron、admin-ajax、外部API待ちを優先して見ます。

症状	まず疑う領域	記録しておくこと
ダッシュボードを開くのが遅い	ダッシュボードウィジェット、外部API、更新確認	表示までの秒数、重いウィジェット、時間帯
投稿一覧が遅い	カスタムカラム、投稿数、検索、postmeta	一覧件数、表示項目、検索条件
編集画面が遅い	ブロックエディター、メタボックス、カスタムフィールド	開く時間、保存時間、使っているブロック
保存・公開が遅い	save_post系フック、キャッシュ削除、外部連携	保存時だけ遅いか、公開時だけ遅いか
メディア一覧が遅い	画像数、サムネイル生成、ストレージ	画像件数、アップロードサイズ、生成失敗
プラグイン画面が遅い	ライセンス確認、更新API、管理画面通知	どのプラグイン画面か、外部通信の有無
特定ユーザーだけ遅い	権限、表示オプション、ブラウザ拡張	ユーザー権限、ブラウザ、端末

管理画面の重さは、画面表示の遅さと、操作後の遅さを分けて考えます。

投稿一覧を開く前から遅いなら、一覧取得やカラム表示が重い可能性があります。記事を開くまでは普通で、保存ボタンを押したあとに固まるなら、保存時に動くフック、リビジョン、メタデータ更新、キャッシュ削除、外部通知を疑います。

「管理画面が重い」という一言では依頼が粗すぎます。投稿一覧、編集画面、メディア、保存、公開のどこが遅いかを先に分けることが診断の入口です。

制作会社や保守会社に相談するときは、「管理画面が重いです」だけでなく、「投稿一覧を開くのに12秒、記事保存後に20秒、画像アップロード後にタイムアウトする」のように、作業単位で伝える方が原因に近づけます。

公開ページ高速化では管理画面が直らない理由

公開ページの高速化と、管理画面の高速化は、見る場所が違います。

公開ページでは、画像、CSS、JavaScript、キャッシュ、CDN、Core Web Vitalsが重要です。管理画面では、ログイン状態の動的処理が中心になり、ページキャッシュが効かないことも多くあります。

領域	公開ページで効く対策	管理画面で見るべき対策
キャッシュ	ページキャッシュ、CDN、ブラウザキャッシュ	wp-admin除外、オブジェクトキャッシュ、DB負荷
画像	LCP画像、WebP/AVIF、遅延読み込み	メディア一覧、サムネイル生成、アップロード処理
JavaScript	不要JS削除、遅延読み込み	admin-ajax、Heartbeat、エディター拡張
プラグイン	公開ページのCSS/JS読み込み	管理画面通知、一覧カラム、保存時フック
DB	表示用クエリ、検索、関連記事	wp_options、autoload、postmeta、リビジョン
サーバー	TTFB、キャッシュヒット率	PHPワーカー、メモリ、管理画面の同時処理

WordPressの管理画面は、ログインユーザーごとに状態が変わります。投稿の下書き、自動保存、権限、通知、更新情報、管理画面ウィジェット、プラグイン固有のメニューなどが絡むため、単純な静的キャッシュでは解決しにくい領域です。

また、高速化プラグインを追加しても、管理画面の重さが改善するとは限りません。むしろ、設定画面、通知、キャッシュ削除、最適化スキャンが増えて、管理画面の負荷が増えることもあります。

公開ページのLCPやCLSを改善しても、投稿保存、メディアアップロード、プラグイン画面の遅さは別原因として残ることがあります。

管理画面が遅いときは、PageSpeed Insightsの点数より、管理画面で実際に発生しているDBクエリ、PHP処理、Ajax通信、Cronイベント、外部API待ちを見ます。

投稿一覧・編集画面・メディアで起きる遅延の原因

管理画面の遅さは、画面ごとに原因が変わります。

投稿一覧が遅い場合は、一覧表示のためのDBクエリ、カスタムカラム、SEO分析列、カスタム投稿タイプ、検索条件、表示件数を見ます。編集画面が遅い場合は、ブロックエディター、メタボックス、カスタムフィールド、リビジョン、自動保存、外部連携を見ます。メディアが遅い場合は、画像数、サムネイル生成、ストレージ、画像最適化プラグインを見ます。

画面・操作	よくある原因	確認すること
投稿一覧	カスタムカラム、SEOスコア列、重い並び替え	表示オプション、カラム数、検索条件
固定ページ一覧	親子階層、ページビルダー情報、権限チェック	ページ数、階層、追加カラム
編集画面の初回表示	ブロック、メタボックス、カスタムフィールド	読み込み時間、表示される管理UI
記事保存	save_post、リビジョン、メタ更新、キャッシュ削除	保存だけが遅いか、公開時だけ遅いか
メディア一覧	画像件数、サムネイル、添付メタ	表示件数、サムネイル生成状況
画像アップロード	大容量画像、サムネイル生成、WebP変換	元画像サイズ、生成される画像サイズ
予約投稿	wp-cron、タイムゾーン、Cron詰まり	予約時刻、Cronイベント、失敗履歴

特に編集画面では、開く時と保存する時を分けます。

開く時が遅いなら、エディターに表示するための情報取得が重い可能性があります。保存時だけ遅いなら、保存後に動く処理が多すぎる可能性があります。たとえば、サイトマップ再生成、検索インデックス更新、キャッシュ削除、SNS通知、外部API送信、メール通知などです。

メディア操作では、画像の枚数だけでなく、アップロード時に生成されるサムネイル数も見ます。テーマやプラグインが追加画像サイズを増やしていると、1枚の画像アップロードで複数ファイル生成が走り、管理画面上では「アップロードが終わらない」ように見えることがあります。

管理画面の遅延は、表示が遅いのか、保存が遅いのか、アップロードが遅いのかで原因が変わります。画面単位ではなく操作単位で分けるのが実務的です。

まずは、同じ記事で「編集画面を開く」「下書き保存」「公開」「画像を1枚追加」「メディア一覧を開く」を別々に測り、どこで待ち時間が増えるかを記録します。

プラグインと管理画面フックを確認する

管理画面が重いとき、プラグインは最初に見るべき領域です。

ただし、単純に数が多いから重いとは限りません。重要なのは、管理画面で何をしているかです。管理画面通知を出す、投稿一覧にカラムを追加する、保存時に外部APIへ送る、ライセンス確認をする、更新確認をする、ダッシュボードウィジェットを出す、といった処理が積み重なると重くなります。

見るポイント	よく使われる処理	遅くなりやすい場面
管理画面読み込み	admin_init、admin_menu、admin_enqueue_scripts	どの管理画面でも毎回重い
投稿一覧カラム	manage_posts_columns、manage_posts_custom_column	投稿一覧だけ遅い
保存時処理	save_post、transition_post_status	下書き保存・公開が遅い
Ajax処理	wp_ajax_*、admin-ajax.php	裏で通信が増える
外部通信	HTTP API、ライセンス確認、API同期	特定プラグイン画面が遅い
エディター拡張	ブロック、メタボックス、カスタムフィールド	編集画面だけ遅い

Query Monitorは、WordPressとWooCommerce向けの開発者用パネルとして、DBクエリ、PHPエラー、フック、アクション、読み込まれたスクリプトやスタイル、HTTP API呼び出しなどを確認できます。管理画面の重さを調べるときは、公開ページではなく、実際に遅い管理画面で計測することが大切です。

検証の順番は、次のように進めます。

順番	作業	注意点
1	本番バックアップと復元手順を確認する	DB削除や停止作業の前提
2	検証環境を用意する	本番で停止検証しない
3	遅い画面をQuery Monitorで確認する	クエリ、フック、HTTP APIを見る
4	管理画面系プラグインを候補化する	SEO、セキュリティ、バックアップ、フォームなど
5	1つずつ停止・再確認する	まとめて止めない
6	代替、設定変更、読み込み制御を検討する	削除だけで判断しない

プラグイン診断では、プラグイン数よりも「管理画面のどのフックで、どの処理が、どの画面で動いているか」を確認します。

特に、投稿一覧のカラム追加と保存時フックは見落とされやすいです。公開ページには影響していないのに、編集者の作業だけを重くしていることがあります。

DB・autoload・postmeta・リビジョンを点検する

管理画面が重いWordPressでは、DBが原因になることがあります。

特に見るべきなのは、wp_optionsのautoload、wp_postmeta、リビジョン、transient、ログ系テーブル、フォーム送信履歴、バックアップやセキュリティプラグインの履歴です。

領域	起きやすい問題	管理画面への影響
wp_options autoload	不要な設定値が毎回読み込まれる	wp-admin全体が重くなる
wp_postmeta	カスタムフィールド、SEO情報、ページビルダー情報が肥大化	投稿一覧・編集画面が重い
リビジョン	長期運用で過去版が増え続ける	編集画面やDB容量に影響
transient	期限切れ一時データが残る	DB検索や管理画面処理が重い
ログ系テーブル	セキュリティ、フォーム、アクセス解析、バックアップ履歴	管理画面表示や検索が遅い
Action Scheduler系	予約ジョブや失敗ジョブが溜まる	WooCommerceや連携系で遅い

autoloadは、WordPressの各リクエストで自動的に読み込まれる設定値です。便利な仕組みですが、不要なプラグイン設定や古いテーマ設定が大量に残ると、管理画面の全体的な重さにつながります。

postmetaは、記事や固定ページに紐づく追加情報です。カスタムフィールド、ページビルダー、SEOプラグイン、関連記事、CTA、フォーム連携などが多いサイトでは、1記事に大量のpostmetaが付くことがあります。投稿一覧でメタ情報を表示したり、編集画面でメタボックスを大量に読み込んだりすると、遅延が目立ちます。

確認時に保守会社へ渡すとよい情報は次の通りです。

依頼したい確認	具体的な見方
autoloadの総量	wp_optionsでautoload対象の合計サイズを見る
大きいoption	サイズの大きいoption_nameを上位から確認する
postmetaの偏り	meta_key別の件数や肥大化を確認する
リビジョン数	投稿ごとのリビジョン数、全体件数を見る
期限切れtransient	不要な一時データが残っていないか見る
ログテーブル	プラグイン固有テーブルの容量を見る

DB最適化は「削除ボタンを押す作業」ではなく、autoload、postmeta、リビジョン、ログのどれが管理画面を重くしているかを確認してから行う作業です。

削除系の作業は必ずバックアップと復元手順を確認してから実施します。リビジョンやtransientの削除は有効なことがありますが、フォーム履歴、EC注文、会員情報、カスタム投稿の関連データを誤って消すと復旧が難しくなります。

wp-cron・Heartbeat・admin-ajaxを切り分ける

管理画面が常に重いのではなく、特定のタイミングで急に重くなる場合は、wp-cron、Heartbeat、admin-ajaxを確認します。

WordPress公式のCronでは、WP-CronはWordPress内で時間ベースのタスクを扱う仕組みとして説明されています。更新確認、予約投稿、メール送信、バックアップ、外部連携、セキュリティスキャンなどが同じ時間帯に重なると、管理画面操作とぶつかることがあります。

Heartbeat APIは、WordPressに組み込まれたサーバーポーリングの仕組みです。自動保存、投稿ロック、ログイン状態の確認、プラグインのリアルタイム処理などで使われます。便利な一方で、編集画面を複数人が開いている、プラグインがHeartbeatに処理を追加している、サーバーが弱い、といった条件が重なるとadmin-ajax.phpへの通信が目立つことがあります。

領域	典型的な症状	確認方法
wp-cron	特定時刻に固まる、予約投稿が失敗する	Cronイベント、実行時間、失敗履歴
バックアップ	夜間や営業時間中に重い	実行スケジュール、保存先、圧縮時間
セキュリティスキャン	管理画面全体が遅い	スキャン時間、対象範囲、ログ
Heartbeat	編集画面で定期的にAjaxが走る	DevTools Network、admin-ajax.php
admin-ajax	裏側通信が多い、待ちが長い	Ajaxアクション、レスポンス時間
外部API	プラグイン画面や保存時に止まる	HTTP API呼び出し、タイムアウト

WP-CLIが使える環境なら、wp cron系のコマンドでイベント一覧やCronの状態を確認できます。実務では、期限切れイベントが溜まっていないか、失敗を繰り返すジョブがないか、バックアップや同期処理が営業時間中に走っていないかを見ます。

Heartbeatは、止めればよいという話ではありません。自動保存や投稿ロックにも関係するため、複数人で編集するサイトではむやみに無効化すると、編集競合や保存漏れにつながります。頻度を調整する、対象画面を絞る、重いプラグイン処理を外す、といった順で考えます。

管理画面が「たまに」重い場合は、常時の表示速度ではなく、wp-cron、Heartbeat、admin-ajax、外部APIが重なるタイミングを疑います。

公開処理が遅い場合は、公開ボタンを押した瞬間に何が走るかも見ます。サイトマップ更新、キャッシュ削除、検索インデックス送信、SNS通知、Webhook、メール通知が一斉に走ると、編集者には「公開処理が終わらない」と見えます。

PHP・メモリ・サーバーリソースを確認する

管理画面は動的なPHP処理が多いため、サーバーリソースの影響を受けやすいです。

公開ページはページキャッシュやCDNで軽く見えていても、wp-adminはログイン状態の処理が多く、PHPとDBに直接負荷がかかります。そのため、表側は問題ないのに管理画面だけ重い、という状態が起きます。

確認項目	見る理由	典型的な問題
PHPバージョン	古いPHPは速度や保守面で不利	古いバージョン、互換性放置
memory_limit	編集画面や画像処理で不足しやすい	メディア処理失敗、白画面、エラー
max_execution_time	重い保存処理や画像生成で足りない	タイムアウト、504
PHP-FPMワーカー	同時処理数に影響する	複数編集者で詰まる
MySQL/MariaDB	DB検索、postmeta、optionsに影響する	スロークエリ、CPU上昇
OPcache	PHP実行効率に影響する	無効、メモリ不足
オブジェクトキャッシュ	DB負荷軽減に効く場合がある	Redis未設定、設定不整合
サーバーログ	見えないエラーを確認する	PHP Warning、Fatal error、502/504

単純にPHPメモリを増やすだけで改善することもあります。ただし、それは根本原因を隠すだけの場合もあります。重いプラグイン処理、肥大化したDB、失敗する外部API呼び出しがある状態でメモリだけ増やすと、しばらく動くように見えて、後から別の形で詰まります。

共用サーバーでは、CPU、メモリ、同時実行数、DB接続数、I/Oに制限があります。編集者が複数人いるサイト、画像アップロードが多いサイト、予約投稿や外部連携が多いサイトでは、管理画面の体感に差が出ます。

管理画面だけが重い場合でも、公開ページ用キャッシュが効いているだけで、実際にはPHPワーカー、DB、メモリ、サーバーI/Oが限界に近いことがあります。

サーバー移行やプラン変更を検討する前に、どのリソースが詰まっているかを確認します。CPUが高いのか、メモリ不足なのか、DBが遅いのか、外部API待ちなのかで、適切な対策は変わります。

安全に改善する順番と外注時に渡す情報

WordPress管理画面の改善は、本番を壊さない順番で進めます。

いきなりDB削除、プラグイン停止、キャッシュ設定変更、PHPバージョン変更を本番で行うと、投稿編集、フォーム、予約投稿、会員機能、EC、外部連携に影響することがあります。まずは記録、バックアップ、検証環境、原因仮説の順で進めます。

順番	作業	目的
1	遅い画面と操作を記録する	症状を絞る
2	本番バックアップと復元方法を確認する	失敗時に戻せるようにする
3	検証環境を用意する	本番停止や表示崩れを避ける
4	Query Monitorやログで重い処理を見る	DB、PHP、フック、外部通信を確認する
5	プラグイン候補を1つずつ確認する	原因を混ぜない
6	DB、autoload、postmeta、Cronを点検する	裏側の詰まりを整理する
7	PHP、サーバー、オブジェクトキャッシュを見る	土台の不足を確認する
8	変更ごとに同じ操作で再測定する	効果と副作用を確認する

外注時には、次の情報を渡すと話が早くなります。

渡す情報	例
遅い画面	投稿一覧、固定ページ編集、メディア一覧、公開処理
再現手順	投稿一覧を開く、記事Aを編集、画像を追加、公開する
待ち時間	一覧表示12秒、保存20秒、画像アップロードで504
発生頻度	毎回、午前だけ、予約投稿時だけ、複数人編集時だけ
利用環境	ブラウザ、端末、ユーザー権限、社内回線
WordPress情報	WordPress、PHP、テーマ、主要プラグインのバージョン
サーバー情報	サーバープラン、PHP設定、DB、エラーログの有無
業務上の制約	本番停止不可、営業時間、予約投稿、フォーム、EC、会員機能

依頼文は、次のようにすると具体的です。

WordPressの公開ページではなく、管理画面の投稿運用が遅いです。投稿一覧の表示、記事保存、画像アップロード、公開処理を分けて確認し、Query Monitor、DBのautoload/postmeta、wp-cron、admin-ajax、PHPメモリ、サーバーリソースの順に原因を切り分けてほしいです。

この粒度で依頼できると、「高速化プラグインを入れました」で終わりにくくなります。管理画面の重さは、投稿運用の生産性に直結するため、公開ページの点数とは別に改善計画を作るべきです。

外注時は「管理画面を速くして」ではなく、遅い画面、遅い操作、再現手順、待ち時間、業務上止められない処理を渡すと、原因診断の精度が上がります。

最終的には、投稿一覧が開ける、編集画面が固まらない、画像を安全に追加できる、公開処理が待てる時間で終わる、予約投稿が失敗しない、という運用上の状態をゴールにします。管理画面の改善は、スコア改善ではなく、Web担当者が安心して更新できる作業環境を戻すための実装です。