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

PageSpeed Insightsの結果を開いたら、最初に見るのはPerformanceスコアではありません。まず、改善対象として選んだURLを記録し、モバイルとデスクトップのどちらを見るかを決めます。次に、フィールドデータがそのURLとオリジンのどちらを集計しているかを確かめます。ラボデータは、測定日時と画面に表示された環境情報まで一緒に読みます。

この記事で目指すのは100点ではなく、次に調べる原因か追加計測を一つ決めることです。同じ画面には、過去の実利用データと一回のシミュレーション結果が並びます。両者を分けて読めば、点数が低い項目から根拠なく修正を始めずに済みます。

点数より先に対象URLと測定条件をそろえる

測定結果を判断に使うには、何をどの条件で見たのかを先に固定します。PageSpeed Insightsへ入力したURLと測定日時を残してください。点数や指標は、その条件に付随する観測結果として扱います。

同じページを再測定して数値が変わっても、前回と条件が違えば単純には比較できません。最初の記録があれば、ページの変化と測定条件の変化を分けて考えられます。

モバイルとデスクトップを同じ結果として扱わない

モバイルとデスクトップでは、参照するフィールドデータもLighthouseのラボ条件も分かれます。BtoBサイトで改善したい利用場面に合わせて、どちらか一方を先に判断対象とします。もう一方も確認するなら、別の測定として記録した方がよいです。

二つのPerformanceスコアを平均しても、実利用者の体験を表す新しい指標にはなりません。端末を切り替えたときは、画面に示された環境情報と測定日時も一緒に記録します。

フィールドデータがどの範囲を集計しているか確かめる

フィールドデータはChrome UX Reportに集まった実利用データです。PageSpeed Insightsでは過去28日間の観測を使い、各指標を75パーセンタイルで示します。これは今行った一回のテスト結果ではありません。

75パーセンタイルは、観測値を小さい順に並べたときに75%が収まる境目です。そのため、平均的な一人の利用者や特定の日の状態を表す値ではありません。まず集計対象を見てから、Core Web Vitalsの評価を読みます。

次の表では、同じ画面に並ぶ三種類のデータを判断の用途で見分けます。数値の良し悪しを比べるのではなく、それぞれのデータから何を判断できるかを横に見比べてください。

この表で区別しておきたいのは、オリジン全体の傾向を対象URLの実測値として扱わないことです。ラボのPerformanceスコアも、実利用評価の代わりにはなりません。どのデータを次の調査の根拠にできるかを見てください。

URL単位の結果は対象ページの過去の利用状況として読む

URL単位のフィールドデータが表示されている場合は、選んだページについて集まった実利用データを確認できます。ただし、そこから分かるのは過去28日間の分布です。今この瞬間のページ状態や、遅かった個々の利用条件までは特定できません。

Core Web Vitals評価はPerformanceスコアとは別の判定です。現行の公式説明では、通常はCore Web Vitalsを構成するLCP・INP・CLSの三指標に十分なデータが必要です。それぞれの75パーセンタイルがすべて良好なら合格し、一つでも外れれば合格しません。

INPだけデータが不足している場合は例外があります。LCPとCLSがともに良好なら合格できます。一方でLCPまたはCLSのデータが不足していれば、Core Web Vitalsを評価できません。評価条件は変わる可能性があるため、公開中の記事や運用手順では公式説明を定期的に確認してください。

オリジン集計を対象URLの結果と誤解しない

選んだURLに十分な実利用データがないと、PageSpeed Insightsはオリジン単位のデータを示すことがあります。これは同じオリジンに属するページ全体の傾向です。対象URLだけを測った値ではありません。

執筆時点の日本語画面では、集計範囲が この URL と オリジン で区別されています。画面の文言や配置は変わる可能性があります。名称だけを覚えるのではなく、入力したURLとオリジン全体のどちらが対象かを説明文で確かめてください。

オリジンの結果が不良でも、選んだページが同じ症状を持つとは限りません。反対に良好でも、そのページに問題がないとは断定できません。対象URLの状態を判断するには、ラボでの再現または実利用の追加計測が必要です。

実利用データがなければ未判定として残す

オリジンにも十分なデータがなければ、実利用データは表示されません。執筆時点の日本語画面では データがありません と示されます。この状態は良好でも不良でもなく、Core Web Vitalsを評価できない状態です。

Lighthouseのラボ結果が表示されていても、欠けたフィールドデータの代わりにはなりません。その場合は、まずラボの制御された条件で症状を探します。実利用時の分布が判断に必要なら、追加計測を次の調査にしてください。

ラボデータから次に調べる原因を一つ選ぶ

Lighthouseのラボデータは、画面に示された環境でページを読み込んだ一回の診断です。Performanceスコアは複数のラボ指標から算出されるため、実利用者全体の評価ではありません。再測定で変動することもあります。

ラボデータは、点数を目標にするためではなく原因候補を探すために使います。URL単位のフィールドデータに症状があるなら、対応する症状がラボでも現れるかを確かめます。再現できなければ、実利用時との条件差を調べるか、追加計測へ進みます。

LCPは表示された要素と読み込み経路を追う

LCPが症状として現れたら、ラボでLCP要素として選ばれた内容を確かめます。最大の画像が選ばれるとは限りません。テキストのブロックが対象になることもあるため、指標名だけから画像を原因と決めないでください。

