真实用户监测（RUM）：怎么读来自真实访问的速度数据

真实用户监测告诉你网站对真正在用的人有多快，但它的数据混合了各种设备和网络。本文说明 RUM 和合成测试的区别，为什么默认看按设备分的 P75，小样本怎样误导，以及怎么把慢的细分变成修复。

什么是真实用户监测

真实用户监测（RUM）记录页面在访客自己的浏览器、设备和网络上加载和响应有多快。一个小脚本读取浏览器本来就会测量的计时，随每次页面浏览发送出去（见 MDN）。得到的是一组体验的分布，而不是一台测试机器上的一个数字。

这既是它的长处，也是它难读的地方。RUM 告诉你人们实际得到了什么，但它把光纤上的快笔记本和移动网络上的旧手机混在一起，所以读它要遵守几条规则。

RUM 和合成监测

合成监测按计划从一台受控机器加载页面。它可重复，适合在发布前发现性能退化。RUM 是发布后用户实际的体验，包括你不会去测的设备、网络和国家。多数团队两者都需要：用合成测试拦住变慢的版本，用 RUM 看真实访客有没有受影响、在哪里受影响。下表对比两者。

多数团队两者都用。

看百分位，不看平均值

加载时间有很长的尾巴：少数特别慢的加载会把平均值拉高。所以 RUM 工具报的是百分位：

• P50（中位数）：典型的一次访问。
• P75：四次访问里有三次至少这么快。Google 的 Web Vitals 指南按移动端和桌面端分开，用页面加载的 75 百分位判断网站是否达标（见 web.dev）。
• P95 / P99：最慢的那些访问，适合找出坏掉的情况。

核心指标的阈值是：最大内容绘制（LCP）不超过 2.5 秒为良好、超过 4 秒为差；交互到下次绘制（INP）不超过 200 毫秒为良好、超过 500 毫秒为差；累积布局偏移（CLS）不超过 0.1 为良好、超过 0.25 为差（见 web.dev）。另见 Web Vitals。

按设备和页面看

全站的 P75 会掩盖真正要紧的细分。先按设备拆：问题通常出在移动端。示例里，桌面端三项都达标，而移动端 LCP 为差、INP 需改进。只看全站数字，会觉得只是一般。

然后把慢的细分再按页面、国家和浏览器拆开。一个慢的模板（比如商品页），或者一个离服务器很远的国家，通常能解释大部分问题。

注意样本量。只有 40 次加载的页面，P75 一周到下一周可能差一秒。在每个百分位旁边记下样本数，样本够了再行动。

从慢的细分到修复

1. 找出 P75 最慢、且样本数有意义的细分。
2. 把加载时间拆成后端（首字节时间）、网络和前端渲染，看时间花在哪里。
3. 在实验室测试里用相同的设备和网络限速复现。
4. 修复、上线，在接下来几周比较同一细分的 P75。
5. 看人有没有留下来：比较该页面改动前后的跳出率和退出率。

RUM 看不到什么

RUM 需要脚本运行。脚本被拦截的访问，以及慢到脚本还没加载人就走了的页面，都会缺失，所以最慢的体验会被低估。它也说不出页面为什么慢，那需要实验室工具和调用追踪。另外，指标依赖浏览器支持，有些浏览器报的指标会少一些。

TapCub 里的真实用户监测

TapCub 的性能报表用的是访客浏览器里的真实加载，不是实验室测试。它显示五个指标及其良好和差的阈值：LCP（2.5 秒 / 4 秒）、CLS（0.1 / 0.25）、INP（200 毫秒 / 500 毫秒）、首次内容绘制（1.8 秒 / 3 秒）和首字节时间（800 毫秒 / 1.8 秒）。卡片可在 P95、P75、中位数和平均值之间切换；趋势和拆分可用 P50、P75、P90 或 P99，按页面、国家、设备、浏览器和操作系统拆（见文档性能）。

加载计时拆成后端、网络传输和前端渲染，最慢页面列表按 P75 LCP 排序。页面样本少时百分位会跳动；脚本被拦截时页面为空，而不会用服务器时间顶替。脚本错误是单独的报表。慢页面上的行为见怎么看热力图和网站分析指标。

常见问题

什么是真实用户监测？

从真实访客的浏览器里测量页面速度和响应能力，区别于在受控机器上跑的测试。

RUM 和合成监测有什么区别？

合成监测按计划运行脚本化测试；RUM 记录真实访客的体验。合成监测在发布前发现退化，RUM 展示真实影响。

为什么用 P75 而不是平均值？

加载时间的长尾会扭曲平均值。P75 反映了包括较慢访客在内的大多数人的体验，也是 Web Vitals 指南采用的口径。

RUM 收集哪些指标？

通常是核心 Web Vitals（LCP、INP、CLS），加上首次内容绘制、首字节时间和加载计时拆分。

RUM 会拖慢网站吗？

做得好的 RUM 脚本很小，在页面加载完或隐藏时才发送数据，影响很小。

另见：网站性能监控。

另见：网站优化。