PageSpeed InsightsにサイトのURLを入力すると、モバイルのパフォーマンススコアが赤く表示されました。診断には画像、JavaScript、キャッシュなど、なじみのない項目が並びます。すべて直すべきだと思えても、開発チームに「スコアを上げてください」と伝えるだけでは、作業範囲を決めにくくなります。
まず、低いスコアと実際のユーザーが困っていることを分けて考えます。私はスコアの横に、どのページ・端末・操作で問題が起きるかを書き添えます。最初の画面で商品がなかなか表示されない問題と、購入ボタンを押しても反応しない問題では、必要な対応が違うからです。
1. 実際のユーザーデータとラボの結果を分けて読む
PageSpeed Insightsには、性質の異なるデータが並んでいます。実際のユーザーデータは、Chromeユーザーエクスペリエンスレポート（CrUX）の観測値です。ラボの結果は、Lighthouseが特定の条件でページを実行した診断です。1回のラボ測定のスコアが、すべての訪問者の体感速度を表すわけではありません。両者の対象範囲はPageSpeed Insightsの公式解説で確認できます。
実際のユーザーデータを見るときは、「このURL」のデータなのか「オリジン」単位なのかを先に確認してください。URLのサンプルが不足すると、同じオリジンの複数ページを含むデータが表示される場合があります。これを特定の商品ページの結果として報告すると、範囲が食い違います。どちらもサンプル不足で実際のユーザーデータが表示されない場合もありますが、データがないことは「速い」という判定ではありません。
CrUXは直近28日間の観測を反映するため、今日公開した修正がすぐに期間全体の結果に表れるわけではありません。ラボの結果は今日のコード変更を素早く確認するために、実際のユーザーデータは改善がユーザー体験にも表れるかを継続して確認するために使えます。同じ日の同じ測定値として比較しないようにします。
2. LCP・INP・CLSをユーザーの不便に置き換える
略語を覚えるより、どんな不便を表すかを結び付けると、次の作業を決めやすくなります。以下はweb.devのCore Web Vitalsガイドに基づく3つの指標と「良好」の基準です。実際のユーザー分布の75パーセンタイルを、モバイルとデスクトップに分けて確認します。平均的な訪問者1人の結果ではありません。
| 指標 | 何を見るか | 良好の基準 | 確認する場面 |
|---|---|---|---|
| LCP | 画面内の最も大きな画像やテキストブロックが表示されるまでの時間 | 2.5秒以下 | 主要な商品画像や本文の表示が遅い |
| INP | クリック・タップ・キー入力から次の画面更新までの応答性 | 200ミリ秒以下 | オプションを押しても選択表示が遅れる |
| CLS | 予期しない画面要素の位置のずれ | 0.1以下 | 押そうとしたボタンが別の位置に動く |
INPは、注文が完了するまでのサーバー処理時間全体とは違います。ボタンを押すとすぐに「処理中」と表示されても、決済完了までには時間がかかる場合があります。逆に、処理自体は簡単でも、ブラウザーがほかの作業をしているため最初の反応が遅れる場合もあります。どの瞬間が遅いのかを区別して伝える必要があります。
ラボで表示されるTBTも、INPと同じ指標ではありません。Core Web Vitalsのツール活用ガイドで説明されているように、読み込み中の長いタスクを探す手掛かりにはなりますが、ユーザーが後からフィルターを開いたり入力したりする場面まで代わりに測るものではありません。各指標が何を観測したかを区別することが、改善の出発点です。
3. LCPが遅いときは、大きな画像の容量だけを見ない
最初の画面で大きな画像が遅れて表示されるからといって、すべての画像をさらに圧縮する必要があるとは限りません。ブラウザーが画像の存在を知るのが遅かったのか、ダウンロードに時間がかかったのか、取得後も表示できなかったのかで原因が変わります。最初のHTMLを受け取る段階が遅いなら、画像の差し替えだけでは解決しない場合もあります。
運営担当者はまず、どの要素がLCPとして計測されたのかを開発チームと確認できます。メイン画像なら、表示サイズに対して大きすぎるファイルを使っていないか、複数のバナーを一度に読み込んでいないか、最初の画面の画像を遅延読み込みにしていないかを調べます。画面の下にある画像と、最初の画面の主要画像で、読み込みの優先順位を同じにする必要はありません。
Google ChromeチームのLCP最適化ガイドでは、リソースの発見・ダウンロード・表示までの遅延を分けて調べるよう説明しています。そのため、依頼も「画像を最適化する」より「モバイルの最初の画面にあるメイン画像が、いつ要求され、いつ表示されるかを確認する」と書く方が具体的です。形式変更や圧縮後は、画質や商品の識別に問題がないかも実際に確認してください。
4. ボタンの反応が遅いときは、その瞬間の処理を見る
メニュー、商品オプション、検索フィルター、カートボタンなど、よく使う機能をスマートフォンで操作してみてください。最初に開くときだけ遅いのか、項目が増えたときに遅いのか、特定の機能だけなのかを記録します。「モバイルが遅い」より「オプション一覧を開いて色を変更すると、選択表示が遅れる」と伝える方が、原因を探しやすくなります。
外部のチャット、広告、分析ツールのスクリプトも確認対象です。ただし、不要に見えるという理由で本番サイトからすぐに削除すると、計測や顧客対応まで止まる可能性があります。何の機能に使っているかを担当者に確認し、テスト環境で実行タイミングと負荷を比べるとよいでしょう。
INP改善ガイドでは、遅いインタラクションを見つけ、入力の遅延、処理、画面表示の遅延に分けて分析するよう説明しています。運営担当者が内部の原因をすべて判断する必要はありません。再現手順と遅くなる瞬間の画面を伝え、開発チームが原因を確認した後に、フィルター・購入・計測の機能が維持されているかを一緒に検証すればよいのです。
5. レイアウトがずれるときは、後から入り込む要素を探す
記事を読んでいる途中で広告が入り本文が押し下げられたり、商品ボタンを押そうとした瞬間にバナーが広がったりすると、ユーザーは位置を探し直さなければなりません。こうした問題はダウンロードが速くても残る場合があります。画像や広告のスペースをあらかじめ確保しているか、フォントの切り替えで行数が大きく変わらないかを確認してください。
例えば商品写真の表示後に価格とボタンが下へずれるなら、画像が読み込まれる前から、必要な縦横比のスペースを確保できているかを確認します。Cookieの案内、プロモーションバナー、埋め込み動画も同じ観点で見ます。写真をなくすのではなく、写真が表示されても周囲の要素が予期せず動かないようにする作業です。
CLS最適化ガイドでは、サイズ未指定の画像・広告・埋め込みコンテンツやフォントなどを主な原因として挙げています。基本的な読み込み診断で問題がなくても、読んだりスクロールしたりする間にずれが起きる場合があります。最初の画面だけでなく、実際の操作を最後まで試してください。
6. スコアより影響範囲で修正の順番を決める
トップページの最初の画面だけを測ると、検索から入る記事、広告のランディングページ、商品詳細ページの問題を見落とす場合があります。流入の多いページと、問い合わせ・購入に重要なページを選び、同じ構造のページから代表的なURLも確認します。共通テンプレートの問題が複数ページに広がっていれば、1回の修正を広く適用できる可能性があります。
次は測定結果ではなく、作業の優先順位を考える例です。訪問の少ない紹介ページの装飾と、主要商品ページでオプション選択を妨げる遅延が同時に見つかったなら、後者を先に検討できます。影響を受ける訪問者の範囲、不便の程度、修正コスト、機能を損なう可能性を一緒に記録すると、開発予定に組み込む根拠になります。
Lighthouseのスコア解説によると、総合パフォーマンススコアは各測定指標を重み付けして計算され、実行条件によって変動します。診断項目の数を減らせば一定の幅で上がるわけでもありません。最高点が出た1回だけを報告せず、同じ条件で複数回実行しても同様の改善が見られるかを確認してください。
7. 開発チームにはスコアではなく再現できる依頼を渡す
依頼にはURL、モバイル・デスクトップの区分、測定日と結果へのリンク、実際のユーザーデータの範囲、問題のある指標、再現する操作を記します。例えば「モバイルの商品詳細でオプション一覧を開き、色を変えると反応が遅い。この操作の処理と外部スクリプトの影響を確認し、修正後に同じ条件で比較する」と書きます。原因が確認できる前に、特定のスクリプトが原因だと決め付けないようにします。
修正直後はラボで再測定し、機能を検証します。その後、実際のユーザー指標の変化も観察します。購入ボタンを正常に押せるか、分析イベントが収集されるか、画像や動画が正常かも確認が必要です。点数のために重要な機能が失われたなら、改善が完了したとは言えません。
GoogleはCore Web Vitalsと検索に関するガイドで、良好なユーザー体験を推奨しています。また、ページエクスペリエンスのガイドでは、指標が良いだけで検索上位を保証するものではないと説明しています。PageSpeedの100点を、順位や売上の保証と受け取ってはいけません。修正の目標を「100点」だけにせず、「重要な内容を待たずに見られるか」「必要なボタンが反応するか」「読んだり押したりするときに画面が安定しているか」に分けてみてください。その問いに沿って測定と検証を重ねると、次に何を直すべきかも明確になります。