用 BEACON 在 BigQuery 中分析数十亿条真实用户 Web 性能数据

预计阅读时间：8 分钟

实验室跑分能回答“这个页面在受控环境里有多快”，却很难说明不同浏览器、设备和地区的真实用户正在经历什么。Cloudflare 开放的 BEACON 数据集把数十亿条匿名化真实用户监控（RUM）记录放到 Google BigQuery 中，让开发者可以直接研究 Core Web Vitals、软导航性能以及浏览器和地区之间的差异。

这类数据集真正有价值的地方，不只是规模大，而是它允许团队从单个站点的性能面板跳到更广泛的现实基线：某个指标到底是自身回归，还是某类浏览器、网络或设备上的普遍现象？

实验室数据与 RUM 回答的是不同问题

Lighthouse 等实验室工具适合重现问题、验证优化和接入 CI，但测试环境通常固定了设备、网络和页面路径。RUM 则来自实际访问过程，能够覆盖更复杂的组合：

不同浏览器及其版本；
不同地区、网络质量和设备能力；
页面首次加载与单页应用中的软导航；
LCP、INP、CLS 等 Core Web Vitals 的真实分布。

分析 RUM 时不要只看平均值。性能数据经常呈长尾分布，少量极慢样本会显著拉高均值，而平均值也可能掩盖一批体验糟糕的用户。更实用的统计量通常是 p50、p75 和 p95，其中 p75 常被用来观察大多数用户是否获得了可接受的体验。

同样需要避免把相关性当成因果关系。某地区的 LCP 较高，可能来自网络、设备构成、页面内容、样本来源或测量覆盖差异，不能仅凭地区字段断言基础设施存在问题。

软导航让 SPA 性能不再是盲区

传统页面性能测量通常围绕完整文档导航展开。但在 React、Vue、Angular 等单页应用中，用户点击链接后可能只是更新路由和部分 DOM，并没有触发完整页面加载。

BEACON 包含软导航相关指标，因此可以把两类体验拆开分析：

硬导航：首次访问、刷新或完整文档切换；
软导航：客户端路由变化及其后续渲染工作。

这种拆分很重要。一个站点可能首次加载很快，但进入应用后，每次切换页面都要执行大量 JavaScript；也可能首次加载较慢，却通过预取和缓存提供流畅的后续导航。

不过，软导航和硬导航的生命周期并不相同。分析时应分别计算分位数和样本量，而不是把两类记录直接混合后得出一个总分。还应检查数据集对软导航的具体定义、支持范围和缺失值规则。

在 BigQuery 中完成第一次分析

BEACON 的实际项目名、表名和字段名应以公开数据集当前提供的 schema 为准。下面给出一个可以直接改造的分析流程；示例假设表中存在 event_date、browser、region、navigation_type、lcp_ms、inp_ms 和 cls 等规范化字段。

先查看表结构，不要一上来扫描全部数据：

# 替换为 BEACON 文档中公布的 project.dataset.table
export BEACON_TABLE='project.dataset.table'

bq show --schema --format=prettyjson "$BEACON_TABLE" > beacon-schema.json
cat beacon-schema.json

确认字段和分区方式后，可以按日期、浏览器和导航类型计算近似分位数。运行前请替换表名，并将示例字段映射到真实 schema：

-- Standard SQL
-- 将 project.dataset.table 替换为实际 BEACON 表
SELECT
  event_date,
  browser,
  region,
  navigation_type,
  COUNT(*) AS samples,
  APPROX_QUANTILES(lcp_ms, 100)[OFFSET(50)] AS lcp_p50_ms,
  APPROX_QUANTILES(lcp_ms, 100)[OFFSET(75)] AS lcp_p75_ms,
  APPROX_QUANTILES(lcp_ms, 100)[OFFSET(95)] AS lcp_p95_ms,
  APPROX_QUANTILES(inp_ms, 100)[OFFSET(75)] AS inp_p75_ms,
  APPROX_QUANTILES(cls, 100)[OFFSET(75)] AS cls_p75,
  SAFE_DIVIDE(
    COUNTIF(lcp_ms IS NOT NULL AND lcp_ms <= 2500),
    COUNTIF(lcp_ms IS NOT NULL)
  ) AS good_lcp_rate
FROM `project.dataset.table`
WHERE event_date BETWEEN DATE '2025-01-01' AND DATE '2025-01-07'
GROUP BY event_date, browser, region, navigation_type
HAVING samples >= 1000
ORDER BY event_date, samples DESC;

这里使用 APPROX_QUANTILES，是因为对数十亿条记录计算精确分位数通常没有必要。HAVING samples >= 1000 则能减少极小样本造成的剧烈波动；阈值应根据分析目标调整，而不是机械沿用。

在正式执行前，可以先做 dry run 估算扫描量：

bq query \
  --use_legacy_sql=false \
  --dry_run \
  'SELECT COUNT(*) FROM `project.dataset.table`
   WHERE event_date BETWEEN DATE "2025-01-01" AND DATE "2025-01-07"'

如果表按其他字段分区，应改用对应的分区过滤条件。面对十亿级数据，限定日期、只选择需要的列、使用近似聚合以及保存中间汇总表，往往比调整 SQL 语法细节更能控制成本。

从公共基线走向工程决策

BEACON 很适合回答跨站点、跨浏览器和跨地区的问题，但不能替代产品自己的遥测。公共 RUM 数据的用户构成、采样方式和页面类型未必与你的业务一致，匿名化记录也通常无法提供具体页面组件、发布版本或业务流程上下文。

比较稳妥的采用方式是：

用 BEACON 建立浏览器、地区和导航类型的外部基线；
用自有 RUM 验证同样的趋势是否出现在产品用户中；
用实验室工具和性能剖析器定位具体代码路径；
发布优化后，同时观察公共趋势与内部版本数据；
在报表中保留样本量、缺失率、时间范围和分位数定义。

数十亿条记录不会自动给出答案。真正可靠的结论来自正确的分组、明确的分母、受控的查询成本，以及对样本偏差的持续警惕。把 BEACON 当作现实世界的参照系，而不是一张绝对排行榜，它才能真正帮助团队做出性能工程决策。

用 BEACON 在 BigQuery 中分析数十亿条真实用户 Web 性能数据

实验室数据与 RUM 回答的是不同问题

软导航让 SPA 性能不再是盲区

在 BigQuery 中完成第一次分析

从公共基线走向工程决策

相关推荐

建议反馈