スマホで使えるサイトか確認する方法

サイトがスマートフォンで使えるかを確かめるには、性能レポートと、利用者が目的の操作を完了できるかの実地確認を組み合わせます。読み込みが速くても送信ボタンを押せないページはあります。レスポンシブな画面でも、フォームの入力が失われることがあります。

GoogleはモバイルフレンドリーテストとAPIを2023年12月に終了しました。PageSpeed Insights、Lighthouse、ブラウザの端末エミュレーション、実機確認は、それぞれ役割が異なります。どれか一つだけで、使いやすさ、アクセシビリティ、検索順位を保証することはできません。

重要なページと操作を選ぶ

ホームページ、主要な商品・サービスページ、記事を一つずつ選びます。問い合わせ、予約、購入の実際の流れも含め、途中で別ドメインへ移る場合も確認します。関連する言語版と、同意バナーが出る初回訪問、再訪問、メニューを開いた状態、フォームにエラーが出た状態を試してください。

当社の無料モバイルチェックツールは、最初の予備確認に使えます。取得したHTMLと応答情報から、viewportタグの欠落、インライン指定の固定幅や極端に小さい文字などの手がかりを探します。ページの描画、JavaScriptの実行、外部スタイルシートによるレイアウト計算は行いません。HTMLのサイズは総ダウンロード量ではなく、取得時間も実機の読み込み時間ではありません。指摘はブラウザで確かめてください。

PageSpeedの2種類の結果を分けて読む

PageSpeed Insightsで公開URLを入力し、モバイルを選びます。

フィールドデータはChrome UX Reportに基づく過去28日間の測定です。「このURL」か「オリジン」かを確認してください。URL単位のデータが足りない場合、同じプロトコル、ホスト名、ポートを持つページをまとめたオリジンの結果が表示されることがあります。オリジンの合格は、そのページ単体の合格を証明しません。どちらにも十分なデータがなければ、評価なしであり、不合格ではありません。

ラボ部分は、シミュレーション条件で新たに行うLighthouse測定です。遅いリソースや処理を妨げるスクリプトの調査に使います。性能スコアはフィールド評価とは別です。1回のナビゲーション測定では、訪問者のINPは測れません。Googleの説明で違いを確認できます。

保存した2026年8月4日のモバイルレポートを原寸で開く（オリジンを選択、Core Web Vitalsは合格）

この保存例はオリジン単位のフィールド結果で、LCPは2.4秒、INPは112ミリ秒、CLSは0です。Lighthouseの性能スコアは写っていません。測定範囲の読み方を示すもので、当社ホームページの現在の測定値ではありません。

Core Web Vitalsの基準値

次の区分は、該当するフィールド測定の75パーセンタイル値を使います。平均値ではありません。

3指標をそろえた完全な合格には、すべてが良好である必要があります。ただしINPのデータが足りなくても、LCPとCLSが良好ならPageSpeedが合格とする場合があります。LCPまたはCLSのデータ不足では評価できません。このPageSpeedの評価規則は、実際の操作確認を代替するものではありません。

Search Consoleとは範囲をそろえて比較する

Search Consoleで「ウェブに関する主な指標」のモバイルレポートを開き、対象グループ、最も悪い指標、例示URLを見ます。Googleは似た体験のページをまとめますが、そのグループがサイトのテンプレート分類と一致するとは限りません。共有部品が原因だと決める前に、不具合を再現してください。

フィールドデータ同士でもPageSpeedとSearch Consoleは異なる場合があります。URL、オリジン、グループの範囲、端末、収集期間、URLの扱いを確認します。Search ConsoleはURLパラメータを区別しますが、PageSpeedのフィールドデータはパラメータを除いて集計します。すべての差を「ラボと実利用者の違い」と説明するのは不正確です。レポートの公式説明に詳細があります。

修正を公開したら、同じブラウザ操作とラボ設定ですぐに再確認します。フィールド結果は、直近28日間の集計に新しい訪問が加わるにつれて変化します。「トラッキングを開始」は28日間の検証を始める機能で、クロールや再インデックスを強制しません。表示データは28日より前に変わることもありますが、検証には監視期間と十分なデータが必要です。

Lighthouseの測定条件を残す

ChromeでページとDevToolsを開き、Lighthouseでモバイルを選んで実行します。ローカルのLighthouseなら、公開のPageSpeedリクエストでは届かないログイン後のページも確認できます。実行方法はLighthouseのドキュメントにあります。

レポート、日時、URL、Lighthouseのバージョン、端末設定、速度制限、テストしたページの版を保存します。修正前後では条件をそろえ、意外な結果は再測定してください。パソコン、ブラウザ、同意状態、設定が変われば値も変わります。DevToolsでCPUを手動で遅くしても、PageSpeedのシミュレーションと一致するとは限りません。

