WordPressの表示速度改善ガイド｜測定・原因の切り分け・修正の確認手順

WordPressのサイトが遅いと感じたとき、最初に決めたいのは「どのページで、何をしようとして待たされるのか」です。画像が見えるまでの待ち時間、メニューを押した後の反応、読んでいる途中の画面のずれでは、調べる対象が違います。速度測定の点数だけを見てプラグインを追加すると、原因が残ったまま設定が複雑になることもあります。

この記事は、自社サイトの改善を担当する方や、制作会社へ調査を依頼する方に向けたガイドです。測定結果の読み方、画像・操作・レイアウト・キャッシュの切り分け、修正前後の比較、依頼メモまでを説明します。コードを自分で書けなくても、調査の目的と確認することを共有できる構成にしました。

技術的な説明はGoogle・WordPress・WooCommerceの公式資料を参照しています。資料の確認日は2026年9月11日です。Renaultの公開事例と、説明用に作成した架空例を区別して掲載します。

1．表示速度の改善は、訪問者が困る場面を決めるところから

「遅い」を、表示・反応・ずれに分ける

まず、担当者が感じたことを操作の言葉で書き出します。「トップページを開くと写真だけ後から出る」「スマホのメニューを押しても開くまで待つ」「料金表を読んでいると、上の画像が現れて位置が動く」といった記録です。ページのURL、端末、ブラウザー、操作の順番も添えます。これがあれば制作側は同じ場面を探せます。

一方、「サイト全体が重い」という依頼だけでは、最初の表示と管理画面の保存処理が同じ問題として扱われかねません。管理者が記事を保存するまでの時間と、一般の訪問者が公開記事を開く時間も分けてください。どちらも重要ですが、使っている画面と処理が異なるため、調査結果を混ぜると優先順位が決まりません。

再現用のメモには、必ず起きるのか、ときどきなのかも記します。短い画面録画があれば、どの部分が待ち時間なのかを伝えやすくなります。録画に顧客名や入力内容が映る場合は、共有前に説明用の内容へ置き換えましょう。

Core Web Vitalsの三つの指標を知る

GoogleのWeb Vitalsの公式解説は、読み込み、操作への反応、表示の安定性をLCP・INP・CLSで捉えます。良好の目安は次のとおりです。実利用の評価では、モバイルとデスクトップを分け、原則として各指標の75パーセンタイルを確認します。平均値だけで判断する仕組みではありません。

75パーセンタイルは、値を小さい順に並べたときの75%の位置です。また、CLSには秒の単位がありません。会議の資料でも「CLSが0.1秒」のように書かず、指標名と単位をそろえます。表は入口となる目安で、個々の不具合の原因を特定するためには実際の画面を調べる必要があります。

検索順位と、使いやすさの確認を分ける

Googleのページエクスペリエンスの説明では、Core Web Vitalsをランキングシステムで利用する一方、良い測定結果が検索上位を保証するわけではないとしています。速度改善を「これだけで地域名の検索1位を取る施策」として発注するのは適切ではありません。

事業側では「料金を比較する人が、スマホで表と相談先を確認できる」といった目的を決めましょう。必要な説明や事例写真を削って点数だけを上げると、相談前の判断材料が不足します。残すべき情報と改善したい待ち時間を両方示すことで、見た目・内容・速度の調整について話し合えます。

2．PageSpeed Insightsは、実利用と再現テストを分けて読む

実際の利用データの期間と対象を確認する

PageSpeed Insightsの公式説明によると、実利用データはCrUXというデータセットに基づく過去28日間の集計です。対象URLのデータが足りない場合は、同じオリジンの集計が表示される場合があります。それも不足すると実利用データを表示できません。オリジンは、通信方式とホスト名、ポートの組み合わせで捉える単位です。

入力したURLの結果だと思って読んでいても、表示がオリジンに切り替わっていれば、別のページの利用状況も含まれます。記録するときは「このURL」「オリジン」のどちらかと、対象期間、モバイル・デスクトップの区別を残します。データがない場合は「未評価」と書き、良好とも不良とも決めないようにします。

