WordPressが重い原因と改善方法｜初心者向けに切り分け・高速化手順を解説

WordPress

WordPressサイトを開いたときに表示が遅いと、「サーバーが悪いのか」「画像が重いのか」「プラグインを減らせばよいのか」と迷いやすいものです。原因を確認しないまま高速化プラグインを追加すると、設定が競合したり、表示が崩れたり、かえって管理が難しくなったりすることがあります。

大切なのは、最初に遅さを再現し、どこで時間がかかっているかを切り分け、影響の小さい改善から一つずつ試すことです。この記事では、WordPress初心者が自分で確認できる範囲を中心に、測定、原因の整理、改善、効果確認、元に戻す方法まで順番に解説します。

作業前には必ずバックアップを用意し、変更をまとめて行わないようにしてください。管理画面に入れない、エラーが出る、契約サーバーの制限が分からないといった場合は、無理に進めずサーバー会社や制作者へ相談する判断も必要です。

WordPressが重いと感じる状態を整理する

「重い」という言葉には、いくつかの異なる状態が含まれます。サイト全体の表示が遅い場合もあれば、特定のページだけが遅い場合、管理画面だけが遅い場合、クリック後の反応だけが鈍い場合もあります。まず症状を分けると、確認すべき範囲を絞りやすくなります。

  • トップページも記事ページも表示開始まで時間がかかる
  • 画像が多いページだけ読み込みが終わらない
  • 管理画面へのログインや投稿保存に時間がかかる
  • メニューやボタンを押した後の反応が遅い
  • スマートフォンだけ遅く、パソコンでは気にならない
  • 更新やプラグイン追加の直後から急に遅くなった

一時的な通信混雑や端末側の問題もあるため、別の端末や回線でも確認します。自宅のWi-Fiだけでなくスマートフォン回線でも試し、ブラウザのシークレットウィンドウを使うと、キャッシュや拡張機能の影響を切り分けやすくなります。

改善前に記録しておくこと

高速化は、変更前後を比べて初めて効果を判断できます。体感だけでは、その日の通信状況やキャッシュの有無に左右されます。作業を始める前に、対象URL、測定日時、端末、回線、測定結果、変更内容を簡単に記録しておきましょう。

比較用には、トップページ、代表的な記事、画像が多いページ、問い合わせページなど、性質の違うページを数件選びます。ログイン中の管理者にはキャッシュが効かない設定もあるため、ログアウトした状態でも確認します。

作業履歴には「画像を差し替えた」「プラグインAの設定を変更した」「プラグインBを停止した」のように、一つの変更を一行で残します。問題が起きたとき、どの変更を戻せばよいか判断しやすくなります。

作業前にバックアップと復元方法を確認する

高速化の設定は、キャッシュ、画像配信、HTMLやCSSの圧縮、データベースなど、サイト表示の中心部分に触れることがあります。変更前には、WordPressのファイルとデータベースの両方をバックアップします。

バックアップは作成しただけで安心せず、保存先、作成日時、復元手順も確認してください。サーバー会社の自動バックアップを使う場合は、対象範囲や保存期間、復元の申し込み方法が契約によって異なります。管理画面の説明や公式マニュアルで確認します。

更新前後の差が大きいサイトでは、利用者の少ない時間帯に作業する、テスト環境で先に確認する、連絡先を用意する、といった準備も有効です。公開中のサイトで直接試す場合は、元に戻せる小さな変更に限定します。

PageSpeed Insightsで現状を測る

公開されているページの確認には、GoogleのPageSpeed Insightsを利用できます。調べたいURLを入力すると、実際の利用状況に基づくフィールドデータがある場合はその情報と、一定条件で計測したラボデータが表示されます。実際の利用者データが十分でない新しいサイトでは、フィールドデータが表示されないことがあります。

最初は点数だけを追わず、モバイルとデスクトップの違い、どのページで問題が大きいか、診断項目に何が挙がるかを見ます。ラボデータは原因調査の手がかりになりますが、実際の端末や回線での体験を完全に再現するものではありません。自分の端末での確認と組み合わせます。

Core Web Vitalsでは、読み込みの体感を表すLCP、操作への反応を表すINP、表示のずれを表すCLSが中心です。数字を一度にすべて改善しようとせず、最も悪いページと最も大きな問題から着手します。

WordPressのサイトヘルスを確認する

WordPress管理画面の「ツール」から「サイトヘルス」を開くと、サイトの構成や推奨される改善項目を確認できます。重大な問題とおすすめの改善が分かれて表示されるため、まず重大な問題がないか見ます。

