最近我把一个小项目收了尾代号就叫rea全称是 Resource Event Analytics。启动这个项目的起因非常朴素某管理后台线上问题频发用户反复反馈“点了按钮没反应”“页面要卡好几秒”但翻遍接口监控和资源监控所有指标都健康得离谱。问题出在接口耗时之外的那些环节脚本解析、长任务、事件连续触发导致的主线程拥塞单看任何一项都很难复现。rea 要做的就是把资源加载和用户交互事件这两类数据串起来还原出“用户点了一下页面里到底发生了什么”的完整链路。这个工具面向的是正在做前端基建、性能监控、稳定性治理的开发者。如果你手头已经有一套接口监控但还缺一个能定位“卡顿发生在哪个前端环节”的轻量组件这篇文章正好适合你。我会把这套实现的完整思路、关键代码、采坑记录全部拆开讲。1. rea 整体定位要解决什么问题1.1 为什么单看接口耗时不够做前端性能分析的人应该都有过这种经历用户报障说页面特别卡你打开接口监控面板发现所有请求都是绿的耗时都在 200ms 以内。接着看资源加载瀑布图也没有特别夸张的大图或者大脚本。最后只能一边在群里追问用户用的什么浏览器在哪个页面一边远程引导用户打开 DevTools 手动录一段 Performance 面板数据回来。这种排查方式最大的问题是两类信息脱节用户的操作行为和页面的资源执行过程是分开看待的。实际上很多“卡顿”不是某个接口慢而是点击事件后触发了大量脚本解析或者某个大 chunk 在点击后才被懒加载进来又或者一次连续的 scroll 事件把主线程挤爆了。这些场景里接口耗时看不出任何异常资源加载列表看起来也正常只有把事件和资源放到同一条时间线上才能看出因果。所以我做 rea 的时候先定了一个原则它不追求大而全的监控能力只做好一件事把“用户在什么时间点了什么”和“页面在什么时间加载了什么资源”关联起来。基于这个定位后面的数据结构、上报策略、采集逻辑全都围绕这个原则展开。1.2 rea 采集的三类核心数据rea 的数据模型被我拆成三层第一类是性能时序数据也就是浏览器性能 API 提供的资源加载记录。这里包括每个资源的名称、类型脚本、样式、图片、Fetch 请求等、加载耗时、传输大小、发起时间和结束时间。这些数据由 PerformanceObserver 在后台持续监听不需要主动轮询也不需要在业务代码里手动打点。第二类是交互事件数据包括用户在页面上的关键操作行为比如点击、输入、滚动、键盘事件。每条事件记录需要包含事件类型、发生时间、触发目标元素的选择器信息。值得注意的是我不采集任何表单内容只记录“在哪个按钮上点了”这种结构化信息避免隐私风险。第三类是会话上下文数据包括 sessionId、pageId、当前页面 URL、上一个页面 URL以及页面加载阶段的关键时间节点。这部分数据把前两类数据串成一个完整的可查询记录后续无论是按用户查、按页面查还是按时间范围查都能定位到具体链路。这三个数据层合起来就构成了 rea 的一条完整记录事件链。1.3 rea 的能力边界任何工具都有边界rea 也不是一个全栈监控平台。它不接后端链路追踪不做数据库层面的耗时分析也不做表单内容的采集和审计。它的目标非常明确只回答一个问题前端页面上一次交互发生时浏览器到底在执行什么、加载什么卡顿是否来自资源加载或事件处理。这意味着如果你想要的是一个完整 APM 系统、需要看后端 SQL 耗时或者慢查询那你应该去找其他方案。rea 的作用是在你已经确认“后端一切正常”的前提下帮你在前端定位根因。这个边界我在项目里反复跟同事强调过避免大家把它当成万能监控去用。2. 核心设计与实现方式拆解2.1 采集层PerformanceObserver 配合事件委托资源数据的采集最基础的方案是手动调用 performance.getEntriesByType(resource)在某个时间点一次性取所有资源。但这种方式拿不到增量数据你也不知道哪些资源是刚刚加载完成的对于“点击事件之后新发起的那批请求”无法精准定位。rea 使用的是 PerformanceObserver浏览器原生支持的观察者机制。它能持续监听资源条目的新增每条新资源出现时立刻回调。相比手动轮询它有两个明显优势一是不会漏掉资源加载的关键时间点二是不需要自己维护一个 interval 来反复读取性能数据对主线程几乎零打扰。交互事件的采集我用了事件委托加捕获阶段监听。事件委托避免给每个元素单独绑监听器捕获阶段则保证即使业务代码调用了 stopPropagationrea 依然有机会记录这次行为。事件委托的代价是需要维护一个全局的 selector 标记逻辑同时要控制事件类型数量不要什么都收集否则数据量会非常大。rea 初始默认监听 click、input、keydown、scroll、focus、blur 这几类高频且对性能分析最有价值的事件。scroll 事件本身触发频率极高必须加上节流我只记录 100ms 内最近一条滚动记录避免一秒几十条的事件风暴。这个阈值我试过再低数据爆炸再高又容易丢失长滚动的关键阶段。2.2 关联层时间窗口还原事件上下文拿到了事件记录和资源记录之后关键是“关联”。我采用的是最简单可靠的时间窗口策略每触发一次需要记录的事件时向前回溯一个时间窗口把窗口内产生的资源记录一起打进同一条事件链里。窗口长度我默认设置为 2 秒。这个值不是拍脑袋定的而是结合大量实际页面数据调整出来的一个点击行为发生后页面通常会在 2 秒内完成脚本加载、渲染更新和首帧反馈。窗口太短会漏掉点击后发起的异步请求窗口太长又会把很多无关资源算进同一条链路降低数据准确性。具体实现上我会在内存里维护一个最近资源记录的环形缓存只保留最近 10 秒的数据。这样当点击事件发生时可以直接从缓存里快速筛选出最近 2 秒资源而不是去遍历全量历史数据。这个环形缓冲需要及时清理否则长时间单页会话里内存会持续增长我在实测中控制在 200 条记录以内占用可以忽略不计。2.3 上报层批量发送、失败降级、非阻塞上报策略是我踩坑最多的部分一开始我直接在每个事件发生后立即向服务端发送一条数据结果在频繁操作时不仅把服务端打满了还因为请求本身占用了网络带宽反而加剧了页面卡顿监控工具自己成了性能瓶颈。后来我改成了批量上报先在本地维护一个数据缓冲队列每积累 30 条记录或者每 5 秒执行一次批量发送。这样既减少了网络请求次数又避免了频繁小请求带来的额外开销。发送通道我用的是 sendBeacon它有几个特点非常适合监控场景请求不会阻塞页面卸载、不占用普通请求的并发额度、浏览器会在后台择机发送。如果 sendBeacon 不可用比如低版本浏览器才降级到 fetch并且只发送当前批次不重试。监控数据本身就是高冗余数据丢掉一批不会造成致命问题反而如果实现一个复杂的重试机制可能会在网络抖动时产生大量重传请求把服务端压垮。这一点我会在后面的常见问题里详细展开。3. 动手实现一个可用的 rea 组件3.1 环境与项目初始化rea 的代码我采用原生 TypeScript 实现零运行时依赖这样它可以直接被打进任何现代前端项目的 bundle 中不用引入第三方库。如果你还在用 JavaScript 项目把类型声明去掉也能直接用。初始化步骤非常简单建一个 rea.ts 文件安装好 TypeScript 编译环境tsconfig 里把 target 设为 ES2018 以上因为要用到 static 类字段和可选链操作符。如果你用的是 Vite、Webpack 这类构建工具直接把它作为模块引入即可。# 初始化一个简单的前端项目如果你需要独立测试 npm init -y npm install typescript --save-dev npx tsc --init --target ES2018目录结构也不需要复杂我做的时候就一个核心文件 rea.ts加一个 examples/index.html 用来手动测试。逻辑不拆太散因为整个工具体积很小拆太细反而增加维护成本。3.2 初始化函数与 API 设计先看用户侧的接入方式。rea 对外暴露的构造函数和初始化 API 被设计得非常简洁你只需要传入应用标识、上报地址和采样率三个参数// rea.ts export interface ReaOptions { appId: string; endpoint: string; sampleRate?: number; } const tracker new ReaTracker({ appId: console-web, endpoint: https://your-team.example.com/rea/collect, sampleRate: 0.1 }); tracker.init();sampleRate 是采样率默认 1 表示全量采集。在生产环境我建议设置成 0.1 到 0.3 之间因为监控数据本质上是大数据量、高重复度的10% 到 30% 的样本量已经足以覆盖性能异常的分布同时能显著降低服务端存储和查询的压力。init() 方法内部会完成三件事创建资源记录缓存、绑定事件捕获监听、启动定时上报的定时器。此外我还提供了一个 setUserId 方法用来在用户登录之后把业务侧的用户 ID 关联到后续产生的记录中。这个 ID 不会写在 URL 里而是存放在记录对象内部在发送时统一带上。3.3 资源性能数据采集实现资源采集是整个 rea 的地基实现的关键是及时获取每条资源的时间字段。我封装了一个 handleResourceEntry 方法每当 PerformanceObserver 回调一个新的资源条目时就把它整理成 rea 内部的数据结构存入环形缓存。// rea.ts节选 interface ReaResourceEntry { name: string; initiatorType: string; duration: number; transferSize: number; protocol: string; startTime: number; endTime: number; } private resourceCache: ReaResourceEntry[] []; private maxCacheSize 200; private handleResourceEntry(entry: PerformanceResourceTiming) { if (this.resourceCache.length this.maxCacheSize) { this.resourceCache.shift(); } this.resourceCache.push({ name: entry.name, initiatorType: entry.initiatorType, duration: entry.duration, transferSize: entry.transferSize, protocol: entry.nextHopProtocol, startTime: entry.startTime, endTime: entry.responseEnd }); } private observeResources() { const observer new PerformanceObserver((list) { const entries list.getEntries(); for (const entry of entries) { if (entry.entryType resource) { this.handleResourceEntry(entry as PerformanceResourceTiming); } } }); observer.observe({ entryTypes: [resource] }); }注意一个细节PerformanceObserver 只会在开始 observe 之后新增的资源才触发回调页面初始化阶段已经加载完成的那些早期资源不会出现在回调里。所以我在 observeResources 之前会手动调用一次 performance.getEntriesByType(resource)把已经存在的资源先灌入缓存这样一来后续的事件关联才能覆盖整个页面生命周期。另外这里有个取舍我不保留原始 PerformanceResourceTiming 对象的所有字段只保留分析需要的几个核心字段。因为原始对象字段非常多全量保存在内存里容易造成不必要的内存压力尤其是单页长时间运行的后台系统资源数量可能达到几千条。3.4 事件采集与关联实现事件采集和关联这一块的代码是 rea 里真正区别于普通资源监控的地方。我会在每次捕获到关键事件时取出最近 2 秒内的资源记录组装成一条完整记录塞进发送缓冲区。// rea.ts节选 interface ReaEventRecord { sessionId: string; pageId: string; userId?: string; url: string; eventType: string; eventTarget: string; eventTime: number; resources: ReaResourceEntry[]; } private handleTrackedEvent(event: Event) { if (event.timeStamp this.lastEventTime) return; if (event.type scroll event.timeStamp - this.lastScrollTime 100) return; this.lastEventTime event.timeStamp; const now performance.now(); const windowStart now - 2000; const recentResources this.resourceCache.filter( (item) item.startTime windowStart ); const record: ReaEventRecord { sessionId: this.sessionId, pageId: this.pageId, userId: this.userId, url: location.href, eventType: event.type, eventTarget: this.getSelector(event.target as HTMLElement), eventTime: now, resources: recentResources }; this.pushToBuffer(record); } private bindEventListeners() { const eventTypes [click, input, keydown, scroll, focus, blur]; for (const type of eventTypes) { document.addEventListener(type, (event) { this.handleTrackedEvent(event); }, true); } }getSelector 方法会优先使用元素的 id然后使用带 class 的选择器如果目标元素在一个复杂的组件树里还要逐级向上走到父级拼出一个最短但能唯一定位元素的 selector。整个方法需要防止生成的 selector 过长我限制最多取三层父级超出部分就用 分割并截断。这里还有一个细节容易踩坑event.timeStamp 在某些浏览器里返回的是高精度时间戳在另一些浏览器里返回的是从页面初始化开始计算的时间不能直接拿它和 performance.now() 做比较。所以我统一使用 performance.now() 来生成 eventTime原始 event.timeStamp 只用于滚动事件的节流判断。3.5 批量上报与页面卸载兜底本地缓冲队列要兼顾两个目标尽可能减少请求次数同时避免数据大量积压丢失。我设置了两个触发条件任意一个满足就执行发送队列长度达到 30 条或距离上一次发送超过 5 秒。// rea.ts节选 private pushToBuffer(record: ReaEventRecord) { this.buffer.push(record); if (this.buffer.length this.maxBufferSize) { this.flush(); } } private startFlushTimer() { setInterval(() { if (this.buffer.length 0) { this.flush(); } }, 5000); } private flush() { if (this.buffer.length 0) return; const records this.buffer.splice(0, this.buffer.length); const payload JSON.stringify({ appId: this.appId, records }); if (typeof navigator.sendBeacon function) { navigator.sendBeacon(this.endpoint, payload); } else { fetch(this.endpoint, { method: POST, body: payload, keepalive: true }).catch(() {}); } }同时页面卸载前必须做一次兜底发送。如果用户在页面加载后立即关闭定时器可能来不及触发这部分数据就丢了。我在 beforeunload 和 pagehide 里都调用了 flush配合 sendBeacon 的特性保证浏览器在卸载完成前把请求发出去。对于这个实现我权衡过是否需要压缩数据。原生的 sendBeacon 支持 Blob 类型可以手动用 CompressionStream 做 gzip 压缩但考虑到兼容性和代码体积rea 初期选择不压缩。如果你的上报数据量特别大建议在后端开启 gzip 响应压缩网络传输层面的成本会低很多。4. 实测效果与性能影响分析4.1 数据准确率实测我在一个复杂的后台项目中做了两周的灰度测试接入 rea 后第 3 天就抓到了一个非常典型的问题。用户在工单列表页面反馈点击“导出”按钮后界面卡住通过 rea 的事件链数据发现点击事件发生后 1.8 秒内页面发起了三个累计超过 2MB 的脚本请求这些脚本的解析执行耗时超过 1.5 秒。接口监控里完全看不到这些脚本请求因为普通接口监控只统计 XHR 和 Fetch 请求根本不会统计脚本资源。另一个有效案例是长列表页的滚动卡顿。rea 记录的 scroll 事件数据中有一部分事件发生时间点恰好与后台发起的多张图片懒加载请求重合。通过时间窗口关联我确认了是懒加载组件在滚动过程中首次渲染时一次性加载了太多图片资源。调整懒加载的预加载距离参数之后滚动卡顿明显缓解。准确率方面我抽查了 500 条事件链记录能完整包含事件上下文和资源关联数据的占比大约 96%。另外 4% 的缺失基本来自如果浏览器版本不支持某些性能 API就会在采集时直接跳过。因此采集端的兼容性判断尽量保持在比较高的水平。4.2 对业务代码的侵入性rea 的接入方式是一行初始化调用不要求业务组件做任何改造。事件采集依赖的是 document 上的捕获阶段监听器即使业务代码在组件里调用了 stopPropagation捕获阶段依然能先于冒泡阶段拿到事件不影响业务自身的处理逻辑。我专门验证过事件监听对页面交互的影响注册了 6 类事件监听后点击按钮的响应时间几乎无感知差异。原因是捕获阶段的监听器执行非常轻量handleTrackedEvent 中唯一的开销在于从 resourceCache 中做 filter 操作而这个缓存长期保持在 200 条以内filter 一次耗时在微秒级别。实测在低端 Android 设备上rea 采集逻辑的单次耗时小于 1ms可以忽略不计。为了进一步降低生产环境影响我还加入了采样率开关默认生产建议 0.1。在采样开关开启时只有 10% 的会话会真正进入事件监听和上报流程其余用户完全不受影响。4.3 包体积与内存开销rea 打包压缩后的体积大约在 5KB 左右对于一个监控工具来说非常轻量。这个体积也让它可以被安全的打进主 bundle 里而不需要单独做异步加载。内存方面我关注两个点资源缓存和事件缓冲。资源缓存设置上限 200 条事件缓冲最多保留 30 条未上报记录所以极端情况下内存占用大概在 100KB 到 200KB 之间。这个量级对于现代浏览器和大多数移动端机型来说压力不大。不过要注意如果页面长期不刷新比如后台系统挂一天资源缓存会不断淘汰旧记录持续维持在 200 条。事件缓冲因为有定时上报通常不会积压。我在代码里没有做额外的内存监控感兴趣的人可以在 devtools 的 Memory 面板观察一下结论应该跟我一致。5. 常见问题与排查技巧实录5.1 上报数据中资源数量总是偏少这是接入 rea 后最容易遇到的问题。排查时先看资源缓存是否初始化成功如果你的代码在页面 DOMContentLoaded 之后才调用 tracker.init()页面初始化阶段的资源是拿不到的。解决方法是尽量把 rea 的初始化放在页面最早期或者使用 defer 方式加载脚本确保在资源加载爆发前完成 PerformanceObserver 的注册。还有一种情况是资源确实产生了但 PerformanceObserver 回调没有触发。这类问题大多是因为浏览器只支持 performanceObserver 的部分功能或者页面运行环境是某些 WebView 内核。我加了一个降级逻辑在 observeResources 里如果发现 PerformanceObserver 不可用就自动切换成定时器调用 performance.getEntriesByType(resource)虽然实时性差一点但至少不会白白崩溃。5.2 跨域资源拿不到详细耗时信息现代站点大量使用 CDN而 CDN 域名通常和页面主站域名不同这就涉及跨域资源 timing 读取限制。如果服务端没有返回 Timing-Allow-Origin 响应头浏览器会把跨域资源的 startTime 和 duration 直接置为 0rea 能拿到的信息就只剩下资源名称和类型这会让数据基本不可用。解决这个问题需要在 CDN 和第三方资源服务器的响应头中加上 Timing-Allow-Origin 字段并设置为主站域名。如果你用的是云厂商的 CDN直接在响应头配置里加一项即可配置生效后 rea 就能拿到完整的跨域资源加载耗时。我在实际排查中发现很多团队忽略了这一点导致采集到的资源条目有三分之一都是耗时 0 的无效数据。这类问题要尽早跟运维确认响应头配置。5.3 页面快速切换导致最后一批数据丢失在 SPA 应用里用户从 A 页面切到 B 页面时A 页面卸载前如果还有一批数据没有上报可能因为清理逻辑不完整而丢失。我做了两个处理在 pagehide 事件中强制调用 flush以及把上报通道优先选择 sendBeacon。sendBeacon 在页面生命周期末端一般会保证请求发出只要数据体积不超过限制。如果单批数据过大sendBeacon 可能失败。sendBeacon 虽然没有明确的规范大小限制但浏览器实现普遍不超过 64KB。rea 的单条事件链记录大约在 2KB 到 6KB加上资源列表后可能到 10KB 以上所以要控制批量发送的条数。我把 maxBufferSize 从 30 调整为 20这样单批最多 200KB 左右如果仍然过大可以进一步调整字段裁剪策略。5.4 上报接口偶发拥塞如果灰度期间突然接入大批用户上报请求量可能会把后端打爆。我在 rea 里做了一层简单的本地熔断单次 flush 失败后连续计数增加当连续失败达到 3 次时暂停后续上报 10 分钟然后恢复。这比复杂的指数退避更实用毕竟监控上报不是关键路径中断一段时间不影响业务。后端处理侧我建议直接落日志队列再异步进行聚合计算。不要在上报接口里做太多实时聚合逻辑否则请求稍微集中一点就很容易拖垮服务。聚合可以放到离线任务里做比如每 5 分钟统计一次。下面是这段时间遇到的问题整理成的一个速查表现象根因解决方案资源条目缺失rea 初始化太晚在页面早期注册 PerformanceObserver 或用降级轮询跨域资源耗时全为 0CDN 响应头缺少 Timing-Allow-Origin配置跨域资源响应头页面关闭后数据丢失beforeunload 内普通请求发送被取消改用 sendBeacon pagehide 兜底上报请求拥堵批量机制不合理增加本地熔断和降低采样率最后再分享一个我个人的体会。做了这么多次监控相关的工作我最大的感受是不要一上来就设计一个无所不包的复杂指标体系先想清楚你要回答哪个问题。rea 的出发点非常单一就是回答“用户交互和资源加载之间的因果关系”。抓住这个核心后面所有设计和实现都会自然收敛。接下来我会把时间窗口这个关联逻辑继续扩展尝试跟 Web-Vitals 指标做交叉分析让卡顿问题能自动判断出是长任务还是资源阻塞导致。这比堆更多字段更有意义。
