Lighthouse と RUM: パフォーマンスをどう正しく測定しますか？

Question

IT Interview Practice · Accepted Answer

ラボデータとフィールドデータの**両方**で測定してください。両者は異なる問いに答えます。**Lighthouse** はラボ（合成的、再現可能、デバッグ用）です。**RUM** はフィールド（実際のユーザー、真実のため）です。片方だけを信じると、間違ったものを最適化してしまいます。

## ラボ と フィールド

| | ラボ（Lighthouse） | フィールド / RUM |
|--|------------------|-------------|
| ソース | 固定デバイス/ネットワークでの1回の合成実行 | 実際の訪問、あらゆるデバイス/ネットワーク |
| 適する用途 | デバッグ、CIの回帰ゲート、再現性 | ユーザーが*実際に*体験するもの |
| INP | 測定不可（実際のインタラクションがない） | 訪問全体で測定される |
| 弱点 | 実際のトラフィックを反映しない | ノイズが多く、量が必要で、デバッグが難しい |

Lighthouseはクリーンなマシンでスロットリングされた読み込みを1回実行します。問題を*再現する*には最適ですが、あなたのp75を知るには役に立ちません。**特にINPは**フィールドでしか捕捉できません。セッションを通じた実際のインタラクションが必要だからです。

## web-vitalsライブラリでフィールドデータを収集する

```js
import { onLCP, onCLS, onINP } from "web-vitals";

function send(metric) {
  // Attribution build tells you WHICH element/interaction caused it
  navigator.sendBeacon("/rum", JSON.stringify({
    name: metric.name, value: metric.value, id: metric.id,
  }));
}
onLCP(send); onCLS(send); onINP(send); // report each metric as it finalizes
```

これはGoogleの **CrUX**（Chrome User Experience Report）と同じ方法論であり、検索ランキングを支えています。CrUXはラボではなく実ユーザーのp75です。

## 両者を組み合わせて使う方法

- **RUM** で実際の回帰を検出し、p75（ランキングが使う値）を知る。
- **CIでのLighthouse** をガードレールとして、回帰が出荷される*前*に捕捉する。
- RUMをデバイス/国/接続で分割する。平均化された数値は、ローエンドのAndroidが遅いテールであることを隠してしまいます。

## なぜ重要なのか

シニアのシグナルは、ラボ ≠ フィールドであること、ランキングがフィールドのp75を使うこと、そしてINPがフィールドでのみ本物であることを知っていることです。実際のp75が貧弱なままLighthouseスコアを最適化することは、この質問が暴こうとしている典型的な罠です。

Lighthouse と RUM: パフォーマンスをどう正しく測定しますか？

ラボとフィールド

web-vitalsライブラリでフィールドデータを収集する

両者を組み合わせて使う方法

なぜ重要なのか

関連する質問

ソース	固定デバイス/ネットワークでの1回の合成実行	実際の訪問、あらゆるデバイス/ネットワーク
適する用途	デバッグ、CIの回帰ゲート、再現性	ユーザーが実際に体験するもの
INP	測定不可（実際のインタラクションがない）	訪問全体で測定される
弱点	実際のトラフィックを反映しない	ノイズが多く、量が必要で、デバッグが難しい

ラボ と フィールド

web-vitalsライブラリでフィールドデータを収集する

両者を組み合わせて使う方法

なぜ重要なのか

関連する質問

ラボとフィールド