古いPHP、必要なモジュールの不足、バックグラウンド更新の問題、停止中の機能などが表示されることがあります。ただし、表示された項目を見てサーバー設定をすぐ変更するのは避けてください。PHPの切り替えはテーマやプラグインの互換性に影響するため、バックアップと対応状況の確認が先です。

サイトヘルスの「情報」タブには、WordPress、テーマ、プラグイン、サーバー、データベースなどの情報があります。サポートへ相談するときに役立ちますが、公開の問い合わせ欄へそのまま貼ると、環境情報が含まれる場合があります。送付先と必要範囲を確認して扱います。

画像の容量と表示サイズを見直す

初心者のサイトで効果が出やすい改善の一つが画像です。カメラやデザインツールから書き出した大きな画像を、そのまま記事へ入れると、画面上では小さく表示されていても大きなファイルを読み込むことがあります。

まず、アイキャッチ、本文画像、背景画像など、表示が遅いページで使われている画像を確認します。必要な表示幅に対して極端に大きい画像は、縦横比を保ったまま適切な大きさへ縮小します。写真は内容に適した圧縮を行い、文字や図が読みにくくならない範囲で容量を下げます。

画像を差し替えた後は、パソコンだけでなくスマートフォンでも確認します。ぼやけていないか、トリミングが変わっていないか、代替テキストが残っているかも見ます。既存画像を一括変換する処理は影響が広いため、少数のページで試してから広げます。

遅延読み込みは、画面外の画像を必要になるまで読み込まない仕組みです。WordPressやテーマに標準機能がある場合、別のプラグインと二重に働かせないよう注意します。二重設定は表示のちらつきや画像が出ない原因になることがあります。

プラグインの影響を安全に切り分ける

プラグインは数が多いだけで必ず遅くなるわけではありません。処理内容、読み込むファイル、外部通信、データベースへの問い合わせなどによって負荷は変わります。そのため、件数だけで判断せず、更新や追加の時期と症状が始まった時期を照らし合わせます。

利用していないプラグインは、機能とデータの扱いを確認して整理します。停止だけでデータが残るもの、削除時に設定を消すもの、他の機能が依存しているものがあります。分からないまま一括削除せず、公式説明とバックアップを確認します。

原因調査でプラグインを停止する場合は、影響の少ないテスト環境が理想です。公開サイトで行うなら、アクセスの少ない時間に一つずつ停止し、対象ページ、フォーム、ログイン、決済など重要機能を確認してから次へ進みます。原因候補が見つかったら、代替手段を検討するか、開発元へ問い合わせます。

キャッシュや圧縮を行うプラグインを複数使うと、同じ機能が重なることがあります。ページキャッシュ、ブラウザキャッシュ、画像最適化、CSSやJavaScriptの圧縮がどの仕組みで提供されているかを整理し、役割が重複しない構成にします。

テーマと追加機能の読み込みを確認する

テーマは見た目だけでなく、ページごとに読み込むCSS、JavaScript、フォント、画像、ウィジェットにも関係します。スライダー、動きの多い演出、動画背景、外部フォント、SNS埋め込みなどは、必要性と表示速度のバランスを考えます。

使っていない機能がテーマ設定で無効化できる場合は、まず設定で止めます。テーマファイルを直接編集すると、更新で変更が消えたり、記述ミスで表示できなくなったりします。コード変更が必要なら、子テーマやテスト環境を使える制作者へ相談する方が安全です。

テーマを変更して速度を比較する方法もありますが、公開サイトでの変更はレイアウト、メニュー、ウィジェット、ブロック表示に影響します。高速化だけを目的に安易に切り替えず、ステージング環境で再現し、見た目と機能の両方を確認します。

キャッシュを理解して一つずつ設定する

キャッシュは、毎回同じ処理をやり直さず、用意した結果を再利用して表示を速くする仕組みです。サーバー側のページキャッシュ、ブラウザキャッシュ、CDNのキャッシュなど、複数の場所に存在します。

契約サーバーにキャッシュ機能がある場合は、先に公式マニュアルを確認します。サーバー機能とプラグイン機能を同時に有効にすると、更新内容が反映されない、ログイン状態の表示が混ざる、フォームで古い情報が表示されるなどの問題が起きることがあります。

