ワードプレス（WordPress）
プラグイン

WordPressにログインすると管理画面だけ異常に遅い…その原因を調べて対策しました

2026.01.07
この記事は約5分で読めます。

WordPressにログインしたあとの画面表示が遅い最近、WordPressの管理画面が異常に重くなりました。しかし、通常のページ（未ログイン状態だとのページ表示は速いのです。PageSpeedInsights でも80点前後の評価なのでサクサク感もあります。
しかし、WordPressにログインするとトップページの表示がやたら遅いのです。管理画面やフロント表示が30秒以上かかることもあります。「表示高速化は一通りやったはずなのに、なぜログイン時だけ遅いのか？」これが今回の出発点です。

WordPressにログインしたあとの画面表示が遅い

WordPressにログインしたあとの画面表示が遅い

まず切り分けとして分かったのは次の点です。

  • 一般ユーザー（未ログイン）向けページは問題なし

  • ログイン時にだけHTMLソースが異常に大きくなる

  • Network（通信）を見ると、外部スクリプトが大量に動いている

つまり問題は
「WordPressそのもの」ではなく、「ログイン時にだけ追加される処理」にありそうだ、という仮説に至りました。

ここからは、ChatGPTに相談しながら一つずつ原因を潰していきました。

対策1：ダッシュボードバー（管理バー）を停止

最初に効果が大きかったのがこれです。

  • フロント側に表示される黒い管理バーを非表示にする

  • 管理バーは便利だが、ログイン時はDOM操作やJSが増える

これだけで、体感的に「少し軽くなった」感触がありました。

対策2：Heartbeat API を制御

Heartbeat Control設定画面

次に手を入れたのが Heartbeat API です。

Heartbeat は、

  • 管理画面の自動保存

  • セッション維持

  • 通知更新

などのために、定期的にサーバーと通信します。

今回は以下の方針にしました。

  • フロント側：Heartbeat を停止

  • 管理画面・投稿編集：頻度を落とす

結果として、

  • ログイン中に「裏で常に何か動いている」感じが減少

  • 管理画面の引っかかりが明らかに軽減

しました。

対策3：テーマ Cocoon の「管理者向け表示」を見直す

Cocoon は高機能なテーマですが、

  • 管理者向けの便利表示

  • 統計や補助UI

がログイン時のフロント表示に影響することがあります。

そこで、

  • 管理者向けの表示項目を整理

  • フロント側では不要なものをオフ

にしました。

「便利さ」と「軽さ」のトレードオフを、ここで一度整理しました。

対策4：ログイン中だけ「外部計測・広告系スクリプト」を止める

ここが今回の最大の改善ポイントです。

ログイン時のNetworkを見ると、

  • Google Tag Manager

  • GA4

  • Microsoft Clarity

  • 広告

  • SNS埋め込み

などが一斉に動いていました。

これらは「一般ユーザー向け」には必要ですが、

  • 管理者がログインして作業するとき

  • 表示確認をするとき

には、必ずしも必要ありません。

そこで方針をこう切り替えました。

  • 未ログイン時：これまで通り計測・広告を動かす

  • ログイン時：外部計測・広告系スクリプトを一切読み込まない

対策5：GTM（Google Tag Manager）の中身を整理

GTM を確認すると、

  • GA4

  • Clarity

  • すでに提供終了した Google Optimize

が混在していました。

Optimize はサービス終了済みなので、

  • タグを停止・削除

  • GTM を「現役タグだけ」に整理

これで無駄な処理をさらに削減できました。

新規プラグインは増やしたくない

ここで一つ方針を決めました。

「これ以上、プラグインは増やさない」

代わりに使ったのが、すでに入っていたプラグインです。

Head, Footer and Post Injections を活用

このプラグインは、

  • HEAD や BODY にコードを挿入できる

  • PHP条件分岐が使える

という特徴があります。

これを使って、

  • ログイン中だけ読み込まない

  • 未ログイン時だけタグを出す

という条件付き制御を行いました。

実装イメージ

page section injection

実際には、以下のような考え方で実装しています。

もし「未ログイン」なら
・GTMを読み込む
・計測タグを読み込む
・広告タグを読み込む
ログインしているなら
・何も読み込まない

具体的なコードは伏せますが、
「is_user_logged_in() で条件分岐する」だけのシンプルな構造です。

結果：どれくらい改善したか

WordPressの表示を早くする

体感としては倍速化しました

HTMLソースを比較すると、

  • ログイン時のソース量は約80％以上削減

  • 行数も大幅に減少

  • 管理バー関連の記述が激減

体感としても、

  • ログイン時トップの表示待ちがほぼ消えた

  • 管理画面操作がストレスなく行える

レベルまで改善しました。

結論から言うと、今回の対策で「ログイン時トップページのソース量」はかなり減っています。

  • ログイン時（当初）テキスト量: 6,604,453 bytes

  • ログイン時（最新）テキスト量: 1,251,278 bytes

差分: 5,353,175 bytes 減
削減率: 約81.1% 減

これは体感が軽くなるレベルの改善です（ブラウザが解析・構築する材料が激減しているため）。

比較データ（当初 vs 最新）

  1. htmlのソース量（PDF→テキスト化の容量）

  • ログイン当初: 6,604,453 bytes

  • ログイン最新: 1,251,278 bytes

  • 約81.1%削減

  1. 行数

  • ログイン当初: 37,921 行

  • ログイン最新: 10,314 行

  • 約72.8%削減

  1. 管理バー系の痕跡

  • wp-admin-bar の出現回数

    • 当初: 69

    • 最新: 10

  • admin-bar の出現回数

    • 当初: 87

    • 最新: 17

この「管理バー系の減り方」が、ログイン時だけ遅い問題の核心にかなり刺さっています。

まとめ：ログイン時だけ遅いWordPressは珍しくない

今回の経験から言えることは、

  • 表示高速化＝一般ユーザー向けだけでは不十分

  • ログイン時は「管理者向けの別世界」

  • 外部計測・広告・便利機能が重なりやすい

ということです。

そして、

  • 新規プラグインを増やさず

  • 既存機能を整理し

  • 「誰のための処理か」を見直す

だけでも、WordPressはかなり軽くなります。

同じように
「ログインすると急に重い…」
と感じている方の参考になれば幸いです。

必要であれば、
・自分の環境ではどこを見るべきか
・Networkの見方
・切り分け手順

なども別記事でまとめたいと思います。