WordPressの表示速度：高速化の手順と原因

この記事の要点：

WordPress の表示速度は、PageSpeed Insights などで「どの指標が遅いか」を先に測り、原因を 1 つずつ切り分けてから直します。高速化のプラグインを先に入れると、何が効いたか分からなくなります。
遅さの原因は、サーバーの応答（TTFB）、最初の画面の画像、描画を止める CSS・JavaScript・Web フォント、プラグインが足すスクリプトの 4 つに分けると探しやすくなります。
目安は Core Web Vitals の基準で、LCP は 2.5 秒以下、INP は 200 ミリ秒以下、CLS は 0.1 以下が「良好」です。実際の利用者の 75 パーセンタイルで判定します。
当サイト（seoagent.jp）では、描画を止める Web フォントと Google タグの重複、大きすぎるロゴ画像が主な原因でした。画像と計測タグの読み込みを見直し、Lighthouse のモバイルの値（ラボ値）が改善しました。

WordPressの表示速度は、測ってから原因を絞って直す

WordPress の表示速度を上げるには、まず計測で「遅い指標」と「遅い原因の候補」を確かめ、原因を 1 つずつ直して同じ条件で測り直します。WordPress はページを開くたびに PHP とデータベースで HTML を組み立てる仕組みのため、サーバー側の処理と、ブラウザでの表示の両方に遅くなる原因があります。どちらが遅いかで、打つ手がまったく変わります。

よくある失敗は、高速化のプラグインやキャッシュの設定を一度にいくつも入れることです。表示が速くなったとしても、どの変更が効いたのか、どれが不要だったのかが分からず、後で表示の崩れが起きたときに戻す場所も分かりません。1 回に 1 つだけ変え、変える前と後を同じ道具・同じ端末の設定で比べるのが基本です。

速度の目安には、Core Web Vitals を使います。web.dev の「Web Vitals」は、LCP（最も大きな要素が表示されるまでの時間）を 2.5 秒以内、INP（操作への応答）を「200 ミリ秒以下」、CLS（表示のずれ）を「0.1 以下」とし、モバイルとパソコンに分けたページ読み込みの 75 パーセンタイルで判定するとしています（web.dev：Web Vitals、最終更新日 2024年10月31日、2026年10月13日確認）。各指標の意味と基準は「コアウェブバイタルとは」で説明しています。この記事では、WordPress に特有の原因の切り分け方と、当サイトで実際に測って直した記録を中心に説明します。

WordPressが遅くなる主な原因

WordPress が遅くなる原因は、サーバーの応答、画像、描画を止めるファイル、プラグインやテーマが足すスクリプトの 4 つに大きく分けられます。原因ごとに遅くなる指標が違うため、指標を見れば原因の見当がつきます。

原因	WordPressでよくある例	遅くなりやすい指標
サーバーの応答	ページのキャッシュが無い、PHP の版が古い、データベースの処理が重い、サーバーの性能が足りない	TTFB（最初の 1 バイトが届くまでの時間）、その結果として LCP
画像	アップロードした大きな画像をそのまま表示、最初の画面の画像まで遅延読み込み、幅と高さの指定が無い	LCP、CLS
描画を止めるファイル	テーマやプラグインの CSS、同期で読み込む JavaScript、Web フォントの読み込み待ち	FCP（最初に何かが表示されるまでの時間）、LCP
追加のスクリプト	計測タグの重複、チャットや SNS の埋め込み、使っていないプラグインの読み込み	INP、TBT（メインスレッドが止まっている時間）

WordPress に特有なのは、プラグインやテーマが「すべてのページ」に CSS や JavaScript を足すことがある点です。問い合わせフォームのプラグインが、フォームの無い記事にもファイルを読み込ませる、といった形です。プラグインの数そのものより、各プラグインが何を読み込んでいるかが速度に関係します。

サーバーの性能や PHP の版は、ホスティング会社の管理画面で確かめます。WordPress.org は、推奨する環境として「PHP version 8.3 or greater」、MariaDB 10.11 以上または MySQL 8.0 以上、HTTPS への対応を挙げています。PHP 7.4 以上でも動くものの、古い版は公式のサポートが終わり、安全上の問題がありうるとしています（WordPress.org：Requirements、2026年10月13日確認）。版は更新されるため、変更前に公式の要件のページを確かめてください。

表示速度の測り方：実際の利用者のデータとラボのデータ

