WordPress高速化の正攻法。パフォーマンスオーディットで原因を特定する手順

WordPress高速化の正攻法。パフォーマンスオーディットで原因を特定する手順

WordPressサイトの表示速度が低下した際、多くの運営者は反射的にキャッシュプラグインを導入しようとする。しかし、根本的な原因を特定せずにツールを重ねる手法は、期待したほどの効果を生まないことが多い。元記事の著者であるMark Zahra氏は、場当たり的な対応ではなく、体系的な「パフォーマンスオーディット（性能調査）」の重要性を説いている。

パフォーマンスオーディットとは、適切なツールを正しい順序で使用し、サイトの遅延を招いている真の要因を突き止める作業だ。本稿では、無料ツールのみを用いて、コードに触れることなくサイトのボトルネックを特定する具体的なステップを解説する。

このプロセスを実践することで、サーバーの応答速度、画像の最適化不足、あるいは特定のプラグインによる負荷など、改善すべき優先順位が明確になるはずだ。

Google Search Consoleで「現場のデータ」を把握する

高速化調査の第一歩は、スピードテストツールを回すことではない。まずはGoogle Search Console（グーグル・サーチコンソール）を開き、左サイドメニューの「エクスペリエンス」内にある「ウェブに関する主な指標」を確認することから始めるべきだ。

多くのガイドがこの手順を飛ばしてシミュレーションテストに移行してしまうが、それは誤りだと指摘されている。Search Consoleが提供するのは「フィールドデータ」と呼ばれるもので、過去28日間に実際の訪問者が体験したパフォーマンスの記録である。Googleが検索順位の決定に使用するのは、シミュレーション値ではなく、この実測データの方だ。

CWV（コアウェブバイタル）のステータスを確認する

レポートでは、ページが「良好」「改善が必要」「不良」の3つのカテゴリに分類される。ここで重要なのは、どの指標が問題を引き起こしているかを特定することだ。例えば、LCP（Largest Contentful Paint / 最大視覚コンテンツの表示時間）に問題があるサイトと、CLS（Cumulative Layout Shift / 視覚的な安定性）に問題があるサイトでは、必要な対策が全く異なる。

LCPとは、ページ内で最も大きなコンテンツ（通常はヒーロー画像や見出し）が表示されるまでの時間を指す。一方、CLSは読み込み中にレイアウトがガタつく度合いを示す指標だ。これらを区別せずに「なんとなく高速化プラグインを入れる」だけでは、特定の問題を解決することはできない。

なお、アクセス数が少ないサイトや公開直後のサイトでは、データが表示されない場合がある。その場合は、次のステップであるPageSpeed Insightsによる診断へ進むことになる。

PageSpeed Insightsでボトルネックを深掘りする

次に、Search Consoleで「不良」と判定されたページや、サイト内で最も重要なページ（通常はトップページや人気記事）のURLをPageSpeed Insights（ページスピード・インサイト / PSI）で測定する。PSIはシミュレーション環境でのテスト結果（ラボデータ）を表示するツールだ。

結果が表示されたら、デスクトップではなく必ず「モバイル」のスコアを重視すべきだ。Googleはモバイル版のパフォーマンスを評価基準とする「モバイルファーストインデックス」を採用しているため、デスクトップで高得点でもモバイルで低得点であれば、改善の優先度は高い。

診断セクションの重要項目を読み解く

PSIのレポートには多くの項目が並ぶが、特に注目すべきは以下の3点だ。まず、TTFB（Time to First Byte / 最初の1バイトが到着するまでの時間）を確認する。これはサーバーがリクエストを受け取ってから、ブラウザに最初のデータを返すまでの時間だ。もしTTFBが600ms（0.6秒）を超えている場合、原因はサーバー側（ホスティング環境）にある可能性が高い。この値が正常であれば、サーバーではなくサイトの構成要素に問題があると判断できる。

次に「レンダリングを妨げるリソース（Render-blocking resources）」をチェックする。これは、ブラウザが画面を表示する前に読み込まなければならないCSSやJavaScriptファイルを指す。ここでの推定短縮時間が1,000msを超える場合は、最優先で対処すべき課題となる。

最後に、どの要素が「LCP要素」として判定されているかを確認する。多くの場合、トップページのヒーロー画像がこれに該当する。画像が適切に圧縮されているか、次世代フォーマット（WebPなど）が使われているか、そして「遅延読み込み（Lazy Load）」が誤って適用されていないかを確認する。ファーストビューの画像に遅延読み込みを適用すると、逆に表示が遅くなり、LCPスコアを悪化させる原因になるからだ。

GTmetrixのウォーターフォール図で読み込み順を可視化する

PSIが「何が起きているか」を教えてくれるのに対し、GTmetrixは「なぜそれが起きているか」を視覚的に理解するのに役立つ。無料アカウントを作成してテストを実行し、「Waterfall（ウォーターフォール）」タブを開くことが推奨されている。

ウォーターフォール図は、ページを構成するすべてのファイルがどの順番で、どれくらいの時間をかけて読み込まれたかを横棒グラフで示したものだ。棒が右に伸びているほど、そのファイルの読み込みに時間がかかっていることを意味する。

グラフから読み取れる遅延のサイン