公開直後の修正を調べる場面では、変更前を含む期間の集計を、その日の修正だけの評価に使わないことが大切です。修正日を書いたうえで、即日の動作確認と、その後の実利用の観測を別欄にしましょう。

ラボの点数は、原因を探す材料にする

同じツール内のラボ診断は、一定の条件でページを読み込むテストです。公式説明でも、ラボで良好な結果が出ても実利用まで良好とは限らないとされています。点数の色は便利な目印ですが、サイト全体の合格証として扱わず、どの待ち時間やリソースが指摘されているかを読みます。

たとえば説明用の架空例として、朝の結果が72点、夕方が80点だったとします。編集していないなら、点数だけで「8点改善した」と報告できません。テストの条件や変動も考え、同じURLと条件で複数回の記録を取り、写真が遅れるという症状が毎回起きるかを調べます。良い値だけを抜き出さず、ばらつきも共有してください。

依頼時には結果のスクリーンショットだけでなく、測定URL、実施日時、端末の区分、指摘内容を添えます。「画像の配信が指摘された」「JavaScriptの処理が長いと出た」など、結果に書かれている事実と、担当者が推測した原因を分けると調査が進めやすくなります。

重要なページと操作を選んで測る

トップページだけを改善しても、広告の着地先や問い合わせページで待たされるなら、相談までの体験を確認できていません。入口となるページ、比較に使うサービス・事例ページ、入力するページを選びます。共通テンプレートで作られたページでは、写真や埋め込みの多い代表ページも含めると、違いを把握しやすくなります。

通常のページ読み込みだけを行うLighthouseではINPを直接測れず、TBTが手掛かりになります。この点は前章のWeb Vitals資料にも説明されています。実際のメニュー操作や入力の反応は、開いた後に操作して確認しましょう。見えているだけの画面と、使える画面は同じ確認ではありません。

測定用の一覧には「URL／ページの役割／測定条件／値または未評価／再現した症状／次に調べること」を一行ずつ残します。最初からすべてのページに同じ修正をかけるより、共通の問題とページ固有の問題を分けてから適用範囲を決められます。

3．LCPの改善は、画像の容量と表示されるまでの流れを見る

大きな画像を圧縮する前に、待っている場所を特定する

GoogleのLCP最適化ガイドは、HTMLの応答、対象リソースの読み込み開始までの遅れ、取得時間、取得後の描画待ちに分けて考えます。画像を小さくしても、読み込みが始まるまで待っていたり、取得後に画面へ出せなかったりすれば、容量削減だけでは解決しません。

制作側には「この画像が大きいから悪い」と決めつけず、どの要素がLCPとして計測され、その要素がいつ取得・表示されたかを調べてもらいます。大きな見出しが対象になる画面もあります。デスクトップとスマホで構成が違う場合は、同じ対象になるとも限りません。

架空例として、トップの写真を軽量化したのに表示開始がほとんど変わらない場面を考えます。ここでは圧縮率をさらに上げる前に、スライダーの準備完了まで写真を隠していないか、写真の参照先を後から追加していないかを調べる方針が考えられます。これは原因の候補であり、画面の観察だけで確定はしません。

最初の画像と、記事の下にある画像を分ける

LCPガイドは、LCPとなる画像を遅延読み込みの対象にしないよう説明しています。最初に必要な画像と、スクロールして読む途中の図解では役割が異なります。すべてに同じ遅延設定を適用せず、上部の主要画像が待たされていないかを確認しましょう。優先度を高くする設定も、何でも高くする使い方では意味が薄れます。

画像の調整では、使用する場所、表示幅、拡大して見せる必要、写真か文字入りの図かを整理します。本文では小さくても、拡大した図の細かなラベルを読ませたいことがあります。ひとつの幅を全画像に強制せず、通常表示と拡大表示で必要な見え方を確認してください。

写真の圧縮では輪郭や暗い部分、図解では文字の欠けや細線を比べます。容量が減っても、料理の質感が分からない、商品説明の文字が潰れる状態では用途を満たしません。「元画像／配信用画像／表示サイズ／容量／見え方」を対にして確認すると、採用する条件が共有できます。

画像以外の読み込みも、担当者へ渡す

