Core Web Vitals（コアウェブバイタル）

3つの指標は、それぞれ別の体感的な問題を切り分けています。LCPは、最も大きく表示される要素（多くの場合はヒーロー画像や見出し）が描画されるまでの時間を測ります。INPは、訪問全体を通してタップ、クリック、キー入力にページがどれだけ速く反応するかを測る指標で、最初の操作だけでなくすべての操作をとらえるため、従来のFirst Input Delayに代わって採用されました。CLSは、アセットの読み込みにともなってレイアウトがどれだけ動くかを測ります。Googleは目標となるしきい値（LCPは2.5秒未満、INPは200ミリ秒未満、CLSは0.1未満）を公開しており、実際のChromeユーザーから集めたフィールドデータの75パーセンタイルでページを判定します。そのため、一握りの高速なセッションがあっても、大多数にとって遅い体験を覆い隠すことはできません。

フィールドデータが重要なのは、Lighthouseのようなラボツールが単一の仮想デバイス上で動作し、中位機種のスマートフォンや不安定なモバイル回線で買い物をする人が実際に感じるものとはほとんど一致しないからです。Googleが信頼する情報源はChrome User Experience Report（CrUX）で、これには約28日の遅れがあります。したがって、今日加えた修正が合格として反映されるまでには数週間かかります。ラボのスコアだけを見て最適化を進めた運営者は、Search Consoleで数値が動かないことに戸惑い、作業が無駄だったと早合点しがちです。

Core Web Vitalsはランキング要因であることが確認されていますが、その影響は控えめです。主に、関連性が同程度のページ同士を分けるタイブレーカーとして働きます。そのため、内容の薄い高速なページが、検索意図によりよく答える低速なページを上回ることはありません。誠実な見方をすれば、良好なバイタルはランキングとコンバージョンを守るものであって、それ単体で勝ち取るものではありません。

たとえば、大きくカスタマイズされたテーマを使うShopifyストアで、商品ページのCLSが0.28という不合格域に入っているとします。原因は、星評価のウィジェットとおすすめ商品の行が、どちらも最初の描画の後に読み込まれ、買い物客がカートに入れるボタンに手を伸ばすちょうどそのときに、ボタンを画面の下へ押しやってしまうことにあります。両方のブロックにmin-heightコンテナで固定の高さを確保し、集計された星評価をサーバー側で最初のHTMLに描画するようにすると、ソーシャルプルーフを一切減らさずにCLSを0.05未満まで下げられます。カートに入れるボタンが動かなくなり、誤タップが減り、メインスレッドがページの再レイアウトに追われなくなるため、INPもたいてい改善します。

AI回答エンジンとの関係は、間接的ではありますが現実のものです。ChatGPT、Perplexity、Google AI Overviewsは、クローラーが問題なく取得して解析できるコンテンツに頼っています。主要なコンテンツと構造化データを速く安定して描画するページは、描画が遅れたりヘッドレスでの取得中にずれたりするページよりも、取得して引用しやすいものです。バイタルは直接の引用要因ではありませんが、合格のLCP、速いサーバー応答、軽いスクリプト、最初のマークアップに含まれるコンテンツを実現する同じ規律が、どの情報源を表示するかを判断するシステムにとってもページを読み取りやすくします。