现代 Web 应用的浏览器监控：SPA 和 API

您的正常运行时间检查显示应用正常。服务器在不到半秒的时间内以 200 状态码响应，HTML 到达，检查变绿。与此同时用户正在盯着一个加载图标，因为 JavaScript 打包渲染了应用外壳，然后一个缓慢的订单 API 导致主视图为空。您的监控没有捕捉到这一点，因为您的监控中没有运行浏览器。

这个差距是监控现代网页应用的核心问题。使用 React、Vue 或 Angular 构建的单页应用在初始 HTML 中几乎没有任何内容。用户实际获得的体验是在客户端组装的：JavaScript 启动框架，客户端路由在不加载页面的情况下切换视图，数个 API 调用填充内容。每一步都可能失败或缓慢，而 HTTP 检查却报告完美健康。

本指南涵盖了浏览器监控对 SPA 架构的意义，传统检查为何错过重要失败，应跟踪的指标，以及捕捉问题的单页应用监控步骤设置。

浏览器监控对现代网页应用的意义

浏览器监控是通过在真实浏览器中定期从受控位置加载并操作网页应用，测量实际渲染的内容来测试应用。它不是询问“服务器是否响应”，而是回答用户唯一关心的问题：页面是否可用，以及速度如何？

这个区别很重要，因为现代应用的工作划分方式。在服务器渲染的网站中，服务器发送的响应基本就是体验，因此检查响应即检查体验。而在 SPA 中，服务器主要交付骨架：一个几乎空的 HTML 文档和脚本标签。解析、框架启动、路由解析、数据获取和渲染都在浏览器中完成。HTTP 检查验证骨架，真实浏览器检查验证应用。这是传统监控不足以应对现代网页应用的核心原因。

在其合成形式中，浏览器监控按照计划驱动脚本会话：加载仪表盘，登录，搜索，加入购物车，结账。每次运行捕获每步的时间点，页面所有请求的瀑布图，失败及位置记录，以及浏览器控制台的错误。当运行失败时，您知道哪个步骤崩溃，哪个请求导致，以及用户看到什么。有效断言不是按钮是否可点击，而是订单确认号码是否渲染，保存的报告是否出现在列表中，权限更改是否生效。浏览器监控靠验证状态而非仅仅验证屏幕赢得价值。

为什么单页应用打破传统监控

SPA 的三个架构特征导致了大多数监控盲点：初始负载不包含内容，导航根本不访问服务器，以及渲染层将“请求完成”与“用户可见”分离。每个特征都打破了传统工具依赖的不同假设。

首次绘制是虚张声势

加载 React 或 Vue 应用时，浏览器几乎立即触发 DOMContentLoaded，因为文档非常小。但此时用户几乎看不到任何内容。框架仍然需要下载并执行包，加载组件树，获取数据，并渲染。任何基于文档加载事件的指标都会在应用可点击之前就宣告成功。浏览器定义的“已加载”与人类定义的“可用”之间的距离，正是 SPA 监控必须工作的地方。骨架加载使这一虚假表现更严重：灰色占位框可以获得极佳的最大内容绘制分数，而使视图可用的数据获取甚至都未开始，所以应用看起来快却功能死寂。更好的问题是路由何时拥有足够的用户特定数据以便使用。

客户端路由使导航变得隐形

当用户从产品列表点击到产品详情视图时，网络层面没有导航发生。路由拦截点击，通过 History API 重写 URL，并就地替换组件，这称为软导航。浏览器不会记录页面加载和导航时长。仅计算页面加载的监控会认为用户只访问过一次且无进一步操作，永远不会注意到结账路由渲染需时九秒。相同盲点也破坏分析：在任何只计完整页面加载的工具中，查看了十个产品的 SPA 用户可以被统计为单页面跳出。路由切换必须有意测量，从触发点击到新视图内容呈现时刻。测量方式因路由与渲染架构不同而异：纯客户端渲染、带水合的服务端渲染和混合方案各有延迟隐藏所在。

渲染层将响应与用户所见分离