画像が原因と確認できない場合は、HTMLが届くまでの処理や、表示を待たせるCSS・JavaScriptも調査対象です。依頼側が細かな技術名を指定する必要はありません。「ページを開いた直後の白い時間が長い」「写真は取得済みでも表示されない」など、調査で分かった状態と次の確認対象を報告してもらいましょう。

フォントの読み込みを変更する場合も、文字の見え方と文章のずれを一緒に確認します。詳細はGoogle Fontsの表示速度と文字のずれを見直す手順で扱っています。不要なCSSの整理と、初期表示に必要なCSSの扱いも別の検討事項です。説明の名前だけで導入を決めず、対象画面と検証する表示状態を確認してください。

修正後は通常の表示だけでなく、画像を変更した記事の一覧、詳細、SNS用の見え方など、同じ素材を使う場所を点検します。圧縮ファイルを作っただけで終わらず、公開ページが新しい配信用画像を取得しているところまで確かめます。

4．INPの改善は、反応が遅い操作を再現して進める

メニュー・入力・絞り込みを実際に操作する

GoogleのINP最適化ガイドでは、問題となる操作を見つけて再現し、入力から処理開始まで、処理中、次の描画までの時間を分けて調べます。読み込み直後に操作する場合も確認対象です。最初の表示が済んでからだけ試すと、訪問者が早めに押したときの待ち時間を見逃すことがあります。

確認する操作は、サイトで実際に使われるものを選びます。スマホのメニューを開く、サービス一覧を絞り込む、よくある質問を開く、フォームへ文字を入れる、といった場面です。操作に要する時間を調べるときは、同じページで同じ順番を再現します。たくさんのページを無作為に触るより、問題のあった操作を確かめられます。

なお、INPは問い合わせメールが相手に届くまでの時間ではありません。送信ボタンを押した後に画面が反応すること、送信処理が終わること、受付側へ通知されることは別に確認します。「反応が速くなったから送信も正常」という報告にはしないでください。

プラグインの個数より、使う機能と処理を調べる

プラグインが多いことは調査のきっかけになりますが、数だけで原因は特定できません。ひとつの機能が複数の画面で使われていたり、テーマの表示と組み合わされていたりします。削除の前に、何に使っているか、止めた場合に何が変わるかを確認します。不要と思ったものを本番で一括削除する進め方は避けましょう。

架空例として、使っていないと思われた絞り込み機能を停止したら、サービス一覧の選択欄が動かなくなった場面を考えます。この場合、速くなったかだけでは採用できません。絞り込みが必要なら別の実装を検討し、不要なら利用者への案内とページ構成を決める必要があります。性能改善と機能廃止は同じ決定ではありません。

用途・依存関係・データ・復元を含む具体的な手順は、WordPressの不要プラグインを整理するガイドを参照してください。調査段階では「どの機能を、どのページで、どのように試すか」が分かる形に整理します。

外部タグやスクリプトの変更は、役割も確認する

解析、広告、地図、動画、チャットなどを見直す場合は、その機能を必要とする担当者を確認します。読み込みを遅らせる設定をまとめて適用すると、メニューの開始条件や計測のタイミングまで変わる可能性があります。速度の結果だけを見て、広告担当者が使う記録を失うような変更を承認しないようにします。

依頼書には「残す機能」「読み込み条件を変える候補」「確認する操作」「計測を確認する担当」を記します。たとえば動画は再生操作と字幕、チャットは起動と閉じる操作、解析は合意したイベントが記録されるかを確認します。不要なものを整理する判断と、必要なものの実装方法を改善する判断を分けると、関係者の認識がそろいます。

見た目の変更が少ない作業でも、キーボードでの操作やエラー時の表示を省略しないでください。反応速度の測定と、必要な操作を最後まで行える確認をセットにして、修正の完了条件にします。

5．CLSの改善は、読み込み前後の位置と途中の表示を確認する

画像や埋め込みの場所を先に確保する

GoogleのCLS最適化ガイドでは、画像などに寸法を指定するか、縦横比に合う領域を確保する方法を説明しています。実際の画像と異なる比率を指定すると、取得後に修正が発生することもあるため、数字を入れれば終わりではありません。

