実環境でのCore Web Vitals：ユーザーが実際に感じているボトルネックを見つける
ラボテストと実ユーザーのCore Web Vitalsをつなぎ、修正の優先順位を付け、モバイルとデスクトップで改善を検証する実践的な方法。
速いラボの実行結果は手がかりであって、最終判断ではない
あるページが管理されたテストでは速く見えても、古いスマートフォン、混雑したネットワーク、あるいはサーバーまでの遠い経路では、訪問者には依然として遅く感じられることがあります。ラボテストはページロードを再現し、リクエストのウォーターフォールを可視化するのに役立ちます。フィールドデータは、実際の訪問がさまざまなデバイスと条件のもとでどう振る舞うかを示します。両方を使いましょう。フィールドデータが問題を選び、再現可能なラボの実行がその箇所を特定して修正するのに役立ちます。
Googleは三つのCore Web Vitalsを75パーセンタイル（75th percentile）で評価し、モバイルとデスクトップは別々に扱います。現在の良好（good）の目標値は、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。平均値では、かなりの数の訪問者が経験している遅い体験が隠れてしまうため、パーセンタイルのデータを見てデバイス別に分割してください。Googleのしきい値に関するガイダンスにパーセンタイル方式の説明があります。
失敗している指標から着手する
LCPは読み込みを示す。 遅れがHTMLレスポンスの前にあるのか、レンダリングをブロックするCSSによるものか、それともメインの画像やテキストの発見とダウンロードによるものかを確認します。リージョン間でTTFBを比較し、次にウォーターフォールを調べます。ヒーロー画像を圧縮して適切なサイズにし、初期HTMLから発見できるようにし、それが本当にLCP要素である場合にだけプリロードします。
INPはインタラクションを示す。 実際のユーザー操作が必要なため、ラボのページロードテストではINPを十分に測定できません。フィールドデータで遅いインタラクションを特定し、該当するクリックやキー入力をブラウザのデベロッパーツールでプロファイルします。長いJavaScriptタスク、コストの高いレンダリング、サードパーティスクリプトはいずれも次のペイントを遅らせます。処理を小さなタスクに分割すること、必須でないスクリプトを後回しにすることは、最初の試行として有効です。web.devの測定ガイドでは、Total Blocking Time（TBT）がなぜラボの代替指標であってINPの代わりにはならないのかが説明されています。
CLSは視覚的な動きを示す。 フィールドデータで、初期ロードだけでなくその後のインタラクションも確認します。画像や埋め込みに明示的な寸法またはアスペクト比を指定し、広告の領域を確保し、ユーザーが読んでいるコンテンツの上に要素を挿入しないようにします。フォントのスワップでもテキストが動くことがあります。指標が近いフォールバックを使い、実際にレンダリングされたページでテストしてください。
スコアを管理された実験に変える
一度に一つの原因だけを変更します。経路、ビューポート、デバイスプロファイル、キャッシュ状態、テスト場所を揃え、テストは複数回実行します。単一の総合スコアだけでなく、ウォーターフォールと該当指標を比較してください。その後、変更がユーザーに届いた時点でフィールドデータを確認します。ある経路やデバイスでの改善が、すべてのページに波及するとは限りません。
フィールドの監視では、似たページテンプレートをグループ化し、最も影響の大きいデバイスセグメントから先に調べます。共通のヘッダーや同意管理ツールは多くのURLに影響する一方、商品画像は一つのテンプレートにしか影響しない場合があります。このグループ化によって、サイト全体の問題とページ固有の問題を区別できます。
完璧な数字よりユーザー体験を優先する
Core Web Vitalsは有用な診断指標ですが、良いサイトの定義をすべて満たすものではありません。Googleは、Core Web Vitalsレポートで良好な結果が出ても検索での上位表示が保証されるわけではなく、関連性やより広いページエクスペリエンスも依然として重要だと述べています。ユーザーが実際に遭遇する、測定可能な不快さを解消し、変更の検証に指標を使いましょう。スコアだけを追いかけないでください。Googleのページエクスペリエンスに関するガイダンスにその背景が示されています。