設定後は、ログアウト状態で記事を開き、更新した文章や画像が正しく見えるか確認します。問い合わせフォーム、会員ページ、カートなど、利用者ごとに内容が変わるページはキャッシュ除外が必要な場合があります。除外条件が分からない場合は、運営会社や制作者へ確認します。

表示がおかしくなったら、まず新しい設定を元へ戻し、関係するキャッシュを正しい手順で削除します。キャッシュ削除を何度も繰り返す前に、どの層のキャッシュを消しているかを区別することが大切です。

CSSとJavaScriptの最適化は慎重に行う

PageSpeed Insightsでは、使用していないCSSやJavaScript、表示を妨げるリソースなどが候補として示されることがあります。しかし、診断に表示されたファイルを削除すればよいとは限りません。ページの操作やレイアウトに必要な処理が含まれている可能性があります。

圧縮、結合、読み込み順の変更、遅延実行などは、設定によってメニュー、スライダー、フォーム、アクセス解析、広告表示が動かなくなることがあります。初心者は機能を一つずつ有効にし、主要ページと主要操作を確認します。

不具合が出たときに除外するファイルを特定できない場合は、最適化機能を無理に維持しません。元に戻し、診断結果と対象URL、発生する操作をまとめて専門家へ相談します。点数を上げるために必要な機能を壊してしまっては、本来の目的から外れます。

サーバーとPHPの状態を確認する

画像やプラグインを見直しても表示開始まで長く待つ場合は、サーバー側の処理が原因かもしれません。同じサーバー内の混雑、契約プランの資源、PHP処理、データベース、外部サービスへの通信など、WordPress管理画面だけでは判断しにくい要因があります。

サーバー会社の管理画面で、障害やメンテナンス情報、アクセス状況、容量、PHPバージョン、エラーログなど、契約内で確認できる項目を見ます。設定名称は会社ごとに異なるため、公式マニュアルに従います。

PHPを新しい対応バージョンへ変更すると、性能や安全性の面で改善が期待できる場合がありますが、テーマとプラグインが対応していることが前提です。バックアップを取り、互換性を確認し、切り替え後にサイト全体をテストします。管理画面が開かない場合に元へ戻す方法も事前に確認します。

アクセスが集中する時間だけ遅い、管理画面も同時に遅い、エラーログに同じ記録が続くといった場合は、測定日時とログを添えてサーバー会社へ問い合わせると、状況を伝えやすくなります。

データベースの整理は削除範囲を確認する

長く運営したWordPressでは、投稿リビジョン、期限切れの一時データ、スパムコメント、削除済みプラグインの設定などが蓄積することがあります。ただし、データベースの容量が大きいことと、表示が遅い原因であることは同じではありません。

最適化プラグインで一括削除する前に、何を削除する機能なのか、復元できるのかを確認します。注文、問い合わせ、会員、アクセス解析などのデータをWordPress内に保存しているサイトでは、不要に見えるテーブルが業務上必要な場合があります。

初心者が直接SQLを実行したり、分からないテーブルを削除したりするのは避けます。バックアップを取得し、対象と影響を説明できない場合は、管理会社や制作者へ依頼してください。データベース整理は、原因が明確で他の改善だけでは足りないときに検討します。

外部サービスと埋め込みを減らす

WordPress本体が軽くても、外部サービスの読み込み待ちで遅くなる場合があります。動画、地図、SNS投稿、予約システム、チャット、広告、計測タグ、外部フォントなどが代表例です。

ページ内の埋め込みを一時的に外して比較すると、影響を確認できます。全ページに必要でない機能は、必要なページだけで読み込む構成を検討します。たとえば地図が問い合わせページにしか必要ないなら、すべての記事で同じ処理を読み込む必要はありません。

外部サービスは相手側の応答時間にも左右されます。重要な機能なら削除するのではなく、読み込み方法、代替表示、遅延読み込み、障害時の案内を含めて設計します。契約や計測に関わるタグは、目的と担当者を確認してから変更します。

管理画面だけ重いときの確認ポイント

公開ページは速いのに管理画面だけ遅い場合、公開ページ向けのキャッシュでは改善しないことがあります。プラグインの管理画面処理、バックグラウンド処理、外部APIとの通信、大量の投稿やメディア、サーバー資源などを確認します。

どの操作が遅いかを分けて記録してください。ログイン、投稿一覧、編集画面、画像アップロード、更新処理など、場所によって原因候補が変わります。特定プラグインの画面だけ遅いなら、そのプラグインの更新履歴やサポート情報を確認します。