依頼側が見たいのは、画面の文章やボタンが不意に移動しないかです。写真の読み込みが遅い状態でも本文の位置が保たれるか、スマホ幅でも同じ比率で収まるかを確認します。写真を入れ替えるときに縦横比が変わる運用なら、どの比率を受け付けるか、トリミングするかも決めておきます。

広告枠や動画の埋め込みも、読み込み前の領域を確認する対象です。表示内容がない場合まで大きな空白を残すと読みづらくなるため、「読み込み中」「表示できた」「表示できない」の状態を分けて見ます。速度測定用の一画面だけに合わせず、訪問者が遭遇する状態を点検してください。

スクロールした後や、文字が切り替わる瞬間も見る

CLSガイドは、最初の読み込み後に起きるずれや、Webフォントによる影響も扱っています。記事を途中までスクロールしたときに図が現れたり、フォントの切り替わりで改行が変わったりする場面もあります。最初の一画面だけで「ずれなし」と判断しないことが大切です。

フォントを早く見せる設定と、文字の位置を保つ設定は同一ではありません。代わりのフォントと本来のフォントで文字幅が異なれば、文章の折り返しが変わる可能性があります。文字が読めるようになったことと、ボタンや文章が動かなくなったことを分けて観察します。

確認時には、価格や相談条件など、読み違えると困る場所を選んでください。途中に出るお知らせや追従要素がある場合は、それが現れる前後の状態も記録します。動きそのものをすべてなくすのではなく、利用者が意図せず読む位置や押す場所を失う場面を特定して直します。

公開後の更新でも、同じ問題を戻さない

納品時の画像で正常でも、担当者が縦長の写真を追加したら見え方が変わることがあります。更新する人へは「推奨する素材の比率」「拡大画像の用意」「追加後に確認する画面」を渡しましょう。細かなコードの説明より、自分の更新作業で何を確認すればよいかが分かる手順が役立ちます。

架空例として、記事途中の図解を横長から縦長へ変更する場面では、本文での表示と拡大表示、スマホでの文字の読みやすさ、次の見出しの位置を点検します。古い寸法が残っていれば、実際の素材に合わせて直します。画像のファイル名だけを変更したことで作業完了にしないようにします。

更新担当者が判断できない場合は、確認済みの素材例を残して制作側へ相談できるようにしてください。読者に必要な説明図を減らすより、各図の容量と領域を適切に扱い、本文として読める説明も残す方針を共有しましょう。

6．WordPressのキャッシュは、速さと内容の正しさを一緒に確かめる

どこに何を保存しているかを整理する

WordPressの最適化ハンドブックは、生成済みのHTMLを配信するキャッシュなどを説明しています。キャッシュは、毎回同じ処理を繰り返す負担を減らす考え方です。ただし、サイトのすべての待ち時間を一律に解消する仕組みではありません。

確認するときは、ブラウザー、サーバー、CDN、プラグインなど、どこに保存機能があるかを制作側へ整理してもらいます。既存の設定を確認せず別の仕組みを追加すると、更新後にどこを消去すればよいか分からなくなることがあります。設定名の一覧だけでなく、保存する対象と更新時の処理を対応させることが大切です。

比較では、初めて訪問した状態と再訪問、ログイン中と一般公開、キャッシュの生成前後などを区別します。管理者の画面で速くなったことだけでは、一般の訪問者が同じ結果になると確認できません。誰の状態を測定したのかを記録します。

個別情報を表示するページは、製品の条件を確認する

具体的な公式例として、WooCommerceのキャッシュ設定資料は、カート、マイアカウント、決済のページをキャッシュ対象から除外するよう案内しています。顧客ごとに変わる内容を表示するためです。これはWooCommerceの条件であり、すべてのフォームに同じ設定をコピーする指示ではありません。

自社サイトに会員ページ、予約、見積もり、入力確認などがある場合は、使っている機能の公式条件を調べてもらいます。「ページが速く表示された」ことに加え、利用者ごとに正しい内容が表示されること、前の入力が不適切に残らないことを確認します。顧客の実データを使わず、合意したテスト用の内容で試せる環境を用意しましょう。