框架在成功响应和可见 UI 之间插入渲染层：React 和 Vue 对组件输出进行调和后再提交 DOM 更新，Angular 的变更检测决定何时绑定数据达到模板。内容可能在 API 响应到达后稍晚出现，或者如果渲染错误被错误边界吞噬，则永远不出现。对监控而言，这意味着干净的 API 响应几乎无价值：端点可能返回完美 JSON，而显示它的组件悄无声息地失败。检查必须断言渲染后输出，而非响应码。渲染层亦惩罚脆弱脚本：CSS-in-JS 库生成的哈希类名在每次构建中变化，目标这些类名的检查在每次部署后都会失败。像 data-testid 属性或 ARIA 角色这类稳定钩子，才是保持浏览器检查可维护的关键。

React、Vue 和 Angular 的框架特定失败模式

三个主要框架共享上述盲点但以各自方言失败，监控知道指向的是哪个应用时效果更佳。

• React。 错误边界设计用来以后备 UI 替换崩溃的组件，这保持应用存活，但同时隐藏了失败：无失败请求，无空白页面，只有一视图静默失去功能。懒加载路由带来了第二个陷阱，失败的动态导入可能使路由陷于加载状态。内容断言捕获两者；状态码两者皆不捕获。监控 React 应用的挑战需要单独清单。
• Vue。 Vue 的响应式系统自动追踪依赖，深层嵌套响应式对象或长观察链可以使一次小的状态改变扇出为级联更新。症状是交互迟缓，而非错误，因此监控 Vue.js 应用更多依赖交互时间而非错误计数。
• Angular。 Zone.js 在事件后触发整个组件树的变更检测，因此繁重的模板或未优化绑定使每次交互稍慢，而非令单个请求失败。关注交互延迟趋势，而非仅依赖通过/失败结果。

共同点：框架问题很少产生失败请求。它们造成延迟和缺失内容，这正是浏览器检查能检测、HTTP 检查看不到的。

API 依赖问题

在 SPA 中，API 性能即用户体验。单个仪表盘视图可能由几个端点组装：会话、用户资料、权限、主数据、通知。最慢的阻塞调用限制了整个视图，用户感受到的不是“某个端点降级”，而是感觉应用失效。

缓慢的令牌刷新延迟了所有排队的认证调用。推荐和购物车端点超时。页面呈现空白部分，用户刷新，刷新导致负载加倍压力倍增。每个服务单独看似健康，只有浏览器能看到它们同时失败。

第三方依赖使风险更大。支付处理器、认证提供商、分析标签和聊天小部件都加载在同一页面，任何一个都可能在您无法控制的时间表内降级。您无法修复供应商基础设施，但可以在用户发现之前先知道。

实际方案是双层监控。直接通过Web API 监控监测关键端点，获得响应时间、错误率和负载正确性等干净数据。然后用浏览器检查在上下文中监视相同端点，因为阻塞呈现的 300 毫秒端点对用户伤害大于不阻塞的 800 毫秒端点。瀑布图是这两种视图的结合：所有页面发起请求的顺序及时间点，可以看到哪个调用真正拖慢了视图。

可行的事件规则：如果直接 API 检查慢且浏览器步骤慢，先从服务端查起；如果 API 检查正常但浏览器步骤慢，查客户端阻塞：包执行、水合、第三方脚本或串行调用瀑布图。若两者均绿灯且用户仍投诉，比对区域与认证角色后再责怪监控。

重要的浏览器监控指标

现代网页应用的计分板分为两部分：Google 提出的核心网页生命力（Core Web Vitals）衡量加载体验，以及 SPA 特有的指标，后者核心生命力未涵盖。

阈值根据Google 公布的目标，基于页面加载的第 75 百分位评估。值得注意的废弃项是：首次输入延迟 (FID) 于 2024 年 3 月退役，INP 取代其作为响应性核心指标。INP 是更严格的评判者，因为它测量整个访问期间的交互延迟，而非仅首个交互的前延。若仪表盘仍报告 FID，则该指标不再被 Google 使用。

核心网页生命力设计基于页面加载，因此很好描述第一次印象，但对用户在应用中度过的数小时中软导航所做的工作描述有限。补足画面需依赖 SPA 特有度量：