自動バックアップ、セキュリティ検査、リンク確認などの処理が重なる時間帯に遅くなることもあります。実行時刻をずらせるか、サーバーの定期処理やCronの状態を確認できるかを運営会社へ相談します。

改善は影響が小さい順に進める

原因候補が複数あるときは、変更のリスクと戻しやすさで順番を決めます。次の流れなら、初心者でも状況を見失いにくくなります。

  1. 対象URLと症状を記録し、別端末と別回線で再現する
  2. PageSpeed Insightsとサイトヘルスで手がかりを集める
  3. バックアップと復元方法を確認する
  4. 大きな画像や不要な埋め込みを少数ページで見直す
  5. 使っていないプラグインや重複機能を一つずつ整理する
  6. サーバー標準のキャッシュ機能と既存設定を確認する
  7. テーマ、外部通信、PHP、データベースは必要に応じて相談する
  8. 変更後に同じ条件で測定し、表示と主要機能を確認する

一度に複数を変更すると、改善した理由も不具合の原因も分からなくなります。一つ変更したら、対象ページだけでなく、トップページ、記事、フォーム、スマートフォン表示、ログインなどを確認します。

変更後の確認で見落としやすい項目

表示速度が上がっても、機能が壊れていれば完了ではありません。キャッシュやスクリプト最適化の後は、次の項目を確認します。

  • 更新した記事や画像がログアウト状態でも反映されている
  • スマートフォンでメニューやボタンが操作できる
  • 問い合わせフォームを送信でき、通知メールが届く
  • 検索、絞り込み、スライダーなどの動きが正常である
  • アクセス解析や必要な計測が継続している
  • 画像のぼやけ、表示遅れ、レイアウトのずれがない
  • 管理画面で投稿の保存や画像アップロードができる

同じURLを同じ端末条件で測り、変更前の記録と比べます。数値が一度だけ良くなった場合は偶然の可能性があるため、時間をおいて複数回確認します。改善が小さく、運用の手間や不具合リスクが大きい設定は、元へ戻す選択も合理的です。

自分で直す範囲と依頼する範囲を分ける

画像の縮小、不要な埋め込みの見直し、利用していない機能の確認、公式マニュアルに沿った設定確認は、比較的取り組みやすい作業です。一方で、サーバーログの解析、データベースの直接操作、テーマやプラグインのコード変更、キャッシュ除外の設計は専門知識が必要です。

次の状態では、無理に進めず相談を検討してください。

  • 500エラーや真っ白な画面が発生している
  • 管理画面へ入れず、設定を戻せない
  • バックアップから復元する方法を確認できない
  • フォーム、決済、会員機能など業務に直結する機能がある
  • 特定時間の負荷やサーバーログの調査が必要である
  • CSSやJavaScriptの除外対象を判断できない
  • 改善してもすぐ遅さが再発する

相談時には、遅いURL、発生日時、端末と回線、直前の変更、測定結果、試したこと、元へ戻したことをまとめます。「サイトが遅い」だけより、調査を始めやすくなります。

WordPressの重さを再発させない運用

高速化は一度で終わる作業ではありません。記事や画像、プラグイン、外部サービスが増えると、サイトの状態は変わります。月に一度など無理のない間隔で、代表ページの表示、サイトヘルス、更新状況、容量を確認します。

新しいプラグインや埋め込みを追加するときは、目的、担当者、対象ページ、削除条件を記録します。画像を投稿する前のサイズや圧縮ルールも決めておくと、後から大量に直す手間を減らせます。

WordPress公式のサイトヘルスやGoogleの測定ツールを手がかりにしつつ、実際の利用者が目的を達成できるかを中心に判断してください。満点を目指すより、主要ページが安定して表示され、更新や問い合わせが正常に動く状態を保つことが重要です。

症状別に最初の確認先を決める

遅さの現れ方から確認先の優先順位を決めると、関係の薄い設定を触らずに済みます。次の例は原因を断定するものではありませんが、調査を始める順番の目安になります。

ページを開いてから何も表示されない時間が長い場合は、サーバー側の処理、データベース、外部通信を疑います。複数ページで同じ症状が出るか、管理画面も遅いか、障害情報が出ていないかを確認します。サーバーの応答が始まる前の問題は、画像を小さくするだけでは改善しない場合があります。

文字はすぐ表示されるのに大きな画像だけ遅れて出る場合は、アイキャッチやファーストビュー画像の容量、寸法、配信形式を確認します。PageSpeed InsightsでLCPの対象として画像が示された場合は、その画像から見直します。ただし、見た目に必要な品質を失うほど圧縮しないようにします。

