サイト表示速度を改善するためのPageSpeed Insightsの見方と原因の切り分け

PageSpeed Insightsで表示速度を改善するなら、点数よりも「利用者がどこで待たされているか」から考えると、直す場所を絞りやすくなります。主要な内容が出るまで遅いのか、ボタンを押しても反応が遅いのかでは、原因も調べ方も違います。

その違いを読むには、過去の実利用者データと、その場でページを読み込んだテストを分ける必要があります。前者で利用時の問題をつかみ、後者や追加の計測で原因を探す関係です。パフォーマンスの点数だけを見て、画像の圧縮やサーバーの変更を決めることはできません。

そのページの結果か、サイト内の複数ページの結果か

PageSpeed Insights（PSI）の実利用者データは、Chrome User Experience Report（CrUX）に集められた直近28日間の体験です。サイトを訪れた全員の測定ではなく、掲載条件を満たしたデータが使われます。モバイルとパソコンでも利用環境が違うため、比較する端末区分を揃えて読みます。

特に気を付けたいのが、URL単位とオリジン単位の違いです。オリジンは、プロトコルとホスト名、ポートが同じページのまとまりを指します。対象URLのデータが足りない場合、PSIではオリジンの結果が表示されることがあります。サービス紹介ページを入力したつもりでも、その数値が紹介ページだけの体験を表しているとは限りません。

たとえば、同じオリジンに資料一覧とサービス紹介があるとします。オリジンの操作応答が悪くても、どちらのページで問題が起きているかは、その集計値だけでは分かりません。ここで紹介ページだけを改修するより、問題のあるページや操作を追加で調べるほうが、修正の根拠を得られます。

URLもオリジンもデータが不足している場合は、実利用者の状態をPSIで判定できません。データがないことを、良好とも速度不良とも扱わないことが大切です。GoogleのPSI説明に、集計範囲とデータ不足時の扱いが示されています。

LCP・INP・CLSは異なる不都合を表す

Core Web Vitalsの三つの指標は、同じ「遅さ」を言い換えたものではありません。LCPは大きな主要コンテンツが表示されるまでの時間、INPは操作への応答、CLSは表示位置のずれを表します。良好とされる境界と、原因を探す場面を並べると、違いが分かります。

ここで比べるのは75パーセンタイル値です。測定値を小さい順に並べたときの75％の位置に当たり、平均値とは異なります。CLSはずれの大きさを評価する指標なので、秒やミリ秒という単位は付きません。

PSIのCore Web Vitals判定は通常、この三つが良好であることを基準にします。ただし、INPのデータが不足していても、LCPとCLSのデータが十分にあり良好なら合格になる場合があります。LCPまたはCLSが不足すれば判定できません。「一部の数値がない」と「不合格」は同じ状態ではないため、判定だけでなく各指標のデータも読む必要があります。

LCPが遅いとき、画像圧縮だけでは解決しない理由

LCPを改善するには、表示までのどこで時間を使っているかが重要です。画像が原因に見えても、ファイルの転送より前や後で待っていることがあります。PSIのLighthouseによるラボ測定は、一定の条件を模擬してページを読み込み、こうした原因の候補を調べるために使えます。

ここからの例は、原因の違いを説明する仮定です。あるサービス紹介ページでLCPが悪く、ラボ測定では冒頭の大きな画像が対象になっていたとします。表示までの時間は、サーバーから最初の応答が来るまでの待ち時間と、画像の取得を始めるまでの待ち時間に分けて考えられます。さらに、画像の転送時間と、取得後に画面へ描画されるまでの待ち時間があります。

転送に時間がかかっていれば、画像の容量や配信方法が調査先になります。一方、画像を読み込み始める時点が遅ければ、ブラウザーがその画像をいつ発見できるかが問題です。容量を小さくしても、読み込み開始までの待ち時間は残ります。取得済みなのに表示されない場合には、描画を待たせている処理を探すことになります。

LCPの対象が文章なら、画像の転送を前提にした対処は当てはまりません。何が対象で、どの段階に時間がかかっているかまで分かれば、原因に合った修正を依頼しやすくなります。web.devのLCP改善資料では、この時間の内訳と調査方法を説明しています。

INPは、反応の遅い操作を再現して調べる

INPが悪い場合、ページが開くまでの時間を短くするだけでは、問題が残ることがあります。読み込み後に利用者が行う操作と、そのときの処理が調査の対象になるためです。

たとえば、資料一覧の絞り込みボタンを押すと画面がしばらく反応しない場合を考えます。通常のページ読み込みテストでは、その後の絞り込み操作までは再現しません。制作担当が該当操作を実行して処理を記録すれば、応答を待たせている箇所を探せます。CrUXの集計値だけでは遅い操作を特定できないため、実際に問題が起きる場面の情報が役立ちます。

ラボ測定のTotal Blocking Time（TBT）は、長い処理を調べる手がかりになります。ただし、INPの代用ではありません。TBTが良好でも、読み込み後の特定の操作が遅い可能性は残ります。INPの改善資料とTBTの説明も、実利用時の操作とラボ測定を区別して扱っています。

CLSは、何がいつ動いたかで原因が変わる

CLSが悪いときは、待ち時間ではなく、画面上の位置がずれる場面を見ます。たとえば、画像が現れた瞬間に本文が下へ押し出されるなら、画像の表示領域を読み込み前に確保できているかが調査先です。画像の縦横比に合う領域を確保すれば、その画像によるずれを抑えられます。

画像以外にも、埋め込みや後から追加される内容で位置が変わることがあります。読み込み時には安定していても、スクロールした先でずれる場合があるため、ラボ結果が良好だからといって閲覧中のずれまで否定はできません。CLSの改善資料では、読み込み後のずれも調査対象にしています。

この場合、ページ内の画像をすべて圧縮するより、どの要素が現れたときに位置が変わるかを再現するほうが原因へ近づきます。「遅いページ」と一括りにせず、表示の待ち時間と位置のずれを分ける意味はここにあります。

改修直後に実利用者データが変わらなくても、失敗とは限らない

ラボ測定はその時点の公開状態を調べますが、実利用者データには過去28日間の体験が含まれます。改修直後は、修正前の利用状況も集計に残っています。ラボ結果だけが先に良くなったとしても、直ちに食い違いを異常と見る必要はありません。

逆に、ラボで良くなったことだけで、利用者側の問題が解決したとも言い切れません。模擬した端末や回線、実行した操作が実際の利用条件と違うことがあるためです。同じ条件での再計測は値の揺れを見分ける助けになりますが、それに加えて、問題のあった操作や実利用者データがどう変わったかで修正を評価します。

Core Web VitalsはGoogleのランキングシステムで使われますが、良好な値は検索上位を保証しません。Googleのページエクスペリエンス説明も、この点を明示しています。PSIのパフォーマンス点数を、検索順位や問い合わせ数へ換算することはできません。

主要な内容が早く見えるようになったか、操作の待ち時間が減ったか。修正によるこうした変化が、速度改善で確かめられる成果です。