図の最上部、最初のファイルが読み込まれる前に長い空白時間がある場合は、やはりサーバーの応答速度がボトルネックだ。また、画像ファイルの横棒が極端に長い場合は、ファイルサイズが大きすぎること（未圧縮）を示唆している。

さらに、外部スクリプトの挙動にも注目したい。解析ツール、チャットウィジェット、SNSの埋め込みなどは、読み込みの後半で大きな遅延を引き起こすことが多い。ウォーターフォール図の後半で特定の外部ドメインからの通信が停滞しているのを発見できれば、その機能を停止するか、読み込み方法を最適化する（非同期読み込みなど）といった具体的な対策が打てるようになる。

Query Monitorでサーバー内部の挙動を監視する

これまでのステップはブラウザ側から見た性能調査だったが、最後の手順はサーバー内部の挙動を調査することだ。これには無料プラグインの「Query Monitor（クエリ・モニター）」を使用する。

プラグインをインストールして有効化すると、管理画面の上部ツールバーに数値が表示されるようになる。フロントエンドのページを表示した状態でこの数値をクリックすると、詳細なパネルが開く。開発者でなくても、特定の情報に注目するだけで原因を絞り込むことが可能だ。

データベースクエリとAPIコールの異常を検知する

まずチェックすべきは「Database Queries（データベースクエリ）」のセクションだ。1ページを表示するために発行されたクエリの数と、それぞれの実行時間が表示される。適切に最適化されたサイトであれば、1ページあたりのクエリ数は20〜50個程度に収まる。もし150個を超えていたり、個別のクエリに50ms以上の時間がかかっていたりする場合、特定のプラグインやテーマが非効率な処理を行っている証拠だ。Query Monitorは、どのプラグインがそのクエリを発行したかまで教えてくれる。

もう一つの重要項目は「HTTP API Calls」だ。これは、WordPressがページを生成する過程で外部サービスと通信している記録である。例えば、ライセンス認証や外部データの取得のためにプラグインが外部サーバーへリクエストを送り、その返信を待っている間、サイトの表示はストップしてしまう。もし予期しない外部リクエストが多発しているなら、そのプラグインの設定を見直す必要がある。

優先順位に基づいた改善リストの作成

4つのツールからデータが集まったら、それらを統合して改善の優先順位を決める。著者のMark Zahra氏は、以下の順序で対策を行うことを推奨している。

1. サーバー環境の改善

TTFBが遅い場合は、他のどの対策よりも先にサーバー環境を見直すべきだ。土台となるサーバーが遅ければ、どんなにコードを最適化しても限界がある。パフォーマンスを重視した高品質な国内レンタルサーバーや、マネージドホスティングへの移行を検討するのが最も効果的だ。

2. 画像の最適化

LCPのスコアが低い場合、対象となるヒーロー画像のファイルサイズを削減する。圧縮、WebPへの変換、そしてファーストビュー画像に対する遅延読み込みの解除を行う。これだけでスコアが劇的に改善することも珍しくない。

3. コードの整理とキャッシュ

サーバーと画像がクリアになった段階で、初めてキャッシュプラグインやコードの最適化（CSS/JSの縮小化など）を導入する。Query Monitorで特定された「重いプラグイン」を削除したり、軽量な代替プラグインに差し替えたりすることもこの段階で行う。

4. サードパーティスクリプトの調整

最後に、解析ツールや広告タグなどの外部スクリプトを整理する。これらは利便性とのトレードオフになることが多いため、本当に必要なものだけを残し、遅延読み込みさせるなどの調整を行う。

独自の分析：なぜ「オーディット」が高速化の成否を分けるのか

筆者の見解として、WordPressの高速化において最も大きな障壁は「情報の過多」にあると考える。ネット上には「このプラグインを入れれば速くなる」という断片的な情報が溢れているが、サイトごとに遅延の理由は千差万別だ。あるサイトでは画像が原因であり、別のサイトではデータベースの肥大化が原因かもしれない。

今回紹介した手順の核心は、仮説ではなく「証拠」に基づいて動く点にある。Search Consoleで「何が悪いか」を知り、PSIで「どこが悪いか」を絞り込み、GTmetrixで「読み込みの順序」を確認し、Query Monitorで「内部の犯人」を特定する。この一連の流れは、まさにサイトの健康診断だ。

また、高速化は一度行えば終わりではない。WordPressはプラグインの更新や記事の追加によって、時間の経過とともにパフォーマンスが低下していく傾向がある。数ヶ月に一度、このオーディットをルーチンとして行うことで、サイトの健全性を長期的に維持できるだろう。

この記事のポイント

• 実測データを優先する: Google Search Consoleのフィールドデータが、SEOにおいて最も重要な指標となる。
• サーバーの応答を確認: TTFB（Time to First Byte）をチェックし、問題があればホスティング環境の変更を最優先する。
• LCP要素の特定: ページで最も大きな要素（画像など）を特定し、その読み込みを最速化する。
• 内部負荷の可視化: Query Monitorを使い、プラグインが発行するデータベースクエリや外部通信の異常を突き止める。
• 一歩ずつの改善: 複数の対策を同時に行わず、一つ修正するごとに再テストを行い、効果を検証する。

出典

• WP Mayor「WordPress Performance Audit: How to Find What’s Slowing Down Your Site」（2026年3月25日）

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験