繰り返し実行可能なウェブサイト速度チェックの実行

有用な速度チェックでは、URL、デバイスの前提条件、テスト条件を記録し、最大のボトルネックを調査します。単一のパフォーマンススコアをすべての訪問者に対する評価に変えるのではなく、変更の選択と検証に役立てるべきです。

ベースラインの確立

代表的なURLを選択し、テスト日時を記録します。モバイルまたはデスクトップの設定、リダイレクト、実行時にクッキーダイアログや通常とは異なるコンテンツに遭遇したかどうかを確認します。比較可能なラボテストを繰り返して、変動性を把握します。フィールド測定値が利用可能かどうか、またそれがページ全体と広範なオリジンのどちらに適用されるかを確認します。

レポートを順番に確認する

1. 期待されるページが実際に読み込まれたことを確認します。
2. メインのコンテンツ要素を特定し、そのリクエストパスを調査します。
3. スクリプトの実行、レンダリングブロックの原因となる処理、レイアウト変更を確認します。
4. ロードテストが測定したと仮定するのではなく、ブラウザで重要なインタラクションを実際に操作して確認します。
5. 利用不可能なデータと、測定されたゼロの値を区別します。

トータルブロック時間（TBT）はメインスレッドの負荷作業の診断に役立ちますが、INPではありません。Lighthouseのスコアが高いからといって、フィールドでのCore Web Vitals、コンバージョンパフォーマンス、検索ランキングが保証されるわけではありません。

実際の例：モバイルとデスクトップの結果が一致しない場合

デスクトップでは高速に表示される一方で、モバイルのラボテストでは大きな商品画像の読み込みが遅いと仮定します。選択された画像リソース、デバイスの設定、接続の前提条件を比較します。適切なサイズに調整されたレスポンシブ画像をテストし、同じモバイル設定で再度実行します。タイミングだけでなく、画像の品質とレイアウトの寸法も確認します。この例はテストの設計を示すものであり、特定の改善を約束するものではありません。

変更ログの維持

デプロイされた変更、変更前後の測定値、影響を受けるユーザーの導線が引き続き機能するかどうかを記録します。結果の原因を把握したい場合は、無関係な変更を組み合わせないようにしてください。フィールドレポートに新しい訪問が反映されるまでには時間がかかるため、ラボでの即座の改善と、その後のフィールドでの結果は分けて報告する必要があります。

スピードチェッカーの実行を開始し、ブラウザのパフォーマンスツールを使用して詳細な診断を行います。サービスが何を測定するかについては、PageSpeed Insightsのドキュメントをご覧ください。