Core Web Vitalsの計測アルゴリズム（LCP/CLS/INP）

計測の土台：PerformanceObserver と描画フレーム

Core Web Vitals の3指標（LCP / CLS / INP）は、いずれもブラウザが内部で持つ計測パイプラインから PerformanceObserver 経由で値を取り出します。共通する原理は、描画フレームごとにブラウザが状態を観測し、エントリとして記録することです。JavaScript で集計しているのではなく、レンダリングエンジンが各段で計測したものを後から読むだけです。基礎の描画工程は レンダリングパイプライン詳説 を参照してください。

// 3指標はそれぞれ専用のエントリ種別で観測する
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry.entryType: "largest-contentful-paint" / "layout-shift" / "event"
  }
}).observe({ type: "largest-contentful-paint", buffered: true });

重要なのは、これらがフィールド計測（実利用者）でも同じ定義で動く点です。Lighthouse のラボ値と PageSpeed Insights のフィールド値がずれるのは、計測アルゴリズムが違うからではなく、入力（端末・回線・操作）が違うからです。

LCP：最大コンテンツ要素の候補確定ロジック

LCP（Largest Contentful Paint）は「ビューポート内に表示されたコンテンツ要素のうち面積が最大のものが描画された時刻」です。ポイントは、これが一発で決まらず逐次更新される候補である点です。

ブラウザは描画のたびに、対象となる要素群の中から面積最大のものを LCP 候補として記録します。対象になるのは次の要素です。

候補のサイズはビューポート内に見えている部分の面積で測ります。はみ出した分や overflow で隠れた分は数えません。さらに精度を保つため、いくつかの除外規則があります。

• 不透明度0の要素は対象外。opacity: 0 で描かれた要素はサイズ0として扱われる。
• ビューポート全体を覆う背景（プレースホルダ的な巨大背景）は除外される。
• 画像の実効サイズは表示面積に制限される。巨大画像を小さく縮小表示しても、表示サイズ分しか加算されない（高密度の引き伸ばしを稼げないようにする補正）。

候補は最初のユーザー操作（クリック・キー入力・スクロール）で確定します。操作以降に大きな要素が現れても LCP は更新されません。これは「ユーザーが触れた＝主要コンテンツは見えたとみなす」という設計です。

CLS：レイアウトシフトスコアの計算式

CLS（Cumulative Layout Shift）は「視覚的な安定性」の指標で、個々のレイアウトシフトのスコアを合算したものです。1回のシフトのスコアは次式で定義されます。

layout shift score = impact fraction × distance fraction

• impact fraction（影響領域の割合）：シフト前の位置とシフト後の位置を和集合した領域が、ビューポート面積に占める割合。たとえば高さ50%の要素が下に25%動くと、和集合は75%＝impact fraction は 0.75。
• distance fraction（移動距離の割合）：そのフレームで動いた不安定要素の最大移動量を、ビューポートの幅または高さ（移動方向に対応する側）で割った割合。上の例で25%下に動いたなら distance fraction は 0.25。

この2つの積がそのシフトのスコアです（例では 0.75 × 0.25 = 0.1875）。distance fraction を掛けるのは、広い領域でも少ししか動かないシフトは体感影響が小さいことを反映するためです（2019年の改定で impact だけの式から変更されました）。

数えるのは予期しないシフトだけです。ユーザー操作の直後500ミリ秒以内に起きたシフトは「操作に起因する想定内の変化」として除外されます（hadRecentInput フラグ）。

セッションウィンドウによる合算

初期の CLS は全シフトの単純合計だったため、長く滞在するページや無限スクロールで不利でした。現在はセッションウィンドウ方式です。

連続するシフトを1つのウィンドウにまとめ、ギャップが1秒空くか、ウィンドウ開始から5秒経過すると次のウィンドウへ切り替えます。各ウィンドウ内のスコア合計のうち最も大きい値がそのページの CLS になります。これにより、滞在時間が長くても1回のひどい瞬間で評価される設計になっています。

INP：インタラクション遅延の内部定義

INP（Interaction to Next Paint）は、FID に代わる応答性の指標です。FID が最初の入力の入力遅延だけを測ったのに対し、INP は操作してから次に画面が更新される（次のペイント）までの全体を測ります。1回のインタラクションの遅延は3つの区間の合計です。

interaction latency = input delay + processing time + presentation delay

• input delay（入力遅延）：ユーザーが操作した瞬間から、対応するイベントハンドラが走り始めるまでの待ち時間。メインスレッドが他の長いタスクで占有されていると延びる。背景は イベントループ詳説 を参照。
• processing time（処理時間）：イベントハンドラ（複数あればその連鎖）が実行されている時間。pointerdown / pointerup / click など、1つの論理操作に紐づく全ハンドラを含む。
• presentation delay（表示遅延）：ハンドラ完了後、ブラウザがスタイル計算・レイアウト・ペイントを終え、次のフレームを描くまでの時間。ハンドラがDOMを大きく書き換えるとここが延びる。

1つの「インタラクション」は入力イベントのグループとして束ねられます。たとえばタップは pointerdown → pointerup → click をまとめて1インタラクション、キー入力は keydown → keypress → keyup を束ね、それらに属するハンドラの中で最も遅延が大きいイベントの値をそのインタラクションの遅延とします。mousemove のような連続イベントは対象外です。

ページ全体の INP 値の決め方

ページ滞在中に多数のインタラクションが起きます。INP として報告されるのは、その中のほぼ最悪値です。具体的には、インタラクション数に応じて外れ値を間引いた98パーセンタイル相当を採用します。

インタラクション総数 N に対し
  floor(N / 50) 個の最悪エントリを除外し
  残りの中で最も遅いものを INP とする

50回ごとに最悪1件を捨てるため、操作回数が少ないうちは実質的に最大値、多くなると上位の外れ値を1件ずつ無視します。単発のたまたまのスパイクで全体評価が決まらないようにする補正です。

良好の閾値とパーセンタイル評価

フィールド評価では、これらの値を全訪問の75パーセンタイルで見ます。つまり「訪問の75%が Good 閾値以下」で初めて合格扱いです。平均ではなくパーセンタイルを使うのは、一部の遅い体験を平均が覆い隠すのを避けるためです。

まとめ