ページが一度表示された後、ボタンやメニューの反応が鈍い場合は、JavaScript、広告、チャット、SNS埋め込みなどの影響を調べます。クリックできない、二度押しが必要、スクロールが引っかかるといった操作も記録します。該当する機能を提供するプラグインや外部サービスを確認し、必要なページだけで使えるか検討します。

最初のアクセスだけ遅く、二回目は速い場合は、キャッシュの有無やサーバーが処理を始めるまでの違いが関係している可能性があります。シークレットウィンドウで複数回確認し、キャッシュを消した直後と通常時を分けて記録します。二回目だけ速いことを理由に、初回利用者の遅さを無視しないようにします。

スマートフォンだけ遅い場合は、通信速度だけでなく、モバイル向けに表示される画像、広告、メニュー、フォント、追従パーツも確認します。パソコンと同じ大きな画像や複雑な演出を読み込んでいないか、実機で操作しながら見ます。

更新直後から急に遅くなった場合は、直前に更新したWordPress本体、テーマ、プラグインを記録します。いきなり古い版へ戻さず、既知の不具合、追加された処理、サーバーのエラーログを確認します。復元が必要なときは、事前に用意したバックアップと公式の手順を使います。

一時間で行う初回診断の進め方

時間を決めずに調査すると、点数を追い続けたり、関係の薄い設定まで変更したりしがちです。初回は一時間を目安に、変更よりも状況把握を優先します。

最初の十分で、遅いURLを三つまで選び、端末、回線、発生時刻、症状を書きます。別回線とシークレットウィンドウで再現し、サイト全体か特定ページかを分けます。管理画面だけ遅い場合は、遅い操作名も残します。

次の十五分で、PageSpeed Insightsをモバイルとデスクトップの両方で確認します。代表URLごとに、フィールドデータの有無、LCP、INP、CLS、目立つ診断項目を記録します。ここでは点数を上げる作業を始めず、共通している問題を探します。

続く十分で、WordPressのサイトヘルス、更新待ち、利用中のテーマ、プラグイン一覧を確認します。最近追加・更新したものに印を付けます。サーバーの障害情報と容量も確認できれば見ます。パスワードや環境情報は診断メモへ書きません。

次の十五分で、最も遅いページを開き、大きな画像、動画、地図、SNS、広告、チャットなどを数えます。画像の元サイズが分かる場合は表示サイズとの差を確認します。全ページ共通の要素と、そのページだけの要素を分けます。

最後の十分で、最初に試す変更を一つだけ決めます。「最大のアイキャッチを縮小する」「不要な地図埋め込みを外して比較する」「重複しているキャッシュ機能を公式手順で整理する」など、戻しやすく、効果を測りやすいものを選びます。バックアップがない場合は、変更を始めずバックアップ準備を次の作業にします。

改善記録に残す項目

速度改善は、数日後に別の担当者が見ても分かる記録にしておくと安全です。表計算や運用メモに、対象URL、変更前の症状、測定条件、変更内容、変更日時、担当者、確認結果、戻し方を残します。

画像なら元ファイル名、差し替え後の寸法と容量、代替テキストの確認を書きます。プラグインなら名称、変更した設定、キャッシュ削除の有無、確認したページを残します。サーバー設定なら、変更前後の値と公式マニュアルの場所を記録します。

結果は「点数が上がった」だけでなく、「スマートフォンで体感が改善した」「フォーム送信は正常」「画像の品質に問題なし」のように、利用者と運用の両方で記録します。改善がなかった変更も残しておくと、同じ作業を繰り返さずに済みます。

元に戻した場合は失敗として消さず、「表示崩れが出たため設定を戻した」「キャッシュ削除後に復旧した」と書きます。トラブルの再発時に重要な情報になります。

まとめ

WordPressが重いときは、すぐに高速化プラグインを追加するのではなく、症状を分け、変更前の状態を測り、原因候補を一つずつ確認します。画像、プラグイン、テーマ、キャッシュ、外部サービス、サーバー、データベースは互いに関係するため、まとめて変更しないことが安全な改善の基本です。

バックアップと復元方法を確認し、影響の小さい変更から進め、同じ条件で効果を測ります。表示速度だけでなく、フォームやメニュー、投稿保存などの機能も確認してください。自分で原因を説明できない設定や、業務に直結する機能が関わる場合は、記録を整理してサーバー会社や制作者へ相談しましょう。

参考にした公式情報