WordPressの管理画面が思ったように動かず、日々の投稿作業やサイト更新にストレスを感じていませんか？フロントエンドの速度対策は多くの記事で取り上げられていますが、“バックエンド”＝管理画面の遅延改善に特化したコンテンツは意外と少ないもの。
本記事では、管理画面専用のパフォーマンステスト方法から始まり、プラグイン負荷の見極め・DB最適化・PHPメモリ設定・Heartbeat API制御・ブラウザキャッシュ対策・リビジョン制限まで、7つのポイントを徹底解説。具体的な設定手順やプラグイン例を交え、ダッシュボード操作がサクサク快適になるチューニング法をお届けします。
ダッシュボード遅延の測定方法
結論：まずは正確に「管理画面がどれだけ重いのか」を測定し、改善項目を数値化しましょう。Chrome DevTools などの開発者ツールを使うことで、バックエンドリクエストの遅延原因を可視化できます。
理由：対策を講じる前に「どこがボトルネックになっているか」を把握しないと、根本的な改善にはつながりません。ページビルダー系プラグインやオートセーブ機能が多くのリクエストを発生させているのか、あるいはサーバー側のレスポンス遅延が主要因なのかを切り分ける必要があります。
Chrome DevTools を用いた手順
- Network タブを開く
Chrome で管理画面にログインし、F12キーを押して開発者ツールを起動。「Network」タブを選択し、「Disable cache」にチェックを入れた上で、ページをリロードします。 - レスポンス時間の確認
一覧に表示された各リクエストの「Time」列で、最も時間のかかっているものを探します。特に/wp-admin/admin-ajax.phpや/wp-admin/post.phpなど、Ajax・ページロードに関わるリクエストを重点的にチェック。 - Waterfall チャートの活用
リクエストをクリックし、右ペインの「Timing」タブで、DNSルックアップ／TCPコネクション／Waiting (TTFB)／Content Download の内訳を確認。TTFB が長い場合はサーバー処理時間に課題あり。Content Download が長い場合はデータ転送量やネットワーク回線のボトルネックが疑われます。 - 管理画面専用のベンチマーク
フロントエンド速度測定ツール（PageSpeed Insights など）はバックエンドには不向き。DevTools での手動測定を週次で行い、改善施策前後の数値を比較しましょう。
プラグイン負荷の見極めと整理
結論：管理画面の重さの多くは、プラグイン負荷が原因です。不要なプラグインを整理し、動作が重いプラグインはチューニングまたは代替を検討することで、管理画面の遅い問題を大幅に改善できます。
なぜプラグイン負荷が管理画面遅延を引き起こすのか
- バックエンド処理の増加：プラグインは管理画面を拡張するために多数のフックを実行。特にAjax系プラグインはadmin-ajax.phpへのリクエストが頻発し、サーバー処理が遅くなる。
- データベースクエリの増大：独自テーブルや大量のオプション保有により、SQLクエリ数が増加。メモリ増強していない環境では処理能力を超過。
- フロントエンドリソースの競合：多数のスクリプト・スタイルを読み込むプラグインはブラウザレンダリング負荷を高め、操作感を低下させる。
プラグイン負荷を可視化する手順
- Query Monitor プラグインの導入：「Slow Queries」や「HTTP API Calls」を確認し、負荷要因を把握。
- プラグインアクティビティの切り分け：全プラグイン無効化後一つずつ有効化し、レスポンス時間の変化を測定。
- 特定プラグインの診断レポート作成：例：ページビルダーX 有効化で Waiting 時間が 700ms→2,000ms。
負荷軽減のための整理・チューニング手法
- 不要プラグインの削除：WP-Optimize でデータベースクリーンアップ。
- アセットの遅延読み込み：Asset Cleanup、Perfmatters で不要アセットを無効化。
- プラグインの代替検討：動作重いフォームビルダー→Contact Form 7＋カスタム。
- プラグイン設定の最適化：functions.php でダッシュボードウィジェットを制御。
データベース肥大化の対策
結論：投稿リビジョンや不要テーブルの蓄積を抑制し、定期的にクリーンアップすることで、管理画面のレスポンスを大幅に改善できます。
なぜデータベース肥大化が問題なのか
- リビジョン蓄積：wp_posts・wp_postmeta テーブル肥大化で SELECT クエリが遅延。
- オプションテーブル断片化：autoload 項目の大量読み込みで初期ロードが遅延。
- 不要テーブル残存：プラグイン削除後のテーブルやオプションがパフォーマンス低下を招く。
リビジョン制限と自動クリーンアップ
- WP_POST_REVISIONS 設定：wp-config.php にてリビジョン数を 5 件に制限。
- 一括削除：WP-Optimize または WP-CLI で全リビジョンを削除。
- 定期自動実行：WP Crontrol で週次ジョブに登録。
オプションテーブルの最適化
- Autoload 見直し：wp_options の autoload=yes を no に更新。
- テーブル最適化：OPTIMIZE TABLE コマンド、WP-Optimize 自動化。
サーバースペックとPHPメモリリミット増強
結論：PHP メモリリミット増強と適切なサーバーチューニングで、管理画面の体感速度を大幅に向上できます。
PHPメモリリミット増強の具体手順
- php.ini 編集：memory_limit = 512M に設定、PHP-FPM／Apache 再起動。
- .htaccess でオーバーライド：php_value memory_limit 256M を追加。
- wp-config.php 設定：WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT 定義。
サーバーリソースのモニタリングと最適化
- New Relic／Datadog：プロセス CPU・メモリ使用率を可視化。
- PHP-FPM 設定：pm.max_children など適切値に調整。
- ディスク I/O 改善：SSD 移行、InnoDB buffer pool 設定。
Heartbeat API 制御
結論：Heartbeat API の実行間隔を延長・制御し、Ajax負荷を軽減しましょう。
Control Heartbeat プラグイン
設定画面で投稿編集300秒、ダッシュボード600秒に変更。
コード追加による制御
add_filter('heartbeat_settings','custom_heartbeat_settings');
function custom_heartbeat_settings($settings){
$screen=get_current_screen();
if($screen && $screen->base==='post'){
$settings['interval']=300;
}else{
$settings['interval']=600;
}
return $settings;
}完全無効化
add_action('init',function(){
if(!defined('DOING_AJAX')||!DOING_AJAX){
wp_deregister_script('heartbeat');
}
},1);ブラウザキャッシュとローカル環境要因
結論：キャッシュクリアや環境チェックで、クライアント側遅延を排除しましょう。
キャッシュクリア手順
Ctrl+F5/⌘+Shift+R、閲覧履歴データの「キャッシュされた画像とファイル」を削除。
拡張機能無効化チェック
シークレットモードで速度比較し、不要拡張を無効化。
ネットワーク確認
DevTools Network で RTT をチェック。有線LAN/VPN解除など。
端末リソースモニタリング
タスクマネージャーでブラウザのメモリ・CPU使用率を確認。
リビジョン制限＆オートセーブ制御
結論：リビジョン無制限と頻繁なオートセーブは負荷要因。制限と間隔調整で軽量化。
リビジョン制限
define('WP_POST_REVISIONS',5);既存リビジョン削除
WP-CLI or WP-Optimize で削除。
オートセーブ間隔調整
add_action('admin_init',function(){
wp_deregister_script('autosave');
wp_enqueue_script('autosave',includes_url('js/autosave.min.js'),[],null,true);
add_filter('autosave_interval',function(){return 300;});
});まとめ
管理画面の重さは、原因の特定→測定→対策→検証のサイクルで劇的に改善します。この記事の7つのポイントを順に実施し、効果を数値化してください。まずはキャッシュクリアやプラグイン整理から着手し、段階的に対策を深めましょう。
