网站性能监控：RUM 和合成监控、指标，以及一次回退算例

测速告诉你一个页面某一次的表现。监控告诉你每个页面每天在真实访客那里的表现，以及什么时候变了。本文比较真实用户监控和合成监控，列出指标和阈值，并走一遍一次只在移动端出现的发布回退。

什么是网站性能监控？

网站性能监控（web performance monitoring）是对网站在访客那里有多快、多稳的持续测量：页面加载和渲染用多久，对输入的响应有多快，布局会不会跳，错误会不会打断体验。目标是在用户和收入受影响之前发现性能回退，并知道先修哪些页面、设备和地区。

它和一次性的测速不同。Lighthouse 或 PageSpeed 告诉你某一个页面、在某一台模拟设备上、某一次的表现。监控告诉你每个页面每天在真实访客那里的表现，有变化时提醒你。

两种主要方式：真实用户监控和合成监控

多数团队两者都需要：合成检查用来发现宕机、测试发布；RUM 用来看用户实际拿到了什么。服务端监控（APM）覆盖后端，比如首字节慢背后的慢查询。

多数团队两者都用，再加上监控后端的 APM。

要监控哪些指标

Google 的 Core Web Vitals 是衡量真实用户体验的标准指标组，按页面加载的第 75 百分位评估：

再加上 JavaScript 错误率、可用性（在线率），应用类产品再加 接口延迟，才算完整。

算例：发现一次发布导致的性能回退

一个电商网站按设备每天监控 P75 LCP。第 7 天的一次发布，给分类页加了一个又大又没压缩的首屏轮播图（示例数字）：

• 分类页 移动端 P75 LCP 一夜之间从 2.3 秒升到 3.5 秒。桌面端从 1.6 秒升到 1.9 秒，仍属「良好」，所以只看桌面端会漏掉。
• 移动端评为良好的加载占比 从 78% 降到 46%。
• 回退持续的三天里，分类页 移动端加购率 从 6.1% 降到 5.4%。
• 最慢页面 列表把三个分类模板排在最前面，它们都用了新的轮播组件，看了不到一小时就找到了原因。

团队把轮播的头一张换成尺寸合适、预加载的图片，其余改为懒加载。第 11 天移动端 P75 LCP 回到 2.4 秒，加购率回升到 6.0%。没有按设备拆分的 RUM，这次回退只会表现为一次说不清原因的收入下滑。

怎么搭建网站性能监控

1. 每个页面都装 RUM，确认它采集了 Core Web Vitals。
2. 按 P75 设目标，用「良好」阈值，按页面模板设，不只设全站。
3. 按设备、国家和浏览器拆分。 问题通常出在慢网络下的移动端。
4. 加上合成检查，覆盖关键页面和可用性，从用户所在的地区发起。
5. 对变化设告警，比如某个模板 P75 LCP 连续两天超过 2.5 秒，或发布后错误率翻倍。
6. 把性能和结果关联起来。 按速度分段比较转化、跳出和参与度。
7. 每次发布后复查，并在 CI 里设性能预算（图片体积、JavaScript 大小）。

常见误区

• 看平均值。 平均数掩盖了真实用户能感受到的慢尾巴，要用百分位。
• 只在快电脑上测。 开发机上的实验室结果比移动端的实际情况好得多。
• 只看一个全站分数。 问题通常只出在某个模板、某类设备或某个地区。
• 忽视低流量页面的噪声。 样本少时百分位会大幅跳动，数据够了再下结论。
• 不关联业务指标。 没有按速度看的转化，性能优化很难拿到优先级。

在 TapCub 里监控网站性能

本节已更新

监测 › 性能 展示来自真实访客浏览器的 LCP、CLS、INP、FCP 和 TTFB，可以在 P95、P75、中位数和平均值之间切换，并按页面、国家、设备、浏览器和操作系统拆分。每次加载拆成后端、网络传输和前端渲染三段，「最慢页面」列表按 P75 LCP 排序。监测 › 错误 把 JavaScript 错误分组，给出错误率、受影响的访客和会话，以及每个页面的愤怒点击和报错点击。对突发变化设置流量告警（设置流量告警），另见 查看 Core Web Vitals 和 查找 JavaScript 错误。相关阅读：真实用户监控 和 网站性能指标。

另见：首次输入延迟（FID）、DOMContentLoaded、速度指数（Speed Index）、页面体验。

另见：提升 App 性能。

资料来源

• web.dev，Web Vitals。
• web.dev，How the Core Web Vitals metrics thresholds were defined。