PageSpeed APIでラボ測定を自動化する

次のBashコマンドは、モバイルの性能、アクセシビリティ、SEOの診断を要求します。例のURLを公開ページに置き換えてください。

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

Windowsでは、この複数行の構文をBashターミナルで使います。スタートガイドは利用方法を説明し、頻繁な自動問い合わせにはキーを推奨しています。一括実行を予定する前にプロジェクトの割り当てを確認してください。割り当て超過を含むHTTPエラーは、ページの監査不合格ではありません。

lighthouseResult内のcategoriesとauditsを読みます。カテゴリのスコア0.92は100点中92点です。fetchTime、lighthouseVersion、requestedUrl、finalUrl、configSettingsを保存し、結果を採用する前にruntimeErrorを処理します。レスポンスの定義も参照してください。GoogleはPageSpeed APIからCrUXデータを外す予定のため、継続的なフィールド監視にはCrUX APIまたはCrUX History APIを勧めています。

ブラウザと実機で目的の操作を完了する

DevToolsのデバイスツールバーを有効にし、360 × 800と390 × 844 CSSピクセルから始めます。幅を連続的に変え、横向きも確認します。デバイスモードは近似です。最後は訪問者に関係する実機とブラウザで試し、必要ならiPhoneのSafariも含めてください。

• ナビゲーション、同意設定、ダイアログを開閉します。固定ヘッダーやバナーで文字やボタンが隠れないか確認します。
• 長い見出し、表、翻訳文を読み、ズームと狭い表示を試します。ウェブコンテンツのアクセシビリティ指針（WCAG）のリフロー基準は、縦スクロールの内容に320 CSSピクセル幅を使います。これは1280ピクセルの表示領域を400%に拡大した状態に相当します。二次元構造が必要な表には例外があります。はみ出しを隠すのではなく、読める内容と操作可能なスクロールを保ちます。
• 隣接するボタンをタップし、対応していればキーボードも使います。WCAG 2.2 AAのターゲットサイズ基準は24 × 24 CSSピクセルで、間隔などの例外があります。48 × 48のように大きな操作領域は使いやすい設計の選択肢です。どちらの寸法だけでもアクセシビリティ適合は証明できません。
• 画面キーボードを開いたままフォームを入力します。ラベル、フォーカス、エラー、入力保持、送信、確認画面を調べます。購入や予約は許可されたテスト環境で行い、対応する受領証や記録も確かめます。
• 実利用に近いモバイル回線で繰り返します。読み込みの遅延やリクエスト失敗時にも、再開方法がわかる状態にします。

不具合報告は具体的に書きます。仮の例なら、「予約ページを390 × 844で開くと、キーボードと同意バナーが送信ボタンを覆う。ページをスクロールしても押せない」。URL、ブラウザ、端末、状態、再現手順、画像、期待する結果、担当者を添えます。性能スコアが緑でも、予約できない不具合は対応が必要です。

測定で見つけた原因を直す

LCPが遅い場合、実際の最大コンテンツ要素と、その表示を遅らせている原因を特定します。画像なら早く発見できるようにし、遅延読み込みを避けます。プリロードは発見を早める必要があるリソースに使い、すべての画像やフォントに付けないでください。LCP改善ガイドで違いを確認できます。

操作が遅い場合は操作を記録し、処理を妨げる作業を調べます。必要な機能や同意を維持しながら、不要なスクリプト処理を減らすか、長いタスクを分割します。配置のずれには、画像、埋め込み、追加コンテンツの場所を確保します。INPとCLSのガイドは、それぞれ異なる問題の診断に使えます。

WordPressやShopifyでは、同じ内容と操作でテーマやアプリの変更を検証環境で試します。すべてのプラグインを原因扱いしたり、作り直しを提案したりする前に影響を測定してください。設定で直る問題も、部品の変更が必要な問題もあります。当社のウェブサイト最適化は原因調査と改善を支援し、コード修正が必要な場合はウェブサイト開発につなげます。

インデックス登録と操作性は別に確認する

Googleのモバイルファーストインデックスの指針はレスポンシブデザインを推奨し、ほかのモバイル構成も認めています。モバイルの内容、画像、メタデータをGooglebotが取得できるようにします。使いやすいページにも登録上の問題はあり得るため、必要に応じて別のSEO調査を行います。

Core Web Vitalsはランキングシステムに使われますが、良いスコアは上位表示を保証せず、悪いスコアだけでペナルティも証明できません。Googleのページエクスペリエンス指針は、ページ全体の有用性の中にこれらを位置づけています。

最後に、発見した問題、公開した修正、再確認して完了できた操作、まだ待っているフィールド検証を記録します。テーマ、アプリ、フォーム、タグを変えたら関係する流れを再確認してください。レポートの合格と、利用者が目的の操作を完了できることは、別々の確認事項です。