サイトの表示が遅いと気づくと、まずPageSpeed Insightsの点数を上げたくなります。分かりやすい進め方ですが、先に確認したいのは点数ではありません。
先に決めたいのは、どのページが、どの端末で、どの操作まで遅いのか。点数は原因を探すための手がかりであって、上げること自体が目的ではありません。問い合わせに近いページで本当に待たされているなら最優先。測るたびに数字が揺れるだけなら、まず条件をそろえるところからです。
この記事でわかること
PageSpeed Insightsを点数競争にせず、サイト改善の作業順を決めるための見方を整理します。
- サイトが重いと言われたときに最初に確認すること
- PageSpeed Insightsの実ユーザーデータとラボデータの違い
- Core Web Vitalsの3指標が示すもの
- 画像、外部タグ、キャッシュ、サーバーを見る順番
- 自分で確認できる範囲と相談へ切り替える条件
点数より先に「誰がどこで待つか」を決める
最初に見るのはサイト全体の平均点ではなく、事業上の役割が大きいページで遅さを再現できるかです。同じサイトでも、トップページとお問い合わせページでは読み込む画像や機能が違います。
まずは対象を3つ程度に絞ります。
- 検索や案内から最初に入るページ
- 主力のサービス内容を説明するページ
- 問い合わせや相談につながるページ
この3つを、実際に利用される可能性が高い端末で確認します。アクセス解析を使っているなら端末の比率を確認し、見ていない場合はパソコンとスマートフォンの両方を同じURLで比べます。
優先度が高いのは、主要ページで同じ遅さを再現できて、しかも閲覧や問い合わせの操作を妨げている場合です。逆に、普段ほとんど見られないページの点数だけが低い。測るたびに結果が大きく変わる。こういう時は、設定を変える前に測定条件をそろえるところからです。
遅さ以外にも問い合わせが止まる場所がありそうなら、ホームページから問い合わせが来ない原因を5段階で切り分ける方法で、流入から受信までの全体を先に確認できます。
もうひとつ、「重い」をひとまとめにしないこと。症状を分けると、次に見る場所が決まります。
- 最初の内容がなかなか表示されない
- ボタンを押してから反応するまで間がある
- 読み込み中に文字やボタンの位置がずれる
- ページの途中で画像や外部コンテンツを待つ
どの待ち方なのかで、見る場所は変わります。ここが曖昧なまま画像だけ軽くしても、ボタンの反応やレイアウトのずれは直りません。症状に関係する場所へ絞るほうが先です。
同じURL・端末・時間帯で遅さを再現する
測定前に条件をメモしておくと、変更前後を比べやすくなります。PageSpeed Insightsの点数は、ネットワークや実行環境などの条件で変動するため、1回の結果だけで良し悪しを決めません。
記録しておきたいのは次の項目です。
| 項目 | 記録する内容 |
|---|---|
| URL | 実際に遅いと感じたページ |
| 端末 | パソコン／スマートフォン |
| 状態 | ログイン中／ログアウト中 |
| 時間帯 | 遅さを確認したおおよその時刻 |
| 操作 | 開くだけ／ボタンを押す／フォームを表示する |
| 再現性 | 毎回／時々／一度だけ |
| 直前の変更 | 画像、プラグイン、タグ、テーマなど |
WordPressへログインしている時だけ遅いなら、一般の訪問者が見る公開ページとは別の問題かもしれません。反対に、ログアウト状態でも複数端末で再現するなら、公開ページ側の確認を優先します。
時間帯も一度は変えてみます。特定の時間だけ遅いのか、いつ見ても同じなのかで、ページ内の要素とサーバー側のどちらから確認するかを考えやすくなります。ただし、この段階で原因を断定する必要はありません。事実をそろえるところまでで十分です。
PageSpeed Insightsは実ユーザーデータとラボデータを分けて見る
PageSpeed Insightsには、実際の利用状況を集計した実ユーザーデータと、一定の環境を再現して測るラボデータがあります。画面上に同居していますが、同じ期間・同じ条件の結果ではありません。
| 種類 | 何が分かるか | 見るときの注意 |
|---|---|---|
| 実ユーザーデータ | 実際の利用者が経験した表示や操作の状態 | 過去28日間の集計。データ量が足りないURLでは、サイト全体の集計へ切り替わるか表示されない |
| ラボデータ | Lighthouseの再現環境で測った結果と改善の手がかり | 一度の模擬測定なので、実行条件によって点数が変わる |
ラボのPerformanceスコアが低くても、すべての訪問者が同じ遅さを味わっているとは限りません。逆もあります。点数が緑なのに、実ユーザーデータを見ると評価が悪い。どちらか片方だけ見て安心しないほうがいいです。
アクセスが少ないサイトでは、実ユーザーデータ自体が表示されないこともあります。これは「問題なし」ではなく、そのURLを判定できるだけのデータがない状態です。主要ページを自分の端末で確認しつつ、ラボデータは原因を探す手がかりとして使います。
Core Web Vitalsは遅さの種類を分ける3指標
Core Web Vitalsは、LCP、INP、CLSの3指標で利用者の体験を見ます。合計点ではなく、どの種類の問題が出ているかを分けるために使うと分かりやすくなります。
- LCP：ページの主要な内容が表示されるまでの時間
- INP：クリックやタップなどの操作に対する反応
- CLS：読み込み中に起きる予期しないレイアウトのずれ
たとえば、最初の大きな画像がなかなか出ないならLCPの手がかりを見ます。ボタンを押してから反応が遅いならINP、読み込み途中でボタンが動いて押し間違えそうならCLSです。
3指標を一度に良くしようとすると、変更範囲が広がります。実際の症状に近い指標を一つ選び、その指標に関係するページ要素から確認するほうが作業前後を比べやすくなります。
確認は画像・外部タグ・キャッシュ・サーバーの順で広げる
原因候補は、ページ上で見えるものから確認し、影響範囲の広い設定へ少しずつ広げます。いきなりプラグインを一括停止したり、サーバーを移転したりする必要はありません。
1. 主要ページの大きな画像と埋め込み
最初に表示される大きな画像、動画、地図、SNSの埋め込みがあるかを見ます。使っていない要素が読み込まれているなら整理候補ですが、見た目や導線に必要なものまで消すと別の問題が出ます。
画像は表示サイズに対して極端に大きなファイルになっていないか、同じ内容の画像を何度も読み込んでいないかを確認します。変更する場合は一枚ずつ行い、前後の表示を比べます。
2. 外部タグや追加機能
アクセス解析、広告、チャット、外部フォームなどのタグは、外部の処理を読み込むことがあります。直前に追加したものがあるなら、対象ページと追加日時をメモします。
ただし、計測タグを止めると改善前後の比較ができなくなる場合があります。用途が分からないタグを削除せず、何に使っているか確認してから扱うのが安全です。
3. キャッシュとWordPressの構成
キャッシュは、すでに作った表示結果を再利用して読み込みを軽くする仕組みです。設定が複数あるサイトでは、WordPressのプラグインだけでなくサーバーや配信側にもキャッシュがある場合があります。
構成が分からないまま全部を消すと、一時的な変化なのか修正結果なのか判断しにくくなります。どの仕組みを使っているか、変更前へ戻せるかを確認してから一つずつ比べます。
画像を差し替えたのに古い画像だけが残る場合は、サイト全体の速度とは分けて考えます。キャッシュを消す前に画像URLを比べる確認方法を先に見てみてください。
4. サーバー応答とサイト全体の共通処理
複数のページで最初の表示まで待たされる場合は、ページ固有の画像だけでなくサーバー応答やサイト全体の共通処理も確認候補です。ここから先はサーバー設定、テーマ、プラグインの関係を切り分ける作業になります。
バックアップや検証環境がなく、元へ戻す手順も分からない状態なら、設定変更を続けないほうが安全です。対象URL、再現条件、測定結果、直前の変更を残して相談へ切り替えます。
PageSpeedの改善提案は作業リストではなく原因候補として使う
PageSpeed Insightsに並ぶ改善提案を、上から全部実行する必要はありません。表示や機能を保ったまま変更できるか、主要ページの症状に関係するかを見て選びます。
優先順位を決める基準は次の4つです。
- 問い合わせやサービス確認に近いページか
- 実際の端末で同じ症状を再現できるか
- 実ユーザーデータでも同じ種類の問題が見えるか
- 一つずつ変更して前後を比較できるか
この条件に合わない提案は、保留にしておいて問題ありません。私が避けたいと思っているのは、100点に近づけるために必要な画像や計測タグまで外してしまうことです。数字はきれいになりますが、それで問い合わせが減ったら意味がありません。点数が何点上がったかより、目的のページで待ち時間や引っかかりが減ったか。こちらを基準にします。
作業記録には、変更した日時、対象ページ、変更内容、変更前後の測定条件を残します。同じ条件で比べられない数字は、改善したかどうかの判断材料にしにくいためです。
自分で確認できる範囲と相談へ切り替える条件
自分で進めやすいのは、遅いページと端末を特定し、主要ページの画像や埋め込み、直前の変更を確認するところまでです。PageSpeed Insightsも、点数だけでなく実ユーザーデータとラボデータを分けて記録できます。
次の条件がある場合は、変更を重ねる前に相談へ切り替えます。
- 複数ページで同じ遅さが起き、原因候補を絞れない
- テーマやプラグイン、外部タグの役割が分からない
- キャッシュやサーバー設定を元へ戻せない
- バックアップや検証方法を確認できない
- 表示速度と問い合わせ導線を一緒に見直したい
速度改善だけを理由に全面リニューアルを決める必要はありません。今あるサイトで影響の大きいページから、変更リスクの低い順に確認できます。
おわりに
サイトが重いと言われたら、PageSpeed Insightsの点数より先に、遅いページ、端末、時間帯、操作、問い合わせ導線への影響を整理します。その後で実ユーザーデータとラボデータを分け、実際の症状に近いCore Web Vitalsの指標から原因候補を見ます。
主要ページは絞れたものの、画像、外部タグ、キャッシュ、サーバーのどこから直すべきか判断できない。そんな時は、記録したURLと再現条件をもとに、全面改修を前提とせず改善の順番から整理できます。