キャッシュ除外の範囲は、設定したURLと理由を残します。担当者が変わった後に、除外を不要と思って消してしまわないよう、機能と対応させて記録しておきます。

更新・復元・契約変更まで含めて依頼する

CDNやサーバーの変更を提案された場合は、遅い処理のどこを改善するためか、費用や運用担当はどう変わるかを確認します。DNSなど配信に関わる設定を触るなら、Webサイト以外の既存設定への影響も調べる必要があります。「切り替えれば速くなる」という説明だけで作業日を決めないでください。

依頼内容には、変更前の設定の保存、試験方法、切り替え担当、不具合時の復元方法を含めます。復元するのが設定だけなのか、ファイルやデータベースも含むのかを明確にします。営業中に更新される注文や問い合わせがあるサイトでは、古いデータへ戻すことで新しい記録を失わないよう、復旧手順を事前に確認します。

本番の変更後には、更新した文章が公開側へ反映されるかも確認してください。速度と更新反映の両方が分かる記録を残すと、保守担当へ引き継げます。体制や定期点検の詳しい整理には、WordPressの保守チェックリストも利用できます。

7．修正前後を比較し、制作会社と次の改善を決める

公開事例は、数字の前提と調べ方を読む

Renault関係者による公開事例では、2020年12月から2021年3月までの4か月間に、33か国のランディングページへの1,000万件を超える訪問を分析しています。LCPと直帰、フォーム完了との相関を調べたもので、2021年10月に公開されました。Acquaが担当した案件ではありません。

この事例から参考にできるのは、速度だけでなく事業上の行動を測り、対象と期間を明記して関係を調べる方法です。資料の数値はそのサイトのデータから分析されたもので、自社のWordPressを同じだけ速くすれば同じ比率で問い合わせが増える、という保証には使えません。サイトの仕組みもSPAであり、自社の構成との違いがあります。

自社への応用では、相談完了、資料の閲覧、予約など、何を結果として数えるかを先に定めます。アクセス解析のイベントと、実際に受付側へ届いた相談が一致するかも確認しましょう。公開資料の数字を目標の根拠にする前に、自社で確かめられる記録を用意します。

公開直後の確認と、後日の評価を分ける

公開直後は、変更対象が実際に反映されたか、同じ条件で待ち時間が変わったか、必要な操作ができるかを確認します。スマホでメニューを開き、記事を読み、比較表を見て、入力へ進むところまで試します。フォームの送信試験は、担当者と送信先、テスト内容を決めて実施し、通知や受付まで確認します。

後日の評価では、変更日、観測期間、訪問者の端末や流入元、広告・原稿など同時に変更した内容を並べます。問い合わせが増えていても、同時期に広告を増やしたなら速度だけの効果とは断定できません。少ない件数で割合が大きく動く場合は、件数も添えて、判断を保留する選択肢を残してください。

重要なのは「点数が上がった」という一文で閉じず、解消した症状、残る課題、判断できないことを分けることです。再現テストでは改善していても実利用の記録がまだない場合は、そのまま記載します。確認日と担当を決め、次の判断につながる形にします。

そのまま使える、速度改善の依頼メモ

相談時には、次の項目を埋めたメモがあると、調査と修正の範囲を話し合えます。分からない欄は「未確認」で構いません。最初から原因や製品名を決めるより、困っていることと守りたい機能を伝えることが先です。

• 対象：URL、ページの役割、訪問者が行う操作。
• 症状：どの端末で、何をすると、どこで待つか。毎回か、ときどきか。
• 測定：日時、実利用・ラボの区別、URL・オリジンの区別、結果と未評価の項目。
• 保持するもの：写真の品質、必要な説明、メニュー、入力、計測など。
• 依頼範囲：原因調査、修正案、実装、公開確認のどこまでか。
• 納品と復旧：変更箇所、比較結果、設定記録、復元方法、残る課題。
• 運用：次の確認日、更新担当、異常時の連絡先。

Acquaへ相談する場合も、対象URLと症状からお知らせください。表示速度を含めたホームページ制作・改善の対応範囲を確認したうえで、調査が必要な箇所と修正の範囲を整理します。測定値と実際の操作を照合し、サイトの情報を必要な人へ届けられる状態に整えていきましょう。