モバイルでのページ表示速度を測るには、PageSpeed InsightsにURLを入力し、まず上部にある実ユーザーのデータを、次にその下のLighthouseのラボ結果を見ます。実ユーザーのデータは、スマホの訪問者が速い体験をしているかどうかを示し、ラボデータはそうでない理由を探すのに役立ちます。訪問の75%以上で、メインコンテンツが2.5秒以内に表示され、操作への応答が200ミリ秒以内で、レイアウトのずれのスコアが0.1以下であれば、そのページはモバイルのCore Web Vitalsに合格です。
フィールドデータとラボデータは別物
速度スコアをめぐる混乱の多くは、この2つを混同することから生まれます。
フィールドデータは、過去28日間にページを訪れた実際のChromeユーザーから、Chrome User Experience Reportを通じて集められたものです。実際の端末、回線、使われ方が反映されます。十分なアクセスがあるページやサイトにしか存在しません。
ラボデータは1回のシミュレーションテストの結果で、通常はLighthouseが、通信速度を制限したミドルレンジのスマホを模した環境でページを読み込みます。再現性があり詳細なので、原因調査に向いています。そのスコア（0〜100）はGoogleが順位付けに使うものではなく、実行するたびに変わります。
両者が食い違うときは、「良いかどうか」はフィールドデータで、「何を直すか」はラボデータで判断します。
モバイルでのCore Web Vitalsの基準値
| 指標 | 測るもの | 良好 | 要改善 | 不良 |
|---|---|---|---|---|
| Largest Contentful Paint（LCP） | メインコンテンツが表示されるまでの時間 | ≤ 2.5秒 | 2.5〜4秒 | > 4秒 |
| Interaction to Next Paint（INP） | タップやクリックへの反応の速さ | ≤ 200ミリ秒 | 200〜500ミリ秒 | > 500ミリ秒 |
| Cumulative Layout Shift（CLS） | 読み込み中にレイアウトがどれだけずれるか | ≤ 0.1 | 0.1〜0.25 | > 0.25 |
どの指標も訪問の75パーセンタイルで、モバイルとデスクトップ別々に評価されます。スマホは処理性能が低く回線も不安定なため、モバイルの数値はほぼ必ず悪くなります。基準値はGoogleがweb.devで定めています。
モバイルの表示速度テストに使える無料ツール
| ツール | データの種類 | 用途 |
|---|---|---|
| PageSpeed Insights | フィールド（ある場合）＋ラボ | 公開URLの最初のチェック |
| Search ConsoleのCore Web Vitalsレポート | フィールド | サイト全体で遅いページのグループを見つける |
| Chrome DevToolsのLighthouse | ラボ | ログインが必要なページやlocalhostのテスト、詳細な診断 |
| DevToolsのPerformanceパネル | ラボ＋自分の操作のライブ指標 | 遅延の原因となる特定のスクリプトや要素を探す |
| WebPageTest | 実機・各地点でのラボ計測 | フィルムストリップ、ウォーターフォール、他国からのテスト |
Lighthouseの具体的な使い方はLighthouseでモバイル監査をする方法で解説しています。
役に立つモバイル速度テストのやり方
- 適切なページをテストする。 トップページだけでなく、アクセスの多いランディングページを選びます。
- まずフィールドデータを見る。 PageSpeed Insightsで「データなし」と出たら、オリジン全体のデータかSearch Consoleを確認します。
- ラボテストは3回実行する。 中央値を見ます。1回の結果はぶれます。
- ローカルでは性能を絞る。 DevToolsでPerformanceの記録を始める前に、CPUを4倍遅く、回線をFast 4GかSlow 4Gに設定します。手元のPCは大半のスマホよりずっと速いからです。
- 読み込み中のページを目で見る。 速度の問題は目に見えることが多いものです。遅れて表示されるメイン画像、コンテンツを押し下げるCookieバナーなど。ここではスマホ表示が役立ちます。DevToolsのデバイスモードや Mobile View Extension を使えば、モバイルのユーザーエージェントでスマホサイズのページが読み込まれる様子を確認できます。サーバーがスマホに別のファイルを返している場合は特に重要です。
数値が改善しやすい対策
LCPが遅い場合
- メイン画像はモダンな形式・スマホ向けのサイズで、
srcsetとsizesを付けて配信する。 - メイン画像は遅延読み込みにせず、
fetchpriority="high"を付ける。 - キャッシュやCDNでサーバーの応答時間を短くする。
- レンダリングを妨げるCSSやJavaScriptを
<head>から外すか、後で読み込む。
INPが遅い場合
- 長いJavaScriptタスクを分割する。50ミリ秒を超える処理はタップをブロックします。
- 全ページで動くサードパーティのスクリプト（チャットウィジェット、タグマネージャー、A/Bテスト）を遅らせるか削除する。
- クリックや入力のハンドラーで重い処理をしない。先に反応を見せてから処理します。
CLSが高い場合
- 画像、動画、埋め込みには
widthとheight（またはaspect-ratio）を指定する。 - 広告やバナーの領域をあらかじめ確保する。
- Webフォントは
font-display: swapで読み込み、メトリクスの近い代替フォントを選ぶ。
モバイルの表示速度はどれくらい重要か
GoogleはCore Web Vitalsをページエクスペリエンスのシグナルの一部として使っていますが、順位には関連性やコンテンツの質のほうが大きく効きます。速度を気にすべき一番の理由は訪問者の行動です。スマホでは、遅いページやずれるページは、何かを読む前に離脱されてしまいます。Core Web Vitalsは追いかけるべき点数ではなく、品質の最低ラインと考えましょう。
公開前のほかの確認項目はモバイルサイトのテスト用チェックリストに、より幅広いスマホ対応はホームページをスマホ対応にする方法にまとめています。
よくある質問
モバイルの速度スコアはいくつなら良いですか？
Lighthouseのスコアはラボでの推定値です。それよりも、フィールドデータでCore Web Vitalsに合格すること、つまり訪問の75%以上でLCPが2.5秒未満、INPが200ミリ秒未満、CLSが0.1未満であることが重要です。
モバイルのスコアがデスクトップよりかなり低いのはなぜですか？
モバイルのラボテストは、より遅いプロセッサと回線を想定しています。重いJavaScriptや大きな画像は、その条件下でずっと大きく響きます。
localhostでモバイルの速度をテストできますか？
できます。Chrome DevToolsのLighthouseかPerformanceパネルを使います。PageSpeed Insightsは公開URLしかテストできません。