你的 Lighthouse 分数只是故事的一半
发布: (2026年2月22日 GMT+8 12:24)
5 分钟阅读
原文: Dev.to
Source: Dev.to
95 分的 Lighthouse 分数听起来很棒……但当你查看真实用户的体验时
40 % 的用户遭遇 Poor LCP（糟糕的最大内容绘制）。
为什么？
Lighthouse 在受控环境中运行：固定的 CPU、固定的网络、没有扩展、冷缓存。
而你的真实用户使用的是旧款 Android 手机、拥挤的 Wi‑Fi，并且装有数十个 Chrome 扩展。测试结果与实际情况可能大相径庭。
我们刚在 Ahoj Metrics 中推出了 Field Data（现场数据），以弥合这段差距。现在，你可以在 Lighthouse 审计旁边，直接查询任意域名或 URL 的真实 Chrome 用户体验数据。
什么是现场数据？
这些数据来自 Google 的 Chrome User Experience Report (CrUX)——一个汇总的、匿名化的真实性能时序数据集，来源于已选择共享使用统计信息的 Chrome 用户。
当有人使用 Chrome 访问你的网站时，浏览器会悄悄测量：
- 加载所需的时间
- 页面对点击的响应速度
- 布局的位移程度
Google 将这些数据在所有已同意的 Chrome 用户中进行汇总，并通过 CrUX API 提供。
关于 CrUX 工作方式的几个重要细节
| 细节 | 说明 |
|---|---|
| 28 天滚动窗口 | 数据代表最近 28 天的真实用户访问。单一天的异常不会导致数值飙升，单一天的优秀表现也不会掩盖持续性问题。 |
| 第 75 百分位 (p75) | 报告的数值不是平均值，而是第 75 百分位的体验——75 % 的访客拥有 更好 的体验，25 % 的访客拥有 更差 的体验。Google 希望你优化的是尾部，而不是中位数。 |
| Good / Needs Improvement / Poor 分布 | 每一次页面加载都会根据 Google 的阈值进行分类。你可以看到用户在每个区间的占比（例如 LCP 为 80 % Good、12 % Needs Improvement、8 % Poor）。这种分布比单一数值提供了更多信息。 |
实验室数据 vs. 现场数据
两者都有价值，但单独使用都不完整。
实验室数据（Lighthouse）
- 在 受控环境 中运行——相同的 CPU、相同的网络限速、相同的浏览器配置。
- 可复现——非常适合发现问题、比较部署前后的差异，以及在 CI/CD 中运行自动化测试。
- 合成的——它并不代表任何真实用户。
现场数据（CrUX）
- 衡量 真实访客 的体验——真实设备、真实网络、真实浏览器配置。
- 杂乱且变量多，但它是真相。
- 被 Google 用于搜索排名中的 Core Web Vitals（核心网络指标）。
为什么数字会出现分歧
- Lighthouse 68 → CrUX 85 % Good LCP ——大多数用户使用快速连接并且缓存已命中，真实体验比实验室预测的要好。
- Lighthouse 92 → CrUX 55 % Good LCP ——你的受众偏向于网络较慢地区的移动用户；实验室测试未能捕捉到这一点。
两个数字都不“正确”。 实验室数据告诉你 哪里出了问题。现场数据告诉你 影响有多大。两者结合使用，才能决定优化的投入方向。
五大指标
Ahoj Metrics 中的现场数据展示了五个指标：
| 指标 | 测量内容 | “Good” 阈值 |
|---|---|---|
| LCP（Largest Contentful Paint） | 主内容加载的速度（首屏图像、大标题、视频缩略图等） |
注：原文在此处结束；“Good” 阈值列在源文中未完整提供。
Ahoj Metrics 是一款性能监控工具，能够从全球 18 个地区运行 Lighthouse 审计，并通过 CrUX 显示真实的 Chrome 用户体验数据。它基于 Rails 8、Solid Queue 与 Fly.io 构建。