• 路由切换时长。 从触发点击到新视图渲染完成的时间，按路由追踪，因重型管理路由与轻量设置页不应共用阈值。
• 每步事务时间。 脚本化旅程（登录、搜索、加入购物车、支付）中每步的时间基线，便于发现性能回归定位具体步骤。
• 每端点的 API 响应时间和错误率。 按端点细分而非整应用平均，因为平均值掩盖了阻塞渲染的一慢调用。
• JavaScript 控制台错误。 检查中未捕获异常和资源加载失败是功能悄然退化的前兆。
• 第三方阻塞时间。 加载与交互路径中等待非自营脚本和服务的时间。

单页应用监控指南（步骤详解）

以下是一个将上述元素付诸实践的设置流程。

步骤 1：采用真实浏览器的正常运行时间检查

以固定频率用真实浏览器检查应用入口 URL。不同于 HTTP ping，它下载包，执行 JavaScript，并在真实浏览器中渲染页面，因此应用失败时检查失败，不仅仅是服务器失败。这是网页应用监控的基础层：廉价、频繁并真实反映应用是否启动。

步骤 2：编写产生收益的用户流程脚本

选择三到五个产生收入或留存的流程：登录、搜索、结账，产品核心工作流。用如EveryStep此类工具记录为脚本化事务，捕获实际点击、键入和等待，按计划重放。脚本化旅程是唯一模拟真实用户操作客户端路由的检查。

步骤 3：断言渲染内容，使用稳定选择器

每步都断言某个有意义内容渲染：订单总额出现，搜索返回结果，仪表盘图表绘制。断言状态而非仅有元素存在：验证提交按钮在表单有效时启用，加载旋转图标已经从 DOM 移除。针对稳定属性如 data-testid 或 ARIA 角色而非自动生成的类名，脚本能经受部署考验而非每次喊“狼来了”。

步骤 4：为底层端点添加直接 API 检查

为所有关键视图依赖的端点设置独立检查，含响应时间阈值和内容验证，也包含第三方服务。浏览器检查失败时，端点数据能秒级指示问题根源是前端、API 还是第三方。

步骤 5：从用户所在地区运行检查

靠近源站的快速包可能远隔重洋时迟缓，CDN 或 DNS 问题常有区域性。应从实际流量地区发起检查，捕获新加坡用户感受到的延迟，而非数据中心的顺畅。

步骤 6：基于步骤设置报警，而非仅会话

为旅程每步设阈值，不为全脚本设单一超时，且对持续退化报警，而非单次慢运行。结账步骤从两秒漂移到六秒值得有人被唤醒，即便脚本仍技术上通过。调优良好的监控警报是您信任系统与静音系统的分水岭。

SPA 的合成监控与真实用户监控对比

真实用户监控（RUM）通过 JavaScript 片段注入应用，报告真实访客经历。其优势在广度：真实设备、真实网络及核心网页生命力的现场数据。限制是必须有人流。无法在凌晨三点用户尚未访问的断点结账检测到故障，无法测试不希望注入的登录后流程，且只有足够用户遭遇后才浮现回归。

合成监控则反向：受控、定时、脚本化监测，无需用户，捕捉失败并持续提供干净的基线供周对周对照。对于 SPA，合成浏览器检查是按您日程而非用户进行路由、渲染和 API 依赖的层。对 SPA，建议将警报放在合成监控，且保留 RUM 作为调查工具：RUM 显示受影响的真实用户数和设备，而合成监控回答登录、搜索或结账是否当前就坏，即便无人使用。Google Chrome 用户体验报告等现场数据补强取样设备和网络的真实世界分布。

总结

现代网页应用将工作及失败移入浏览器。初始 HTML 无法证明任何问题，导航无页面加载，每个视图依赖一连串可能悄然失败的 API 调用。监控必须跟进这点：基于真实浏览器断言渲染内容、按营业路线的脚本化旅程、对底层端点的直接监控，以及描述用户感受的指标（LCP、INP、CLS、路由变更和每步时间），而不仅仅是服务器报告。如果您当前监控无法区分真实渲染页面与带有 200 状态码的空壳，那这正是首先要修补的缺口。

常见问题解答