要素を特定した後は、表示までの経路を追います。最初に、ページの読み込み開始からHTMLの最初の1バイトを受け取るまでの時間を見ます。次にLCPに必要なリソースの読み込みを始めるまでの遅れと、読み込み自体にかかった時間を分けます。リソースの読み込み後も表示まで待っているなら、要素の描画遅延が次の確認先です。

この流れの中から、観測した遅れと結び付く場所を一つ選びます。ラボに原因候補が表示されても、要素との関係を確かめるまでは修正対象と断定しません。

INPは遅れた操作を特定して処理を追う

URL単位のフィールドデータでINPに症状があっても、通常のLighthouse読み込み監査だけでは遅かった操作を特定できない場合があります。実利用データの値だけでは、どの操作で遅れたかという文脈が足りないためです。

次に必要なのは、実際に遅れたクリックやタップ、キー操作を一つ見つけることです。その操作について、入力からイベント処理が始まるまでに待ち時間があったかを調べます。処理自体が長かったのか、結果を画面へ表示するまでに遅れたのかも分けて追います。

TBTは、ページ読み込み中にメインスレッドが長く塞がれた時間を示すラボ指標です。INP問題を探す手掛かりにはなりますが、INPそのものではありません。一方から他方へ換算することもできません。遅れた操作を特定できていなければ、コードを直し始める前に操作時の追加計測を選びます。

CLSはずれた要素と発生時点を追う

CLSが症状なら、どの要素がずれたのかを表示の時系列で確かめます。通常のLighthouse監査は読み込み中のずれを見つける助けになります。一方でフィールドデータはページが開かれている期間を対象にするため、操作後のずれがラボで再現されないこともあります。

ずれた時刻が分かれば、その直前にページで何が変わったかを調べられます。ただし、画面で動いた要素が原因を作った要素とは限りません。観測した発生時点との関係を確認するまでは、画像やフォントなどの実装を原因と決めないでください。

フィールドとラボが食い違うときは測定条件へ戻る

フィールドデータは実利用者の分布を示し、ラボデータは一つの制御条件を示します。対象も時間幅も違うため、結果が食い違っても片方が誤りとは限りません。都合のよい方だけを採用すると、修正理由を説明できなくなります。

URL単位のフィールド結果が悪いのにラボで再現しない場合は、実利用時との条件差を次に調べます。端末の性能やネットワークが違うかもしれません。ページの状態がラボと異なる場合もあります。INPなら、遅れた操作が読み込み監査に含まれていない可能性もあります。

反対にフィールド結果が良好でも、ラボで悪い症状が出ることがあります。その結果は潜在的な原因候補として残します。ただし、一回のラボ結果だけで実利用上の問題が発生しているとは断定せず、条件をそろえた再測定や追加計測で確かめます。

次に調べる内容を診断記録に残す

測定を終えたら、画面で確認した事実と次に調べる内容を一つの記録にまとめます。原因の推測は、確認した事実と分けてください。根拠が足りなければ、修正案ではなく追加計測を選べます。

以下は実測例ではなく、実際の対象URLについて測定条件と判断を引き継ぐための未記入テンプレートです。比較表の内容を写すのではなく、その測定で確認できたことだけを記入してください。

確認した内容
対象URL:
対象URLを選んだ記録:
PageSpeed Insightsの確認日時:
判断対象の端末:

集計範囲
フィールドデータの表示範囲:
表示範囲を確認した画面上の表記:
フィールドデータの対象期間:
Core Web Vitalsの評価:
LCPの75パーセンタイル:
INPの75パーセンタイル:
CLSの75パーセンタイル:

ラボ条件
Lighthouseの測定日時:
Lighthouseの環境情報:
Performanceスコア:
症状に対応するラボ指標または診断:
フィールドデータとの一致点:
測定条件の違い:

次の調査
調べる原因または追加計測:
選んだ根拠:
未確認事項:
担当:
再確認条件:

次の調査欄には、要素や処理など確かめる対象を一つだけ書きます。症状を再現できていない場合は、条件を変えた測定や操作時の計測を選んでも構いません。未確認事項を残せば、後の担当者が推測を事実として受け取らずに済みます。

原因調査から複数の改善候補が生まれた後は、Webサイト改善の優先順位を決めるバックログで着手順を決めます。変更案が具体化したら、Webサイト公開前後のチェックリストで公開可否を判断します。今はそこまで先回りせず、原因を確かめる作業に絞ってください。

検索順位ではなく読者への影響を改善判断に使う

Core Web Vitalsは、Google検索のランキングシステムで使われる複数のシグナルの一部です。ただし、良いCore Web VitalsやPageSpeed Insightsの満点が上位表示を保証するわけではありません。速度の結果が良くても、検索者の問いに合う内容の代わりにはなりません。

表示速度を改善する目的は、訪れた人が必要な内容を読み、ページ上の操作を進められる状態を作ることです。検索順位の変化を先に約束せず、対象URLで起きている症状と読者への影響を根拠に判断します。

対象URLをまだ選べていない場合は、Search Consoleを見て直すページを決める月次手順へ戻ります。すでに選べているなら、記録した内容をもとに次に何を調べるかを一つに絞り、その理由まで説明できるか確かめてください。根拠が足りなければ追加計測を選びます。そろっていれば、その調査を担当者へ渡して原因調査を始めます。