WordPressの表示が重い時、何から確認すべきか｜原因の切り分けを順番に進める簡易診断フロー
目次
【AIによる要約】
– 表示が重いときは「サーバー → プラグイン → テーマ → フロント」の順番に切り分けるのが最短の近道です。
– 管理画面まで重いならサーバー側、管理画面が軽ければプラグイン・テーマ・フロント側に原因が濃厚です。
– 無料ツールの計測と確認順序の型を押さえれば、社内だけでも原因の当たりを付けて外注判断ができます。
「重い」を放置すると、売上と信頼を静かに失います
「最近、サイトの表示が遅い気がする」。そう感じながら、更新のたびに様子見を続けているWeb担当者は少なくありません。
表示速度は体感の問題にとどまりません。Googleはページエクスペリエンスを検索ランキングの要素に含めており、速度が遅いことはSEOにも影響します（出典：Google「Google検索でのページエクスペリエンスの概要」）。
また、私たちカジヤは業界歴10年以上で300社以上のサイトを支援してきました。その経験から言えるのは、「重い」という症状の裏には、サーバーの老化、放置されたプラグイン、肥大化したデータといった、放置すると必ず悪化する原因が潜んでいることが多い、という事実です。自社でも複数のWebサービス・ECサイトを運営している立場から見ても、表示の遅れは問い合わせ・注文の機会損失に直結します。
原因が分からないまま「なんとなく重い」を放置するのは、最も損な選択肢です。この記事では、WordPressの表示が重いときに「何から・どの順で」確認すれば原因に近づけるか、簡易診断フローを順番に解説します。
ECサイト特化のPageSpeed診断中心の記事は別にあります。自社ECサイトの表示が重い――原因はサーバー？プログラム？無料ツールでできる簡易診断と「直すべき場所」の判断基準。本記事はWordPress汎用の「切り分けの順序」に絞ります。
診断の全体像：確認する順番が大事
いきなりキャッシュプラグインを入れたり、サーバーをグレードアップしたりするのは禁物です。原因を特定する前に手を入れると、症状が変化して切り分けがさらに難しくなります。
確認する順番は、基本的に次のとおりです。
- 状況の整理と計測（いつ・どこが・どれくらい重いか）
- サーバーのレスポンス（TTFB）の確認
- サーバーのリソースとログの確認
- プラグインの切り分け
- テーマの切り分け
- フロント（画像・スクリプト）の確認
この順序には理由があります。「サーバーか、WordPress側か」の大きな分岐を先に決めてしまえば、後は範囲を狭めるだけだからです。
ステップ1：状況の整理と計測
確認方法
まず3つの情報を整理します。
- いつから重いのか（特定の作業や更新の直後ではないか）
- どのページが重いのか（全ページか、特定ページか、管理画面もか）
- どれくらい重いのか（体感でなく、ツールで数値を取る）
数値の計測には無料ツールを使います。Googleが提供するPageSpeed Insightsで、URLを入力してモバイル・PC両方のスコアと改善提案を確認してください（出典：Google「PageSpeed Insights」）。同時に、Chromeの検証ツール（F12 →「Network」タブ）で読み込み時間の内訳も見ます。
読み取り方
Networkタブでは、次の2点を見ます。
- 一番時間がかかっているリクエストは何か
- 最初のHTML（ドキュメント）の待ち時間が長いか、画像やスクリプトの読み込みが長いか
次の分岐
- 全ページが重い・管理画面も重い → ステップ2（サーバー）へ
- 特定ページだけ重い・管理画面は軽い → そのページ固有の原因（画像容量、埋め込み、特定のプラグインが作るショートコードなど）
ステップ2：サーバーのレスポンス（TTFB）を確認する
確認方法
Chromeの検証ツールのNetworkタブで、一番上のHTMLリクエストの「Waiting（TTFB）」の時間を確認します。TTFBはTime To First Byteの略で、サーバーが応答を返し始めるまでの時間です。目安として、TTFBが1秒を超えるようならサーバー側の応答が遅いと判断できます（出典：Google「Time to First Byte (TTFB) を最適化する」）。
読み取り方
TTFBが長い場合、主な原因は次のいずれかです。
- サーバーのスペース（プラン）が処理能力に対して足りていない
- データベースのクエリが重い（投稿やメタデータの肥大化）
- 同時アクセスが多く、処理が詰まっている
ポイントは「管理画面の重さ」です。管理画面はキャッシュの恩恵を受けにくいため、フロントと管理画面が両方重ければ、サーバー・データベース寄りの可能性が高くなります。
次の分岐
- 管理画面も重い → ステップ3（サーバーリソース）へ
- 管理画面は軽く、フロントだけ重い → ステップ4（プラグイン）へ進みつつ、キャッシュの有無も確認する
ステップ3：サーバーのリソースとログを確認する
確認方法
レンタルサーバーの管理画面で、次を確認します。
- ディスク使用率（ログやバックアップで満杯になっていないか）
- PHPのバージョン（古いバージョンは速度・セキュリティ両面で不利）
- エラーログに繰り返し出ている警告はないか
読み取り方
ディスクが100%近い場合、WordPressはデータベースへの書き込みに失敗し、極端に重くなったり落ちたりします。私たちが復旧対応で現場に立ち会うケースでも、「ログとバックアップの蓄積でディスクが満杯になっていた」という原因は少なくありません。仕組みと対策は「何もしていないのにサーバーが止まった」――ログとバックアップでディスクが満杯になる仕組みと、定期監視・ローテーションの重要性にまとめています。
「PHPのバージョンアップが必要」と案内が来ているのに放置している場合も、古いPHPの上では処理が遅く、やがて動かなくなるリスクを抱えます。費用が決まる仕組みは「PHPのバージョンアップが必要です」と言われたら？放置するリスクと見積もり金額が決まる仕組みで解説しています。
次の分岐
- ディスク満杯・PHPが古い → その解消が最優先。キャッシュやプラグインの調整は後
- リソースに余裕があるのにTTFBが遅い → データベースの肥大化か、WordPress側の重い処理。ステップ4へ
ステップ4：プラグインを切り分ける
確認方法
プラグインを全部停止して、速度が変わるかを確認します。本番サイトでいきなり停止すると顧客影響があるため、可能ならテスト環境で行ってください。テスト環境がない本番修正がどれほど危険かは、テスト環境（検証用サイト）がない本番修正がどれほど危険か、専門家が分かりやすく解説で解説しています。
切り分けにはWordPress公式プラグインのHealth Check & Troubleshootingも便利です。管理画面から他のプラグインを一時的に無効化した状態（トラブルシューティングモード）で動かせます。ログインしていない訪問者には通常のサイトが見えるため、本番でも比較的安全に確認ができます（出典：WordPress.orgプラグイン「Health Check & Troubleshooting」）。
読み取り方
- 全停止で軽くなる → いずれかのプラグインが原因。半分ずつ戻して、重くなる瞬間を絞り込む
- 全停止しても重い → プラグインは原因ではない可能性が高い。テーマかサーバーへ
次の分岐
原因のプラグインが特定できたら、「停止でよいか」「設定変更で回避できるか」「代替プラグインに置き換えるか」を判断します。動作確認なしの更新で画面が真っ白になる事故は頻発しており、対処法はWordPressの「プラグイン更新通知」を放置するとどうなる？更新で画面が真っ白になった時の対処法で解説しています。
ステップ5：テーマを切り分ける
確認方法
テーマを、WordPress公式のデフォルトテーマ（Twenty Twenty-Fiveなど）に一時切り替えして速度を比べます。プラグインと同様、本番で行うなら訪問者への影響がない時間帯・方法を選んでください。
読み取り方
- デフォルトテーマで軽くなる → テーマ側に重い原因がある（重い処理を書くfunctions.php、大量の読み込み、古いライブラリなど）
- 変わらない → テーマは原因ではない
次の分岐
テーマが原因の場合、子テーマでの修正か、テーマの乗り換えかの判断が必要です。有料テーマはライセンスと更新状況の確認が前提になります。判断基準は購入したWordPress有料テーマが更新されなくなったら？ライセンス切れ・サポート終了の影響と移行の判断基準で解説しています。
なお、テーマやfunctions.phpの修正は、間違えると画面が真っ白になります。エラーが出てログインできないときの初動は、手順を確実に押さえてください（WordPress「重大なエラーが発生しました」の原因特定と管理者の初動 ― ログインできない500エラーの切り分け方）。
ステップ6：フロント（画像・スクリプト）を確認する
確認方法
PageSpeed Insightsの改善提案と、Networkタブの容量ランキングを見ます。
- 画像が原寸・超大容量のまま上がっていないか
- 外部の埋め込み（SNS、動画、広告タグ）が多くないか
- 画像の遅延読み込み（lazy load）が効いているか
読み取り方
HTMLの応答（TTFB）が速いのに全体が遅い場合、原因はほぼこのエリアです。数MB級の画像1枚で、体感速度は激変します。
次の分岐
- 画像の圧縮・遅延読み込みで改善できる → 社内で対応可能な範囲
- テーマ改修やプラグインの調整が必要 → バックアップと検証環境が必須。自社で安全にできる範囲を超えているなら、プロへの相談を推奨します
やりがちな落とし穴
切り分けの現場で何度も見る、注意すべき行動をまとめます。
- 原因特定前にキャッシュプラグインを入れる: 症状が変わって切り分けが不可能になります。キャッシュプラグインは事故も多く、導入前にリスクを確認してください：表示速度改善のために入れたWordPressキャッシュプラグインで事故が起きる理由｜他人のカート情報が見える・更新が反映されない
- 本番環境でプラグインを全部停止する: 問い合わせが止まり、ECであれば売上を直接失います
- スコアだけを見て手を入れる: PageSpeedの点数は手段であって目的ではありません。TTFBと実際の表示を押さえるのが先です
- アクセス集中を原因から外す: 特定の時間帯だけ重いなら、キャンペーンやクローラー、不正アクセスの疑いもあります。事前の負荷対策の考え方はテレビ取材・プレスリリースでサーバーが落ちる前に｜アクセス集中への事前負荷対策と相談基準で解説しています
自社で対応する範囲と、プロに任せる範囲
この診断フローで、ステップ1〜3（計測・TTFB確認・サーバー管理画面の確認）までは、担当者でも安全に実施できます。
一方、ステップ4以降（プラグイン・テーマの停止と検証）は、バックアップからの復元手順、テスト環境での確認、失敗時の切り戻しまで含めて初めて安全です。私たちは300社以上の支援で、バックアップ取得→テスト環境検証→本番反映→実機テスト→切り戻し準備、という工程を省略した修正で起きた事故を繰り返し見てきました。この裏側の工程があるからこそ、軽く見える調査・修正にもそれなりの手間と費用がかかります。
判断基準は明確に言えます。「数値の計測と状況整理まで」は自社で行い、「WordPress本体・プラグイン・テーマへの変更を伴う対応」は検証環境を持つプロに任せる。この境界を越える場合、代理店を挟まずエンジニアと直接取引できる体制かどうかも、選定の重要な視点です。原因の説明と対応の責任が一本になるためです。
診断の結果、サーバーの老化や構成の見直しが必要と出た場合、日々の監視と定期的なメンテナンスで「重くなる前に潰す」運用が現実的な解になります。当社のWebサイト保守管理サービスでは、この診断フローの型をベースに、月次での状況確認と改善提案までを一貫して行っています。まずは現状の計測結果を持って、一度ご相談ください。
