WordPressが遅い・重い原因の調べ方は、「サーバーがページを返すまで」と「届いたページを表示するまで」のどちらが遅いかを先に測り、切り分けることです。
サーバー側ならプラグインやキャッシュ、表示側なら画像を疑えば、直す場所を1つに絞り込めます。
当方の検証用WordPressで実測すると、プラグイン1つでページが約3秒遅くなり、画像の載せ方だけでスマホでの表示が1.2秒から18.8秒に延びました。
しかもプラグインの遅さは、ログイン中の自分と管理画面にしか出ていません。
最終確認日：2026年10月30日（WordPress 7.1.4、PHP 8.3）
症状から、遅い場所の見当をつける
最初に、どんなふうに遅いのかを確かめます。
| 症状 | 遅い場所 | 最初に見るところ |
|---|---|---|
| どのページも、画面が白いまま待たされる | サーバーがページを返すまで | TTFB（応答の速さ）を測る |
| 文字は出るが、画像や全体の表示が遅い | 届いたページを表示するまで | ページの重さの内訳を見る |
| ログイン中や管理画面だけ遅い | キャッシュの外側で動く処理 | Query Monitorで遅い処理を探す |
| 特定のページだけ遅い | そのページの画像・埋め込み・外部の読み込み | 遅いページとほかのページを測り比べる |
| ある日から急に遅くなった | 直前の更新、キャッシュの停止 | 更新の履歴と、キャッシュが効いているか |
見当がついたら、数字で確かめましょう。
まず測る：応答の速さと表示までの時間
遅いかどうかは感覚で決めず、2つの数字を測ります。
| 測るもの | 中身 | 目安 | 測り方 |
|---|---|---|---|
| TTFB | ページを頼んでから、最初の1バイトが届くまで | 0.8秒以下が良好、1.8秒超が不良 | curl、高速化診断 |
| LCP | 画面でいちばん大きい要素が表示されるまで | 2.5秒以下が良好、4秒超が不良 | PageSpeed Insights |
目安の出典は、web.devのTTFBの解説とLCPの解説です。
TTFB（秒）は、コマンドプロンプトやターミナルで次のように測れます。
curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/Windowsのコマンドプロンプトでは、「/dev/null」を「NUL」に変えてください。
1回では決めず、5〜10回測って真ん中の値を見ます。
当方の検証では、何も変えていない同じページでも、0.14秒から0.88秒までばらつきました。
LCPは、PageSpeed InsightsにURLを入れると、スマホとパソコンの両方で確かめられます。
測った結果の読み方は、次のとおりです。
- TTFBが目安より遅い：サーバー側を疑う
- TTFBは速いのにLCPが遅い：表示側を疑う
測り方の詳しい手順は「WordPressのTTFBを改善する方法」、ページの重さは「サイトが重い原因を調べる方法」で解説しています。
実測1：外部と通信するプラグインで、ページが約3秒遅くなった
1つ目は、サーバー側が遅いケースです。
検証用に、ページを開くたびに外部のサーバーへ情報を取りに行くプラグインを作りました。
問い合わせ先は応答しないアドレスにして、待ち時間の上限を3秒にしています。
外部のサービスが止まった、つながりにくくなった、という状況の再現です。
有効にして、同じ記事を10回ずつ測った結果がこちらです。
| 状態 | 応答の速さ（中央値） |
|---|---|
| プラグインなし | 0.28秒 |
| 有効・ログインしていない人が同じURLを開く | 0.30秒 |
| 有効・ログインしていない人がキャッシュの無いURLを開く | 3.25秒 |
| 有効・ログイン中の自分が記事を開く | 3.68秒 |
| 有効・管理画面を開く | 3.24秒 |
ログインしていない人には、遅さが見えなかった
ログインしていない人が同じURLを開くと0.30秒で済んだのは、保存済みのページを返すサーバーのキャッシュが働いていたためと判断しました。
URLの末尾に毎回ちがう文字を付けてキャッシュを通らないようにすると、3.25秒になりました。
一方、ログイン中の自分と管理画面は、毎回3秒以上待たされています。
「自分だけ遅い」「管理画面だけ重い」ときは、キャッシュの外側で動く処理を疑ってください。
訪問者でも、次のようなキャッシュがまだ無いURLを開けば、3秒待つことになります。
- 公開したばかりの記事
- キャッシュが切れた直後のページ
Query Monitorで、原因のプラグインを名指しで探す
遅い処理の持ち主を探すには、無料のプラグイン「Query Monitor」が使えます。
検証ではバージョン4.1.1を、日本語の翻訳を入れて使いました。
- プラグインの新規追加で「Query Monitor」を探し、インストールして有効化する
- ログインしたまま、遅いページを開く
- 画面上部の管理バーに出る「3.08秒 7.3MB …」のような数字を押す
- 「概要」で、ページ生成時間とHTTP API 呼び出しの時間を見る
- 時間の大きい項目を開き、「コンポーネント」の列でプラグイン名を確かめる
概要を見ると、ページを作るのに3.08秒かかり、そのうち3.00秒が外部への呼び出し1件でした。
データベースへの問い合わせは33回で、合わせても0.02秒です。
「HTTP API 呼び出し」を開くと、コンポーネントの列に「プラグイン: lab-slow-remote」と、原因のプラグインが名指しで出ました。
ステータスの列は「cURL error 28: Connection timed out after 3001 milliseconds」で、3秒待って諦めたことまで読み取れます。
外部との通信ではなくデータベースが遅い場合は、「データベースクエリー」の欄に、遅い問い合わせや重複した問い合わせが分けて表示されます（公式の説明による）。
表示されるのはログイン中の管理者だけですが、調べ終わったら停止しておくと安心です。
直し方：止めるか、結果を保存させる
原因のプラグインがわかったら、次の順で考えます。
- 使っていない機能なら、プラグインを停止する
- 必要な機能なら、設定に「キャッシュ」「取得の間隔」などの項目が無いか探す
- 項目が無ければ、作者に報告するか、同じ機能の別のプラグインに替える
検証用のプラグインを、取ってきた結果を1時間保存する作りに直して測り直しました。
| 開いたページ | 直す前 | 1時間保存に直したあと |
|---|---|---|
| 管理画面 | 3.24秒 | 0.19秒 |
| キャッシュの無いURL | 3.25秒 | 0.22秒（保存の無い1回目だけ3.25秒） |
WordPressには、こうした結果を期限つきで保存するTransients APIという仕組みがあります。
自作のコードで外部と通信しているなら、この仕組みで保存できないか確かめてください。
どのプラグインか見当がつかない、止めると困るという場合は、「プラグイン競合の調べ方」で紹介している、自分だけ全プラグインを止める方法も使えます。
原因の特定や、止めてよいかの判断に迷うときは、MOTOKIの保守・運用改善でもご相談を受けています。
実測2：画像の載せ方だけで、表示が1.2秒と18.8秒に分かれた
2つ目は、表示側が遅いケースです。
検証用に、スマホの写真と同じ4032×3024ピクセル、3.74MBのJPEG画像を作りました。
WordPressのメディアに追加した時点で、2560ピクセルに縮めた画像と、1024ピクセルや768ピクセルなどの画像をWordPressが自動で作ります。
2560ピクセルを超える画像を縮める動きは、WordPress 5.3で入った仕組みです。
この画像を、2つの方法で記事の先頭に載せました。
| 載せ方 | 読み込まれた画像 | ページ全体の転送量 | LCP（中央値） |
|---|---|---|---|
| メディアから画像ブロックで挿入 | 768×576（67KB） | 167KB | 1.23秒 |
| 元の画像のURLをHTMLで直接指定 | 4032×3024（3.75MB） | 3.85MB | 18.84秒 |
同じ画像なのに、表示までの時間が15倍以上違いました。
メディアから挿入すると軽くなる理由
メディアから挿入すると、WordPressは画面の幅に合う画像をブラウザーに選ばせる指定（srcset）を付けます。
今回のスマホ表示で、ブラウザーが選んだのは768ピクセルの画像でした。
元の画像のURLを直接書くと、この指定が付かず、3.75MBをそのまま読み込みます。
FTPで上げた画像、HTMLブロック、外部の画像URLは、この形になりやすいので気をつけてください。
なお、検証用の画像は人工的に作ったものなので、縮めたあとの大きさは実際の写真と違います。
重い画像の見つけ方と直し方
- ページ重量診断に遅いページのURLを入れ、画像がいちばん重い種類になっていないか見る
- 「重いファイル ワースト10」で、上位に画像が並んでいないか確かめる
- 見つけた画像を、メディアから画像ブロックで挿入し直す
- 元の画像そのものが大きければ、載せる前に縮めてWebPにする
- 直したあと、PageSpeed InsightsでLCPを測り直す
ページ重量診断は、WEBツール箱にある無料のツールです。
画像を縮めてWebPにする手順は「画像をWebPに変換・リサイズする方法」で、実測つきで紹介しています。
ある日から急に遅くなったとき
何も変えていないのに急に遅くなったなら、直前に起きたことを思い出すのが近道です。
当方が運用しているWordPressサイトでも、次のような例がありました。
| 起きたこと | 遅さ | 直したあと |
|---|---|---|
| キャッシュの保存場所のフォルダーを移したら、キャッシュのプラグインがページの保存を止めた | ある記事が毎回6〜21秒 | 0.11〜0.15秒 |
| 外部サイトのブログカードが多い記事で、カードの情報を毎回取りに行っていた | 本文の組み立てに初回11秒 | カードを保存する設定にして0.02秒 |
1つ目は、使っていたWP Rocketが、キャッシュの保存場所が見つからないとページの保存を止める作りだったために起きました。
エラーも出ず、見た目も変わらないので、測るまで気づけていません。
キャッシュのプラグインを使っているなら、ログアウトした状態で同じページを2回開き、2回目が速くなるかを確かめましょう。
ほかに、直前のプラグインやテーマの更新、PHPのバージョンの変更、サーバー会社の障害も原因になりえます。
更新の直後なら、バックアップを取ったうえでその更新を1つずつ戻し、測り比べれば原因を絞り込めるでしょう。
WordPressを速くする順番
原因が1つに決まらないときは、効き目が大きく、戻しやすいものから順に試します。
- 遅いページのTTFBとLCPを測り、記録しておく
- ログアウトした状態で、ページのキャッシュが効いているか確かめる
- Query Monitorで、時間のかかっている処理とプラグインを探す
- 重い画像を、メディアからの挿入とWebP化で軽くする
- PHPを、プラグインが対応する新しいバージョンに上げる
- ここまでやっても遅ければ、サーバーのプランや会社を見直す
1つ変えるたびに、最初と同じ条件で測り直してください。
2つ以上を同時に変えると、どれが効いたのか、どれが悪さをしたのかがわからなくなります。
キャッシュの設定は「WP Rocketの設定方法」、PHPの上げ方は「WordPressのPHPバージョンを確認する方法」で解説しています。
表示の指標をひと通り見直すなら、「WordPressのCore Web Vitals改善方法」もあわせてどうぞ。
よくある質問
Q. プラグインの数を減らせば速くなりますか？
数より、中身が問題です。
今回の検証では、たった1つのプラグインで約3秒遅くなりました。
やみくもに減らす前に、Query Monitorで時間を使っているプラグインを見つけるほうが早道です。
Q. 自分のパソコンでは速いのに、遅いと言われます。
ブラウザーには一度読み込んだ画像やファイルが残るので、2回目以降は速く見えます。
シークレットウィンドウで開くか、PageSpeed Insightsで測ると、初めての訪問者に近い条件で確かめられます。
スマホの回線も見落としやすい点で、今回の画像の検証ではスマホに近い回線で18.8秒かかりました。
Q. PageSpeed Insightsの点数が低いと、遅いということですか？
点数は、決まった条件で測った複数の指標をまとめたものです。
点数よりも、LCPやTTFBの数字そのものを見てください。
実際の訪問者のデータが表示される場合は、そちらを優先します。
Q. サーバーを替えれば速くなりますか？
効くのは、サーバー側が遅い場合だけです。
今回の画像のように表示側が遅い原因は、サーバーを替えても残ります。
TTFBを測ってから判断し、替えるなら「WordPress向けレンタルサーバーの選び方」も参考にしてください。
検証した環境
- WordPress 7.1.4（日本語）、テーマはTwenty Twenty-Five 1.5
- PHP 8.3、共用のレンタルサーバー
- データベースは検証のためSQLiteを使用（MySQLとは速さが違う可能性がある）
- 計測日は2026年10月30日。応答の速さは当方のPCからcurlで10回、画像はChromiumで3回
- Query Monitor 4.1.1
速さは、サーバーや回線、時間帯で変わります。
数字そのものより、条件を変えたときの差を参考にしてください。
まとめ
- 遅いときは、TTFB（サーバー側）とLCP（表示側）を測って、どちらが遅いかを決める
- 自分だけ・管理画面だけ遅いなら、キャッシュの外側で動くプラグインを疑う
- Query Monitorを使うと、時間を使っているプラグインが名指しで出る
- 画像はメディアから挿入すれば、画面に合う大きさが選ばれる。元の画像を直接指定すると重い
- 1つ変えるたびに、同じ条件で測り直す
自分で直すのが難しいときや、原因の切り分けだけ頼みたいときは、MOTOKIのサービスからご相談ください。
ほかのトラブルは「WordPressのエラー一覧」で、画面やメッセージ別に探せます。
