Lighthouse vs RUM：如何正确地测量性能？

Question

IT Interview Practice · Accepted Answer

要**同时**用实验室数据和字段数据来测量——它们回答的是不同的问题。**Lighthouse** 是实验室（合成、可复现，用于调试）；**RUM** 是字段（真实用户，用于求真）。如果你只信其一，就会优化错误的东西。

## 实验室 vs 字段

| | 实验室（Lighthouse） | 字段 / RUM |
|--|------------------|-------------|
| 来源 | 一次合成运行，固定设备/网络 | 真实访问，所有设备/网络 |
| 擅长 | 调试、CI 回归门禁、可重复 | 用户*实际*体验到的 |
| INP | 无法测量（没有真实交互） | 在整次访问中被测量 |
| 弱点 | 不反映你的真实流量 | 有噪声，需要量，更难调试 |

Lighthouse 在一台干净的机器上运行一次受限速的加载——非常适合*复现*问题，但对于了解你的 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 只有在字段中才真实。优化 Lighthouse 分数而真实 p75 依然很差，正是这道题所要暴露的经典陷阱。

来源	一次合成运行，固定设备/网络	真实访问，所有设备/网络
擅长	调试、CI 回归门禁、可重复	用户实际体验到的
INP	无法测量（没有真实交互）	在整次访问中被测量
弱点	不反映你的真实流量	有噪声，需要量，更难调试

实验室 vs 字段

用 web-vitals 库收集字段数据

如何把它们结合使用

为什么这很重要

相关问题