WordPress の表示速度は、PageSpeed Insights で「実際の利用者のデータ」と「ラボのデータ」を分けて確かめます。PageSpeed Insights は、Chrome の利用者から集めた実測（CrUX）と、Lighthouse による模擬計測（ラボ）の両方を表示するツールです。公式の説明は、ラボデータは制御された環境で集めるため問題のデバッグに役立つとし、実測のデータは過去 28 日間の期間を表すとしています（PageSpeed Insights について、最終更新日 2025-07-25、2026年10月13日確認）。Google 検索のランキングで考慮されるのは実際の利用者の Core Web Vitals で、Lighthouse の点数そのものではありません。

データ	何を表すか	使い方
実際の利用者のデータ（CrUX）	過去 28 日間に Chrome で開いた人の体験。75 パーセンタイルで判定	合格しているかの判断。アクセスが少ないページやサイトでは表示されない
ラボのデータ（Lighthouse）	決まった端末・回線の条件で 1 回読み込んだ結果	原因の調査と、変更前後の比較
Search Console の「ウェブに関する主な指標」	サイト全体の URL を「良好」「改善が必要」「不良」に分けた実測の集計	どのページの群が遅いかを見つける

アクセスの少ない新しいサイトでは、実測のデータが表示されないことがよくあります。その場合はラボのデータで原因を調べますが、ラボの点数が上がったことを「利用者の体験が良くなった」とそのまま読み替えないようにします。ラボの TBT は、操作への応答を表す INP の代わりにはなりません。PageSpeed Insights の画面の読み方は「PageSpeed Insightsの使い方」で説明しています。

ラボの値は、計測するたびに揺れます。1 回の点数で判断せず、同じ URL を同じ設定で複数回測り、中央値や範囲で比べます。トップページだけでなく、記事・一覧など種類の違うページも測ります。WordPress ではテンプレートごとに読み込むファイルが違うため、トップは速くても記事が遅い、ということが起きます。

原因の切り分けの順番：TTFB、LCPの要素、画像、スクリプト

原因は、サーバーの応答（TTFB）、LCP の要素、画像、描画を止めるファイル、スクリプトの順に確かめると、効果の大きいところから見つけられます。web.dev の「Largest Contentful Paint を最適化する」は、LCP の時間を「Time to First Byte（TTFB）」「リソース読み込みの遅延」「リソースの読み込み時間」「要素のレンダリングの遅延」の 4 つのサブパートに分け、「すべてのページの LCP 値は、この 4 つのサブパートに分類できます」としています（web.dev：Largest Contentful Paint を最適化する、最終更新日 2025年3月31日、2026年10月13日確認）。どのサブパートが長いかで、直す場所が決まります。

TTFB を見る：PageSpeed Insights の診断にある「最初のサーバー応答時間」や、実測の TTFB を確かめます。ここが遅い場合は、ページのキャッシュ（サーバーのキャッシュ機能やキャッシュのプラグイン）、PHP の版、サーバーの性能から見ます。画像を軽くしても TTFB は縮みません。
LCP の要素を特定する：診断の「最大コンテンツの描画要素」で、何が LCP になっているかを確かめます。画像なら画像の大きさと読み込みの順番、文字ならフォントと CSS が対象です。
最初の画面の画像を直す：LCP の画像は遅延読み込み（loading=”lazy”）にせず、表示する大きさに合った画像を配信します。WordPress は本文の画像に srcset（画面の幅に合わせて大きさの違う画像を選ばせる指定）と遅延読み込みを自動で付けますが、テーマが独自に出す画像には付かないことがあります。
描画を止めるファイルを減らす：「レンダリングを妨げるリソースの除外」に出る CSS・JavaScript・Web フォントを確かめます。テーマとプラグインのどちらが読み込んでいるかを、ファイルの URL（/wp-content/themes/ か /wp-content/plugins/ か）で見分けます。
スクリプトを見直す：「メインスレッドの処理」「第三者のコード」に出るスクリプトを確かめます。計測タグや埋め込みは、重複していないか、表示の後に読み込めないかを検討します。

プラグインが原因かどうかは、検証用の環境でプラグインを 1 つずつ停止して測り直すと確かめられます。WordPress の公式の手引き（Advanced Administration Handbook）も、性能の改善の最初の方法としてプラグインを挙げ、「Try selectively disabling plugins to measure server performance.」（プラグインを選んで停止し、サーバーの性能を測る）としています（WordPress Developer Resources：Optimization、2026年10月13日確認）。

本番のサイトで一度に止めると、フォームや計測が止まるおそれがあるため、バックアップを取ったうえで、検証用の環境（ステージング）で行うのが安全です。

当サイト（seoagent.jp）の計測と改善の記録

