ウェブサイト速度テストは、特定のテスト条件でページがどう読み込まれるかを測定します。Runner AIのサイト監査ではLighthouseを含め、利用可能なモバイルとデスクトップの結果をクロールの指摘とともに表示できます。公開済みのストアフロントと、分析対象として利用できるSEOの対象から始めます。保存された根拠を限定的な修正依頼に使い、スコアがすべての顧客体験を証明する、またはストアを自動変更すると考えないでください。
アクセスできるストアでウェブサイト速度テストを始める
ストアのプロジェクトを開き、成長からSEOへ進みます。初回設定のチェックリストが表示される場合は、公開要件を満たし、最初の分析を完了してからレポートを確認します。サンプルデータは説明用であり、ストアの測定結果ではありません。まず、調べたい公開アドレスでストアフロントが開くか確認してください。
サイトの健全性カードから監査画面を開きます。新しい監査を始める操作は設定を開くだけで、ストアを編集しません。適切な最大ページ数を選び、Lighthouseのオプションを有効にして監査を実行します。ページ数はクロール範囲の上限です。すべてのURLに個別のモバイルとデスクトップのLighthouseテストが行われるという意味ではありません。結果に表示される分析対象URLを確認します。
監査開始を測定完了とみなさず、レポートを待ちます。対象アドレスと前回の確認以降に行った変更を記録してください。ECサイト監査は、技術的な指摘や購入経路の問題を整理するために役立ちます。このページは、その手順に含まれる任意の速度測定を扱います。同時購入者の負荷テストや継続的な稼働監視ではありません。
モバイルとデスクトップの結果を、欠けた値を補わずに読む
Lighthouseの結果が利用できる場合、Runnerはモバイルとデスクトップを別々のカードで表示します。利用可能なパフォーマンス、アクセシビリティ、ベストプラクティス、SEOのスコアと、受信した指標が並びます。比較前に端末と分析対象URLを確認します。デスクトップの良い結果は、モバイルでも同じ品質である証明にはなりません。総合スコアだけですべての遅延原因も分かりません。
指標にはFirst Contentful Paint、Largest Contentful Paint、Total Blocking Time、Speed Index、Time to Interactive、Cumulative Layout Shift、Interaction to Next Paint、Time to First Byteが含まれる場合があります。表示できる値はプロバイダーの応答によります。横線は値がないことを示し、遅延ゼロや合格を意味しません。推定値を埋めないでください。時間とレイアウトのずれは異なる性質を測っています。
結果は個別の分析から得た根拠であり、すべての顧客の実態調査ではありません。ラボ測定、実利用データ、プレビューでは答えられる質問が違います。詳しい診断や実ユーザーの状況が必要な場合は、ウェブサイト最適化ツールで補足する根拠を選びます。スコアの変化だけで購入率や検索順位の改善、読み込み時間の保証を主張しないでください。
確認した問題を、範囲の明確な修正につなげる
問題とページの一覧で対象URLを見つけ、保存された指摘を読みます。応答時間は参考になりますが、主要な視覚コンテンツが表示される時間とは同じではありません。公開ページを開き、遅いと感じた顧客の操作を再現します。パス、端末、開始状態、期待結果、実際の遅延を記録し、認証情報や顧客の非公開情報は送らないでください。
適切な問題のRunnerによる修正操作を選ぶと、選択した根拠と作業依頼を含む会話が開きます。すべてを修正する選択肢では、より広い依頼の会話が始まります。どちらも、それだけでストアを編集したり公開したりしません。確認できる範囲に依頼を絞り、商品情報、ナビゲーション、購入操作、無関係な内容を維持するよう求めます。
たとえば商品ページの主要画像が遅れて表示されるなら、ページと観察した動作を示します。すべての画像やスクリプトの削除を指定する前に、原因の調査を依頼してください。外部サービスへの依存や運用上の制約には別の判断が必要な場合があります。ECサイトのアクセシビリティ確認で、修正がラベル、フォーカス動作、必要な情報を取り除いていないか調べます。
公開した変更を再テストし、利用できない検査を区別する
提案された修正をプレビューで確認し、元の顧客操作を繰り返します。商品選択、ナビゲーション、カート操作、対象の内容が動くことを確認します。プレビューの確認は公開ストアを更新しません。承認した作業だけを公開し、公開アドレスを再び開いてから、同じ分析対象URLと端末の以前の根拠と新しい監査を比較します。
比較の範囲を明確にします。内容、対象、条件が変わった場合は差を記録し、すべてのスコア変動を修正の効果としないでください。不自然な結果は再確認し、改善したかった具体的な指標や動作を残します。高いスコアは、顧客が元の操作を完了できるかの確認に代わりません。
RunnerはLighthouseを依頼していない状態と、利用できない状態を区別します。未依頼ならオプションを有効にした監査を依頼します。利用できない場合は完了したクロール結果を確認し、任意の検査を後で再試行します。クロール失敗時は公開URLへのアクセスを確認し、規模を小さくすることを検討します。根拠の欠落は未解決の確認事項です。関連手順はRunner AI機能カタログで確認できます。
よくある質問
Runner AIはすべてのページをLighthouseでテストしますか？
そうとは考えないでください。最大ページ数は技術的なクロールを制限し、Lighthouseの結果には分析対象URLが示されます。商品、コレクション、決済ページへ結果を適用する前に、そのアドレスと利用可能な端末カードを確認します。根拠は実際に調べたページと条件に結び付けて扱います。
指標がない場合、ページは合格したという意味ですか？
いいえ。横線は値が利用できないことを示します。ゼロミリ秒やCore Web Vitalsの合格ではありません。欠けた値と表示されたスコアを分け、判断に必要な指標には適切な追加測定を使います。不完全なデータからパフォーマンスを断定しないでください。
修正操作を選ぶとストアは自動的に速くなりますか？
いいえ。根拠と作業依頼を含む会話が開きます。提案とプレビューを確認し、公開は別に判断します。その後に対象操作を繰り返し、公開結果を測定してください。会話の開始やコード変更の受け入れは、読み込みや購入率の改善の証明ではありません。
クロールが完了してもLighthouseが利用できない場合は？
利用可能な結果を使い、任意の検査は未解決として残します。対象の公開アドレスを確認し、後でLighthouseを再試行します。サンプルデータや架空のスコアで埋めないでください。クロールの完了と、ウェブサイト速度テストで利用できる結果が得られることは別の成果です。