WordPressサイトの表示が遅いと感じてGoogle PageSpeed Insightsを開いたものの、点数や専門用語が多く、どこから直せばよいか迷う方は少なくありません。PageSpeed Insightsは便利な測定ツールですが、表示された警告を上から順にすべて消すためのチェックリストではありません。大切なのは、実際の利用者データと一回のテスト結果を分けて読み、自分で安全に改善できる項目から優先順位を付けることです。
この記事では、WordPress初心者を対象に、PageSpeed Insightsの測定手順、画面の見方、LCP・INP・CLSなどの指標、改善項目の選び方、変更後の確認方法を順に解説します。専門的なコード変更を前提にせず、画像、プラグイン、キャッシュ、レイアウトといった確認しやすい範囲を中心に進めます。
PageSpeed Insightsで分かること
PageSpeed Insightsは、入力したページの表示体験をモバイルとデスクトップに分けて確認できるGoogleのツールです。結果には、実際の利用者から集めたフィールドデータと、一定条件で実行したラボデータが表示されます。改善候補も示されるため、遅さの原因を絞り込む入口として役立ちます。
ただし、測定結果はサイト全体を一度に診断したものではありません。入力したURLの結果が中心です。トップページが良好でも、画像の多い記事や問い合わせページが遅いことはあります。逆に、特定の記事だけが重くてもサイト全体の問題とは限りません。
点数だけで判断しない
ラボデータのパフォーマンススコアは0から100で示され、90以上は緑色になります。ただし、100点にすること自体がサイト運営の目的ではありません。実際の利用者にとって読み込みや操作が快適か、改善によって表示崩れや機能停止が起きていないかを優先します。
広告、アクセス解析、動画、予約機能など、サイトの目的に必要な外部機能が点数へ影響することもあります。必要な機能を無理に外して点数だけを上げても、サイトの価値が下がれば本末転倒です。
測定値には揺れがある
ラボデータは、測定時の条件やサーバーの応答、外部通信の状態などで変わります。同じページを続けて測っても、数値が完全には一致しません。一回だけの結果で成功や失敗を決めず、条件をそろえて複数回測り、おおまかな傾向を見るのが基本です。
測定前に準備すること
改善前の状態を記録しておくと、変更の効果を判断しやすくなります。先に設定を変えてしまうと、どの操作が効いたのか、どの操作で問題が起きたのか分からなくなります。
代表的なページを選ぶ
最初に、性質の異なるページを数件選びます。少なくとも、トップページ、通常の記事、画像が多い記事を候補にします。固定ページやフォームが重要なサイトでは、それらも別に測ります。
アクセスが多いページ、検索から初めて訪れる人が多いページ、問い合わせや購入につながる重要ページは優先度を上げます。サイト全体の平均を想像するより、実際に利用されるページを個別に確認するほうが改善につながります。
バックアップと変更記録を用意する
テーマ、プラグイン、キャッシュ設定を変更する可能性があるため、作業前に復元可能なバックアップを確認します。レンタルサーバーの自動バックアップがある場合も、保存期間、対象範囲、復元方法を確認しておきます。
簡単な作業記録も用意します。測定日時、URL、モバイルとデスクトップの結果、変更した設定、変更後の結果を書きます。一度に一項目だけ変えると、効果と副作用を追いやすくなります。
公開ページを使う
フィールドデータは、公開され、一定量の利用データがあるページでなければ表示されません。公開直後の記事やアクセスが少ないページでは「データがありません」と表示されることがあります。これは測定失敗ではなく、実利用データが十分でない状態です。その場合はラボデータを改善の手がかりにし、後日フィールドデータを確認します。
PageSpeed Insightsで測定する手順
対象URLを入力する
PageSpeed Insightsを開き、測定したい公開ページのURLを入力して分析を実行します。URLはトップページだけでなく、実際に改善したい記事のURLを使います。wwwの有無やhttpからhttpsへの転送がある場合は、普段訪問者が見る最終URLを入力します。
モバイルとデスクトップを分けて見る
結果画面ではモバイルとデスクトップを切り替えます。両方を確認しますが、スマートフォンからの訪問が多いサイトではモバイルを先に見ます。モバイルは端末性能や通信条件の影響を受けやすいため、デスクトップより低い結果になることがあります。
結果を記録する
点数だけでなく、Core Web Vitalsの合否、LCP・INP・CLSの値、改善候補の上位項目を記録します。スクリーンショットだけでは後から比較しにくいため、変更内容と一緒に短い文章で残すと便利です。
フィールドデータとラボデータの違い
フィールドデータは実際の利用体験
フィールドデータはChrome User Experience Reportをもとにした実利用データです。さまざまな端末や通信環境でページを利用した人の体験が集約されます。過去28日間の傾向を示すため、設定変更をしてもすぐに全体が入れ替わるわけではありません。
ページ単位のデータが不足すると、サイト全体に近いオリジン単位のデータが表示されることがあります。画面に「このURL」か「オリジン」かが示されるため、どちらを見ているか確認します。
ラボデータは原因を探す検査
ラボデータはLighthouseによる一回のシミュレーションです。同じ条件で比較しやすく、改善候補や診断情報が詳しいため、問題の切り分けに向いています。一方、実際の訪問者全員の体験を表すものではありません。
フィールドデータが悪くラボデータが良い場合、低性能端末、遅い回線、ログイン状態、地域、時間帯など、テストで再現できていない条件を考えます。反対に、フィールドデータが良くラボデータが一時的に悪い場合は、サーバーや外部サービスの一時的な変動も確認します。
Core Web Vitalsの見方
Core Web Vitalsは、読み込み、操作への反応、表示の安定性を測る三つの指標で構成されます。良好と判定される目安は、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。フィールドデータでは、訪問の75パーセンタイルを基準に判定されます。
LCPは主要な内容が見えるまでの時間
LCPはLargest Contentful Paintの略で、画面内の主要な大きな要素が表示されるまでの時間を表します。WordPressでは、ファーストビューの大きな画像、記事タイトル周辺、メインビジュアルなどが対象になりやすい指標です。
LCPが遅い場合は、対象要素を結果画面で確認します。大きすぎる画像、圧縮不足、サーバー応答の遅さ、表示を妨げるCSSやJavaScript、遅延読み込みの設定ミスなどが候補です。まず対象が画像なのか文字ブロックなのかを確認し、原因に合わない対策を避けます。
INPは操作への反応の速さ
INPはInteraction to Next Paintの略で、クリック、タップ、キーボード操作などに対して画面が反応するまでの体験を表します。重いJavaScript、複数の外部タグ、複雑なメニュー、チャットや広告などが影響することがあります。
INPは実際の操作が必要な指標です。アクセスが少ないページではフィールドデータが不足することがあります。ラボデータのTotal Blocking Timeなども手がかりになりますが、INPと同じ指標ではありません。不要なスクリプトを減らし、必要な機能は動作確認をしながら整理します。
CLSは表示のずれ
CLSはCumulative Layout Shiftの略で、読み込み途中に文章、画像、ボタンなどが予期せず動く度合いを表します。画像の幅と高さが確保されていない、後から広告やバナーが挿入される、Webフォント読み込みで文字幅が変わるといった状況で悪化します。
CLSを改善するときは、画像や埋め込みの表示領域を先に確保します。スマートフォン表示でボタンの位置が動かないかも確認します。数値が良くなっても、余白が不自然に大きくなった場合は見た目を調整します。
ラボデータの主な指標
FCP
FCPはFirst Contentful Paintの略で、文章や画像など最初の内容が表示されるまでの時間です。サーバー応答、CSS、フォント、初期表示に必要な資源の読み込みが影響します。FCPが遅く、画面が長く白いままなら、初期表示を妨げている要因を確認します。
Speed Index
Speed Indexは、画面内の内容が視覚的に表示されていく速さを表す指標です。主要な要素が少しずつ現れるページと、長く待った後に一気に表示されるページでは体感が異なります。点数だけでなく、表示過程の画像も見て判断します。
Total Blocking Time
Total Blocking Timeは、メインスレッドが長時間の処理で塞がれ、操作へ反応しにくい時間の合計です。JavaScriptが多い場合に悪化しやすく、プラグインや外部タグの見直しにつながります。ただし、機能を停止する前にテスト環境で必要性と影響を確認します。
改善候補の読み方
「改善できる項目」や「診断」には、画像、キャッシュ、コード、サーバーなどの候補が並びます。表示された推定短縮時間は参考値です。すべて足せばそのまま速くなるわけではなく、項目同士が重なっていることもあります。
対象ファイルを開いて原因を確かめる
項目を展開すると、影響している画像URL、CSS、JavaScript、外部ドメインなどが表示されます。URLにテーマ名やプラグイン名が含まれていれば、発生源を推測できます。ただし、ファイル名だけで削除を決めず、その機能がページで何に使われているか確認します。
自分で安全に変更できる範囲を分ける
画像のサイズ調整、使っていない画像の差し替え、不要なウィジェットの削除、不要な外部埋め込みの見直しは比較的確認しやすい作業です。一方、CSSの遅延読み込み、JavaScriptの実行順変更、データベース最適化、CDN設定は、表示や機能へ広く影響する可能性があります。
意味が分からないコードを貼り付けたり、複数の高速化プラグインを重ねたりしないようにします。分からない項目は記録して保留し、制作会社や保守担当者へ相談できる材料にします。
「次世代フォーマットでの画像の配信」と表示された場合
JPEGやPNG画像をWebPなどへ変換できる可能性があるときに表示される候補です。まず対象画像を開き、写真なのか、ロゴや図解なのか、透過が必要なのかを確認します。形式だけを変えるのではなく、実際の表示寸法に対して元画像が大きすぎないかも確認します。
WordPressでは、テーマ、サーバー、画像最適化プラグインのいずれかがWebP配信に対応している場合があります。同じ変換機能を重ねず、公式手順を一つ選びます。変換後は、古いブラウザへの代替配信、元画像の保存、メディアライブラリでの表示、SNS共有画像を確認します。
「レンダリングを妨げるリソースの除外」と表示された場合
初期表示に必要な内容より先にCSSやJavaScriptの処理を待っている可能性を示します。影響するファイルにテーマやプラグイン名が含まれていることがありますが、初心者がファイルを削除する項目ではありません。
高速化機能でCSSやJavaScriptを遅延させると、最初の一瞬だけ装飾されていない文章が見えたり、メニューやスライダーが動かなくなったりする場合があります。対象ページだけでなく、フォームやスマートフォンメニューもテストできる環境で調整します。
「使用していないJavaScriptの削減」と表示された場合
読み込まれたJavaScriptのうち、測定中に使われなかった部分があることを示します。測定時に使われなかったからといって、サイト全体で不要とは限りません。スクロール後に動く機能、クリック後に開くメニュー、フォーム送信、ログイン後の機能などで使われることがあります。
まず発生源を確認し、利用していないプラグインや埋め込みが明確なら、それらを整理します。必要な機能のファイルが大きい場合は、ページごとの読み分けや実装変更が必要になるため、開発者へ相談する範囲です。
「画像要素でwidthとheightが指定されていない」と表示された場合
画像が読み込まれる前に表示領域を確保できず、周囲の文章やボタンが動く可能性があります。これはCLSへつながる代表的な原因です。WordPressが通常挿入する画像には寸法情報が付くことが多いため、テーマのテンプレート、独自HTML、外部埋め込み、遅延読み込み機能を確認します。
見た目の幅を固定するだけでなく、縦横比を保ったままレスポンシブ表示できることが大切です。パソコンで直ってもスマートフォンで画像がはみ出す場合があるため、両方で確認します。
改善の優先順位を決める方法
優先順位は、利用者への影響、改善効果、作業リスクの三つで考えます。アクセスが多いページでCore Web Vitalsが不良になり、原因が大きな画像一枚で、差し替えリスクが低いなら優先度は高くなります。反対に、影響が小さく、変更リスクが高いコード最適化は後回しにします。
重要ページの不良指標を先にする
問い合わせ、購入、予約、主要記事など、目的達成に近いページを先に改善します。すべてのページを一斉に直す必要はありません。重要ページで再現する問題を解消し、共通テンプレートの問題なら他ページにも展開します。
大きくて安全な改善から着手する
WordPress初心者が取り組みやすい順序の例は、次のとおりです。
- ファーストビューの大きな画像を適切な寸法と容量にする
- ページ上で使っていない動画、地図、SNS埋め込みを見直す
- 不要なプラグインや重複する機能を確認する
- キャッシュ機能が未設定ならサーバーやテーマの公式手順を確認する
- 外部タグや広告の必要性と読み込み数を見直す
- コードや配信設定は専門家へ相談する
画像を変更するときは、縦横比、代替テキスト、画質も確認します。容量だけを極端に小さくすると、ぼやけた画像になり、記事の分かりやすさを損ないます。
共通原因とページ固有原因を分ける
複数ページで同じCSSやJavaScriptが指摘されるなら、テーマや共通プラグインが原因の可能性があります。一つのページだけで大きな画像が指摘されるなら、ページ固有の問題です。共通原因は改善効果が大きい一方、影響範囲も広いため、テスト環境で確認します。
WordPressで取り組みやすい改善
画像を見直す
表示サイズより極端に大きい画像をアップロードしている場合は、用途に合う寸法へ調整します。写真はWebPやJPEG、透過が必要な画像はWebPやPNGなど、内容に合う形式を選びます。WordPressが生成する複数サイズを利用し、本文でフルサイズを常用しないことも大切です。
すでに公開中の画像を一括変換するプラグインは、元画像の保存、互換性、削除時の挙動を確認してから使います。まず代表ページの数枚で試し、見た目と容量を比較します。
プラグインを整理する
停止中のプラグインは通常ページで処理を実行しませんが、更新管理や安全性の観点から不要なら削除を検討します。有効なプラグインでも、使っていない機能や外部通信が多いものは影響を確認します。
プラグイン名だけで重いと断定せず、停止前後で代表ページを測り、フォーム、メニュー、アクセス解析などの機能も確認します。本番で突然停止せず、バックアップとテスト環境を使います。
キャッシュを確認する
キャッシュは、同じ処理を毎回やり直さず、準備済みのデータを再利用する仕組みです。レンタルサーバー、テーマ、プラグインに同種の機能がある場合、重複設定で表示崩れや更新反映の遅れが起きることがあります。
一つの仕組みから試し、変更後はキャッシュを削除して表示を確認します。ログイン中とログアウト状態、スマートフォン、問い合わせフォームなども確認します。
外部コンテンツを減らす
YouTube、Googleマップ、SNS投稿、Webフォント、チャット、広告、アクセス解析などは外部サーバーから読み込まれます。必要性の低い埋め込みを減らすと改善する場合があります。動画の代わりにサムネイルとリンクを使うなど、目的を保ちながら読み込みを遅らせる方法も検討します。
変更後に再測定する手順
一項目ずつ変更する
画像圧縮、キャッシュ設定、プラグイン停止を同時に行うと、どれが効いたか分かりません。一項目を変更し、表示確認と再測定をしてから次へ進みます。問題が出たときも戻しやすくなります。
キャッシュを整理して測る
設定変更後は、WordPress、キャッシュプラグイン、サーバー、CDNのうち利用している範囲でキャッシュを削除します。ブラウザのプライベートウィンドウでもページを開き、更新内容が反映されているか確認します。
複数回の傾向で比べる
同じURL、同じモバイルまたはデスクトップ条件で複数回測り、中央値に近い結果を比べます。一回だけ大きく改善または悪化した数値に振り回されないようにします。測定日時と変更内容を記録すると、サーバーの時間帯差も見つけやすくなります。
見た目と機能を確認する
数値の確認だけで終わらせず、実際のスマートフォンとパソコンでページを開きます。画像、メニュー、追従ボタン、フォーム、目次、広告、アニメーション、ログイン機能などを確認します。表示速度が上がっても主要機能が動かなければ改善とはいえません。
実践例で優先順位を考える
ここでは、画像の多いWordPress記事を測定し、モバイルのLCPとCLSに改善余地があるケースを例にします。結果には、大きなアイキャッチ画像、画像寸法の不足、使用していないJavaScriptが表示されたと仮定します。
最初にLCP対象を確認する
LCP要素が記事上部のアイキャッチ画像なら、画像の表示寸法、元画像の寸法、容量、形式を確認します。別の小さな画像まで一括変換する前に、利用者が最初に見る大きな画像を一枚だけ調整します。差し替え後は画質とトリミングを実機で確認します。
次にCLSの発生箇所を確認する
寸法が指定されていない画像が記事中の外部バナーなら、表示領域を確保できる設定や埋め込み方法を確認します。バナーが不要なら削除も選択肢ですが、問い合わせや収益につながる重要な導線なら、機能を残したまま安定表示させる方法を選びます。
JavaScriptは最後に判断する
使用していないJavaScriptの推定削減量が大きくても、その発生源がフォームやメニューなら先に削除しません。画像とレイアウトの低リスクな改善を終えて再測定し、それでも操作性や読み込みに問題が残る場合に、テスト環境でプラグイン停止や遅延設定を試します。
結果を比較して次を決める
変更前後の複数回測定でLCPが安定して改善し、表示崩れがなければ、その変更を同じテンプレートの記事へ展開します。CLSが残る場合は、別の画像や広告枠が原因になっていないか確認します。改善幅が小さければ元に戻し、次の候補へ移ります。
よくある失敗と対処法
100点を目標にして機能を消しすぎる
PageSpeed Insightsの点数を上げるために、問い合わせ導線や計測タグまで外してしまう例があります。サイトの目的に必要な機能は残し、利用者への影響が大きい問題から改善します。点数は判断材料の一つです。
高速化プラグインを複数入れる
キャッシュ、CSS圧縮、JavaScript遅延などの機能が重複すると、表示崩れや管理画面の不具合が起きる可能性があります。既存のテーマやサーバー機能を確認し、役割が重ならない構成にします。
警告文を見てコードを直接変更する
「使用していないJavaScriptの削減」などの警告を見て、テーマファイルを直接削除するのは危険です。そのファイルが別ページや特定操作で必要なことがあります。発生源を調べ、子テーマやテスト環境を使える人に相談します。
トップページだけ測る
トップページは速くても、記事ページの共通部品や画像で問題が起きることがあります。テンプレートの異なるページを選び、アクセス数と重要度を考慮して確認します。
フィールドデータがすぐ変わると思う
フィールドデータは過去28日間の実利用を集計しているため、改善直後に合格へ変わるとは限りません。直後はラボデータと実機確認で不具合がないことを確かめ、数週間単位でフィールドデータの傾向を追います。
専門家へ相談したほうがよいケース
次のような場合は、自分で設定を重ねるより、制作会社や保守担当者へ相談するほうが安全です。
- サーバー応答が継続して遅く、管理画面も重い
- テーマやプラグインのJavaScriptが主要原因として繰り返し出る
- キャッシュ設定で表示崩れやログイン不具合が起きる
- 広告、計測、予約、会員機能など外せない外部機能が多い
- 改善後に売上や問い合わせ計測が正しく動いているか判断できない
- バックアップから復元する手順を確認できない
相談時には、対象URL、モバイルとデスクトップの結果、問題の指標、改善候補、試したこと、発生した不具合を伝えます。点数だけでなく、どのページで何に困っているかを共有すると原因を絞りやすくなります。
定期確認に使う簡単なチェックリスト
- 重要ページをモバイルとデスクトップで測った
- フィールドデータとラボデータを分けて見た
- LCP・INP・CLSのうち問題のある指標を確認した
- 対象要素や対象ファイルを展開して発生源を確認した
- 利用者への影響、効果、変更リスクで優先順位を付けた
- バックアップと変更記録を用意した
- 一項目ずつ変更して再測定した
- 実機で表示と主要機能を確認した
- フィールドデータは数週間単位で追跡する
まとめ
Google PageSpeed Insightsは、点数を競うためではなく、利用者が感じる遅さを見つけ、改善の優先順位を決めるために使うと効果的です。フィールドデータは実際の利用体験、ラボデータは原因を探す検査として役割を分けます。
まず重要なページを選び、LCP・INP・CLSのどこに問題があるかを確認します。そのうえで、画像、不要な外部コンテンツ、プラグイン、キャッシュなど、安全に確認しやすい項目から一つずつ改善します。変更後は複数回測定し、実機で表示と機能を確認してください。コードや配信設定に踏み込む必要がある場合は、測定結果と変更記録をそろえて専門家へ相談するとスムーズです。