当サイト（seoagent.jp）では、2026 年 10 月 4 日にトップページを Lighthouse で計測し、描画を止める Web フォント、Google タグの重複、大きすぎるロゴ画像を主な原因として特定しました。計測は GitHub Actions（米国の環境）から Lighthouse 12.6.0 で行い、モバイルは Lighthouse の既定の設定（遅い端末と回線を想定）、パソコンはパソコン用の設定です。いずれもラボ値で、実際の利用者のデータ（CrUX）は取得できていません。

見つかった原因	Lighthouse での根拠（2026年10月4日）
Web フォントの読み込みスクリプトが描画を止めていた	レンダリングを妨げるリソースとして推定 1.6〜1.8 秒
Google タグが 2〜3 本重複して読み込まれていた	1 本あたり約 178KB。メインスレッドの停止（TBT）への寄与 300〜590 ミリ秒
jQuery とアイコン用の CSS 全体を同期で読み込んでいた	描画を止める時間として jQuery 511 ミリ秒、アイコンの CSS 約 260 ミリ秒
LCP の要素（モバイル）がロゴの JPEG 画像で、表示より大きいサイズを配信していた	画像の配信の監査で指摘

このときのモバイルの計測は、18 回中 16 回が「描画が検出されない（NO_FCP）」で失敗しました。原因は特定できておらず、失敗したことが実際の利用者に白い画面が出ている証拠にはなりません。一方で、成功した 1 回の点数だけで問題ないと判断することもできません。失敗した回数も記録に残し、改善の前後で比べる対象にしています。

その後、当サイトは独自のテーマに移し、次の 2 つの改善を行いました。どちらも Lighthouse のモバイルのラボ値です。

起きていたこと	行ったこと	結果（ラボ値）
モバイルの Lighthouse が 85、LCP が 4.1 秒	モバイルではヒーロー画像を読み込まない、800px 幅の画像を追加、画像のキャッシュ期間を延長	85 → 100（LCP 約 1.5 秒）
Google タグ（約 180KB）がメインスレッドを 0.46 秒ほど止めていた	計測の設定は残したまま、タグ本体をページの読み込み後に読む	92 → 96〜97（LCP 2.7〜3.2 秒 → 1.9 秒）

2026 年 10 月 13 日時点のテーマのコードでは、文字は端末に入っている書体（システムフォント）を使い、Web フォントのファイルは読み込んでいません。テーマの CSS は約 6KB（gzip）を HTML の head に埋め込み、外部の CSS ファイルによる描画の停止をなくしています。JavaScript は defer（HTML の解析を止めずに読み込む指定）で読み込み、本文を表示しないページではブロックエディターの CSS を読み込みません。改善による順位や流入の変化は、まだ測定前のため書きません。

画像・キャッシュ・プラグイン・PHPの見直し方

WordPress で効果が出やすい見直しは、画像の大きさと形式、ページのキャッシュ、プラグインの読み込み、PHP の版の 4 つです。どれも、計測で該当する指標が遅いと分かってから手を付けます。

画像

画像は、表示する大きさに合わせて縮小し、WebP などの圧縮率の高い形式で配信します。WordPress はアップロード時に複数の大きさの画像を作り、本文の画像に srcset を付けます。最初の画面に出る画像（LCP の候補）は遅延読み込みにせず、それ以外は遅延読み込みにします。WordPress 5.5 からは、幅と高さの指定がある画像に loading=”lazy” が自動で付きます。対象は本文・抜粋・テキストウィジェットの画像、アバター、wp_get_attachment_image() で出す画像で、幅と高さが無い画像には付きません（Make WordPress Core：Lazy-loading images in 5.5、2020年7月14日、2026年10月13日確認）。

当サイトのテーマは 1,200px 幅と 600px 幅の WebP を srcset で出し、最初の画面の画像には fetchpriority=”high”（優先して読み込む指定）を付けています。画像の形式と遅延読み込みの詳しい設定は「画像最適化とlazy loadの使い方」で説明しています。

キャッシュ

ページのキャッシュは、組み立てた HTML を保存しておき、次の訪問者には保存した HTML を返す仕組みです。TTFB が遅いときに最も効きます。WordPress の手引きは、キャッシュのプラグインが投稿やページを静的なファイルとして保存して配信し、サーバーの処理の負荷を減らすと説明しています。サーバー会社がサーバーのキャッシュ機能を用意している場合はそれを使い、キャッシュのプラグインと二重にしないようにします。ログイン中の画面やフォームの送信後の画面など、キャッシュしてはいけないページが除外されているかも確かめます。

プラグイン

プラグインは、数よりも「どのページに何を読み込んでいるか」を見ます。使っていないプラグインは停止して削除し、特定のページでしか使わない機能のファイルが全ページで読み込まれていないかを確かめます。高速化のプラグインで CSS や JavaScript をまとめる・遅らせる設定は、表示の崩れやボタンが動かない不具合を起こすことがあるため、設定を 1 つ変えるたびに主なページの表示と動きを確かめます。

