適切な根拠で測定する
CrUXのフィールドデータは、対象となる実際のChromeの訪問を表します。サイト独自のRUMは、それとは異なるユーザー層を対象にする場合があります。Core Web Vitalsの評価には、75パーセンタイルを使います。公表されている「良好」のしきい値は、LCPが2.5秒以内、INPが200ミリ秒以内、CLSが0.1以下です。
確認の方法
まず、デバイスごと、URLグループごとのフィールドデータを確認します。期間とカバー範囲、データがない場合はその旨を記録します。そのうえで、再現できるラボのトレースを使い、影響を受けているテンプレートを調べます。指標ごとに、原因のレイヤーを特定します。LCPならサーバーの応答と重要なコンテンツ、INPならロングタスクとイベントハンドラー、CLSなら確保されていないレイアウトの領域です。
実装・改善の方法
原因は範囲を絞って一つずつ変更し、同じルートとデバイスプロファイルで再テストします。変更前後のトレースを残し、見た目と必須の操作が今も機能することを確認します。広い範囲の改善と説明するのは、新しいフィールドデータが出てからにします。不完全なフィールドデータは、「合格」とは扱わず、不完全だと明示します。
限界とよくある間違い
繰り返し起こる失敗は、一律の縮小化や遅延読み込みで、スコアを追いかけることです。バンドルが技術的に小さくなっても、必要な操作が遅れたり、レイアウトシフトが起きたりすることがあります。診断の根拠と、検索順位の約束は分けて扱います。
フィールドとラボの根拠は、目的を分けて使います。フィールドデータは実際の訪問の集計レポートで、報告される評価は、該当する母集団の75パーセンタイルの体験に基づきます。トラフィックの少ないページでは、データがない場合もあります。ラボデータは管理された条件のトレースで、考えられる原因の再現と診断に役立ちます。デバイスの種類、URLグループ、収集期間、フィールドのサンプルがあるかどうかを記録します。たとえば、ラボのLCPトレースで最適化されていないヒーロー画像が見つかり、フィールドデータで、その問題がモバイルの訪問者に影響していると分かる場合があります。画像、サーバーの応答、レンダリングの経路は、小さなリリースで修正します。そのうえで、レンダリング後のページを確認し、すぐに母集団が変わったと主張せず、次のフィールドデータの期間を待ちます。