PHPとサーバー

PHP の版は、ホスティング会社の管理画面で変えられることが多く、新しい版のほうが処理が速いことがあります。変更の前に、使っているテーマとプラグインが新しい版に対応しているかを確かめ、バックアップを取ってから切り替えます。

直した後の確かめ方

直した後は、直す前と同じ URL・同じ道具・同じ端末の設定で測り直し、狙った指標が変わったかを確かめます。点数の合計ではなく、遅かった指標（例：LCP や TBT）の値と、診断に出ていた項目が消えたかを見ます。

直す前の計測の条件（日付、URL、モバイルかパソコンか、回数）と値を記録しておきます。
1 つだけ変更し、表示の崩れやフォーム・計測の動きを主なページで確かめます。
同じ条件で複数回測り、中央値や範囲で比べます。計測の失敗も回数として残します。
実際の利用者のデータは 28 日間の集計なので、変化が表れるまで時間がかかります。Search Console の「ウェブに関する主な指標」レポートで、URL の群が「良好」に移るかを数週間かけて見ます。

計測タグの読み込みを遅らせた場合は、GA4 のリアルタイムのレポートなどで計測が続いていることも確かめます。当サイトでは、Google タグを読み込み後に読むように変えたとき、ページを開いてすぐに閉じた訪問は計測されないことがあると、テーマのコードに注記しています。速度と計測の正確さのどちらを優先するかは、サイトごとに判断します。

AI検索と表示速度

AI による概要や AI モードのために、表示速度で特別な対策をする必要はありません。Google は、AI による概要や AI モードにコンテンツが表示されるための「追加の要件はなく、別途特別な最適化を行う必要もありません」としたうえで、SEO の基本の 1 つに「ユーザーにとって優れたページエクスペリエンスを提供します」を挙げています（Google 検索セントラル：AI 機能とウェブサイト、最終更新日 2025-12-31、2026年10月13日確認）。AI の回答から自社のページに移った読者にとっても、表示が遅いページは内容を読む前に離れる原因になります。

一方で、表示速度を上げると AI の回答に引用されやすくなる、という説明は Google の公式の資料にはありません。WordPress の高速化は、AI 検索の対策としてではなく、来た人に内容を届けるための基本として行います。

よくある質問

高速化のプラグインは入れるべきですか？

計測で原因を確かめてから判断します。TTFB が遅く、サーバーにキャッシュの機能が無い場合は、キャッシュのプラグインが効くことがあります。一方、サーバーのキャッシュと二重にしたり、CSS や JavaScript をまとめる設定を一度に有効にしたりすると、表示の崩れが起きることがあります。入れる場合は 1 つの設定ずつ有効にして確かめます。

PageSpeed Insightsの点数は何点を目指せばよいですか？

点数の目標より、Core Web Vitals の実測値が「良好」に入るかを目安にします。LCP は 2.5 秒以下、INP は 200 ミリ秒以下、CLS は 0.1 以下です。点数はラボの 1 回の計測で揺れるため、満点を目指す必要はありません。

サーバーを変えれば速くなりますか？

遅さの原因がサーバーの応答（TTFB）にある場合は速くなることがあります。画像やスクリプトが原因の場合は、サーバーを変えても大きくは変わりません。移転の前に、PageSpeed Insights で TTFB と LCP の内訳を確かめます。

表示速度は検索順位にどれくらい影響しますか？

Google は「Core Web Vitals は、その他のページエクスペリエンス要素とともに、Google のコアランキングシステムがランキングを決定する際に考慮する要素です」と説明しています。どの程度影響するかは公表されていません。速度は多くの要素の 1 つと考え、内容を整えたうえでの使いやすさとして改善します。

SEOAGENTでできること

SEOAGENT の「AI検索・表示速度の診断」では、表示速度を、実際の利用者のデータ（CrUX）による判定と、計測ツールの点数に分けて表示します。取得できた実測や計測情報をもとに、改善点を検討できます。記事は WordPress へ公開でき、公開前の確認では本文の主張と出典を照らせます。

できないこと：診断機能のため、テーマ・サーバー・プラグインの設定は自動で変更しません。改善は診断を見てサイト側で行います。表示速度の改善や検索順位を保証するものではありません。WordPressの表示速度と関わるテクニカルSEOの記事は「テクニカルSEOの記事一覧」にまとめています。

WordPressの表示速度：遅い原因の切り分けと、当サイトの計測で効いた改善