Skip to content

Commit daeaf80

Browse files
Fiona2016Fiona2016
authored
Merge pull request #66 from flashcatcloud/feat/rum-web-perf-impact
chore: add web performance impact
2 parents 6991ece + cf590bf commit daeaf80

3 files changed

Lines changed: 329 additions & 0 deletions

File tree

‎docs.json‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -344,6 +344,7 @@
344344
"zh/rum/sdk/web/advanced-config",
345345
"zh/rum/sdk/web/compatible",
346346
"zh/rum/sdk/web/data-collection",
347+
"zh/rum/sdk/web/performance-impact",
347348
"zh/rum/sdk/web/faq"
348349
]
349350
},
@@ -1396,6 +1397,7 @@
13961397
"en/rum/sdk/web/advanced-config",
13971398
"en/rum/sdk/web/compatible",
13981399
"en/rum/sdk/web/data-collection",
1400+
"en/rum/sdk/web/performance-impact",
13991401
"en/rum/sdk/web/faq"
14001402
]
14011403
},

‎en/rum/sdk/web/performance-impact.mdx‎

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
---
2+
title: "Performance Impact"
3+
description: "Learn about the performance impact of the Flashduty Web RUM SDK on page load, runtime CPU, memory, and network reporting, along with optimization recommendations."
4+
keywords: ["Web SDK", "performance impact", "RUM", "performance optimization", "Session Replay", "frontend monitoring"]
5+
---
6+
7+
## Overview
8+
9+
When integrating a RUM SDK into a web application, understanding its performance impact is crucial for maintaining a good user experience. The Flashduty Web RUM SDK is designed to minimize page overhead and provides transparent, reproducible benchmark data to help you evaluate whether the SDK fits your page's performance budget.
10+
11+
Integrating the SDK introduces three categories of overhead:
12+
13+
1. **Load overhead**: downloading, parsing, and initializing the SDK JS, affecting first paint and time to interactive.
14+
2. **Runtime overhead**: main-thread CPU and memory consumed by event collection, automatic instrumentation (resources, long tasks, user interactions), and Session Replay recording.
15+
3. **Network overhead**: the number and size of requests produced by periodic batched reporting.
16+
17+
<Check>
18+
Overall, **basic RUM overhead is very small** and negligible for most pages; **Session Replay is the main source of overhead**, especially on pages with large or frequently-changing DOM, and should be controlled via sampling rate and privacy configuration.
19+
</Check>
20+
21+
## Performance Impact at a Glance
22+
23+
The table below shows the overall impact (p50) relative to a no-SDK baseline for a **typical business page** (with clicks, input, and XHR), under the **recommended production configuration** (RUM + resource + long-task collection, Session Replay sampled on demand):
24+
25+
| Metric | Without SDK (baseline) | With SDK (recommended) | Impact | Assessment |
26+
| --- | --- | --- | --- | --- |
27+
| SDK size (gzip) | — | 50.0 KB | +50.0 KB (async / CDN cached) | Minimal |
28+
| SDK init time | — | 7.8 ms | +7.8 ms | Minimal |
29+
| First paint (FCP) | 20 ms | 44 ms | +24 ms | Minimal |
30+
| Main-thread CPU (runtime) | 42 ms | 78 ms | +36 ms | Small |
31+
| JS heap peak | 1.24 MB | 3.07 MB | +1.83 MB | Small |
32+
| Report size (per session window) | 0 KB | 30.5 KB | +30.5 KB | Small |
33+
34+
<Note>
35+
Assessment scale: Minimal (negligible) < Small < Moderate < Large. CPU/memory are cumulative over the entire 10s interaction window, which amortizes to very low per-second values; the SDK is loaded asynchronously via CDN and does not block the critical rendering path. These are reference values for typical scenarios; actual impact varies with page complexity, device performance, and SDK configuration.
36+
</Note>
37+
38+
## SDK Bundle Size
39+
40+
The default integration loads the full RUM bundle (including Session Replay). If you don't need recording, switch to the slim bundle to significantly reduce size.
41+
42+
| Bundle | Description | Raw | Gzip | Brotli |
43+
| --- | --- | --- | --- | --- |
44+
| `flashcat-rum.js` | Full RUM (with Session Replay) | 145.3 KB | 50.0 KB | 43.6 KB |
45+
| `flashcat-rum-slim.js` | Slim RUM (without Session Replay) | 104.9 KB | 36.2 KB | 31.7 KB |
46+
47+
<Tip>
48+
Actual transfer size is governed by the **Gzip / Brotli compressed size**. When loaded asynchronously via CDN, the SDK does not block the critical rendering path; the Session Replay recorder is lazy-loaded on demand and only downloaded when recording is enabled.
49+
</Tip>
50+
51+
## Session Replay Additional Overhead
52+
53+
Session Replay is a separate optional capability whose overhead is strongly correlated with page characteristics. The table below shows the **additional** increment (p50) over the recommended configuration when Session Replay is enabled at 100%:
54+
55+
| Scenario | CPU delta (ms) | JS heap delta (MB) | Recording report size (KB) | Assessment |
56+
| --- | --- | --- | --- | --- |
57+
| Typical business page | +11 | +0.3 | 35 | Minimal |
58+
| SPA route page | +45 | +1.5 | 125 | Small |
59+
| High-frequency DOM update page | +73 | +0.7 | 10 | Minimal |
60+
| Large table page (large DOM) | +757 | +39.5 | 1757 | Large |
61+
62+
<Warning>
63+
Session Replay overhead is manageable on ordinary pages, but is significantly amplified on **large-DOM / high-churn** pages — a larger DOM makes the initial snapshot serialization heavier, and more frequent mutations increase incremental recording and report size. We strongly recommend lowering the recording ratio via `sessionReplaySampleRate`, combined with privacy masking and region exclusion to control overhead.
64+
</Warning>
65+
66+
## Performance Impact Details
67+
68+
<AccordionGroup>
69+
<Accordion title="Initialization (init)" icon="rocket">
70+
Runs once synchronously early in the page lifecycle to parse configuration, collect context, and register features. It typically takes milliseconds and has minimal impact on FCP/LCP.
71+
</Accordion>
72+
73+
<Accordion title="Resource collection (trackResources)" icon="wifi">
74+
Uses PerformanceObserver to observe resource timing. Overhead grows with the number of page requests, but it is passive observation with low CPU usage.
75+
</Accordion>
76+
77+
<Accordion title="Long-task collection (trackLongTasks)" icon="clock">
78+
Observes `longtask` entries and only records long tasks that have already occurred; it introduces almost no additional long tasks of its own.
79+
</Accordion>
80+
81+
<Accordion title="User-interaction collection (trackUserInteractions)" icon="hand-pointer">
82+
Listens for events such as clicks and infers element names. The cost per interaction is minimal.
83+
</Accordion>
84+
85+
<Accordion title="Session Replay — main source of overhead" icon="video">
86+
- The initial full snapshot serializes the entire DOM tree, so the **larger the DOM, the higher the first recording cost** (see the large table page).
87+
- Incremental mutations are recorded continuously via MutationObserver, so the **more frequent the DOM changes, the higher the CPU and report size** (see the high-frequency DOM update page).
88+
- Recording data is compressed in a Web Worker before reporting; compression runs on the Worker thread to avoid blocking the main thread, but still adds memory and network overhead.
89+
</Accordion>
90+
</AccordionGroup>
91+
92+
## Performance Optimization Recommendations
93+
94+
<Steps>
95+
<Step title="Choose the bundle on demand">
96+
When recording is not needed, use `flashcat-rum-slim` for a smaller size (gzip 36.2 KB vs 50.0 KB).
97+
</Step>
98+
99+
<Step title="Control session and replay sampling rates">
100+
`sessionSampleRate` controls the proportion of sessions included in RUM; `sessionReplaySampleRate` **separately controls the recording ratio** (recommended well below 100%):
101+
102+
```javascript
103+
flashcatRum.init({
104+
applicationId: "<YOUR_APPLICATION_ID>",
105+
clientToken: "<YOUR_CLIENT_TOKEN>",
106+
site: "rum-server.flashcat.cloud",
107+
sessionSampleRate: 100, // proportion of sessions collected by RUM
108+
sessionReplaySampleRate: 10, // record only 10% of sessions, greatly reducing overhead
109+
trackResources: true,
110+
trackLongTasks: true,
111+
trackUserInteractions: true,
112+
defaultPrivacyLevel: "mask-user-input",
113+
});
114+
flashcatRum.startSessionReplayRecording();
115+
```
116+
</Step>
117+
118+
<Step title="Reduce recording size with privacy and trimming">
119+
Use `defaultPrivacyLevel` (`mask` / `mask-user-input` / `allow`) to mask data; use privacy markers to exclude very large or high-churn regions, reducing serialization and report size.
120+
</Step>
121+
122+
<Step title="Use beforeSend carefully">
123+
`beforeSend` is invoked for **every** RUM event; avoid heavy logic or synchronous blocking operations inside it.
124+
</Step>
125+
126+
<Step title="Disable unneeded automatic instrumentation">
127+
If you don't care about resources or long tasks, disable `trackResources` / `trackLongTasks` respectively.
128+
</Step>
129+
130+
<Step title="Load the SDK asynchronously">
131+
Load via CDN with `async` to avoid blocking the critical rendering path.
132+
</Step>
133+
</Steps>
134+
135+
## Offline Caching and Reporting
136+
137+
The SDK first writes events to a local buffer, and a background batch processor reports them in batches at a steady cadence (with backoff retries). On page unload (`visibilitychange` / `beforeunload`), it falls back to `sendBeacon` to reduce data loss. Failed reports back off according to the retry strategy and never occupy the network indefinitely.
138+
139+
## Test Methodology
140+
141+
- **Device/environment**: Apple M4 (10 cores / 16 GB), Darwin 24.5.0 arm64, Chromium 147.
142+
- **Tools**: Playwright drives Chromium; CDP `Performance.getMetrics` collects CPU / memory / DOM nodes; `PerformanceObserver` collects FCP / LCP / CLS / INP / Long Task.
143+
- **Control groups**: A = no SDK (baseline), B = basic RUM, C = RUM + resources + long tasks (recommended production config), D = + Session Replay 100%. When comparing readings: `B − A` = basic RUM overhead, `C − B` = automatic-instrumentation increment, `D − C` = Session Replay additional overhead.
144+
- **Statistic**: reported as **p50**, not the mean; JS heap is read as the post-GC "retained" value after a forced GC; report request count and size are measured from the live network, independent of transport (fetch / beacon); the no-SDK group loads zero SDK bytes.
145+
146+
<Note>
147+
Impact varies with **page complexity, device performance, and SDK configuration**; we recommend measuring on your own key pages with the benchmark tool.
148+
</Note>
149+
150+
## Related Documentation
151+
152+
<CardGroup cols={2}>
153+
<Card title="SDK Integration Guide" icon="plug" href="/en/rum/sdk/web/sdk-integration">
154+
Learn how to integrate the Web SDK
155+
</Card>
156+
<Card title="Advanced Configuration" icon="sliders" href="/en/rum/sdk/web/advanced-config">
157+
Learn about SDK advanced configuration options
158+
</Card>
159+
<Card title="Data Collection" icon="database" href="/en/rum/sdk/web/data-collection">
160+
Learn what data the SDK collects
161+
</Card>
162+
<Card title="Compatibility" icon="check-circle" href="/en/rum/sdk/web/compatible">
163+
Learn about supported platform versions
164+
</Card>
165+
</CardGroup>

‎zh/rum/sdk/web/performance-impact.mdx‎

Lines changed: 162 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,162 @@
1+
---
2+
title: "Web SDK 性能影响"
3+
description: "了解 Flashduty Web RUM SDK 接入后对页面加载、运行时 CPU、内存与网络上报的影响，以及性能优化建议。"
4+
keywords: ["Web SDK", "性能影响", "RUM", "性能优化", "Session Replay", "前端监控"]
5+
---
6+
7+
## 概述
8+
9+
在 Web 应用中接入 RUM SDK 时，了解其性能影响对于维护良好的用户体验至关重要。Flashduty Web RUM SDK 在设计时以最小化页面开销为目标，并提供透明、可复现的基准数据，帮助您评估 SDK 是否符合页面的性能预算。
10+
11+
接入 SDK 主要会引入三类开销：
12+
13+
1. **加载开销**：SDK JS 的下载、解析与初始化，影响首屏与可交互时间。
14+
2. **运行时开销**：事件采集、自动埋点（资源、长任务、用户交互）与 Session Replay 录制占用的主线程 CPU 与内存。
15+
3. **网络开销**：周期性批量上报产生的请求数量与体积。
16+
17+
<Check>
18+
整体而言，**基础 RUM 的开销很小**，对绝大多数页面可忽略；**Session Replay（会话录制）是开销的主要来源**，尤其在 DOM 规模大、变更频繁的页面上更为明显，应通过采样率与隐私配置加以控制。
19+
</Check>
20+
21+
## 综合性能影响一览
22+
23+
下表为**典型业务页面**（含点击、输入、XHR）在**推荐生产配置**（RUM + 资源 + 长任务采集，Session Replay 按需采样）下相对无 SDK 基线的整体影响（p50）：
24+
25+
| 指标 | 无 SDK（基线） | 接入 SDK（推荐配置） | 影响 | 评估 |
26+
| --- | --- | --- | --- | --- |
27+
| SDK 体积（gzip） | — | 50.0 KB | +50.0 KB（异步/CDN 缓存） | 极小 |
28+
| SDK 初始化耗时 | — | 7.8 ms | +7.8 ms | 极小 |
29+
| 首屏 FCP | 20 ms | 44 ms | +24 ms | 极小 |
30+
| 主线程 CPU（运行期） | 42 ms | 78 ms | +36 ms | 较小 |
31+
| JS Heap 峰值 | 1.24 MB | 3.07 MB | +1.83 MB | 较小 |
32+
| 上报体积（每会话窗口） | 0 KB | 30.5 KB | +30.5 KB | 较小 |
33+
34+
<Note>
35+
评估口径：极小（可忽略）< 较小 < 中等 < 较大。CPU/内存为整个 10s 交互窗口的累计值，折算到每秒均极低；SDK 体积通过 CDN 异步加载，不阻塞首屏关键渲染路径。以上为典型场景参考值，实际影响会因页面复杂度、设备性能与 SDK 配置不同而有所差异。
36+
</Note>
37+
38+
## SDK 资源体积
39+
40+
| Bundle | 说明 | 原始 | Gzip | Brotli |
41+
| --- | --- | --- | --- | --- |
42+
| `flashcat-rum.js` | 完整 RUM（含 Session Replay） | 145.3 KB | 50.0 KB | 43.6 KB |
43+
44+
<Tip>
45+
实际传输以 **Gzip / Brotli 压缩后体积** 为准。SDK 通过 CDN 异步加载时不阻塞首屏关键路径；Session Replay 的录制器（recorder）为按需懒加载，仅在开启录制时才下载。
46+
</Tip>
47+
48+
## Session Replay 额外开销
49+
50+
会话录制是独立可选能力，开销与页面特征强相关。下表为开启 Session Replay 100% 录制后，相对推荐配置的**额外**增量（p50）：
51+
52+
| 场景 | CPU 增量 (ms) | JS Heap 增量 (MB) | 录制上报体积 (KB) | 评估 |
53+
| --- | --- | --- | --- | --- |
54+
| 典型业务页 | +11 | +0.3 | 35 | 极小 |
55+
| SPA 路由页 | +45 | +1.5 | 125 | 较小 |
56+
| 高频 DOM 更新页 | +73 | +0.7 | 10 | 极小 |
57+
| 大表格页（大 DOM） | +757 | +39.5 | 1757 | 较大 |
58+
59+
<Warning>
60+
Session Replay 在普通页面上开销可控，但在**大 DOM / 高频变更**页面上会显著放大——DOM 越大首次快照序列化越重，变更越频繁增量录制与上报体积越大。强烈建议通过 `sessionReplaySampleRate` 降低录制比例，并配合隐私脱敏与区域排除控制开销。
61+
</Warning>
62+
63+
## 性能影响详解
64+
65+
<AccordionGroup>
66+
<Accordion title="初始化（init）" icon="rocket">
67+
在页面早期同步执行一次，完成配置解析、上下文采集与各 feature 注册，耗时通常毫秒级，对 FCP/LCP 影响极小。
68+
</Accordion>
69+
70+
<Accordion title="资源采集（trackResources）" icon="wifi">
71+
通过 PerformanceObserver 监听 resource timing，开销随页面请求数量增长，但属被动监听，CPU 占用低。
72+
</Accordion>
73+
74+
<Accordion title="长任务采集（trackLongTasks）" icon="clock">
75+
监听 `longtask` entry，仅记录已发生的长任务，本身几乎不引入额外长任务。
76+
</Accordion>
77+
78+
<Accordion title="用户交互采集（trackUserInteractions）" icon="hand-pointer">
79+
监听点击等事件并推断元素名称，单次交互开销极小。
80+
</Accordion>
81+
82+
<Accordion title="Session Replay（会话录制）—— 主要开销来源" icon="video">
83+
- 初始全量快照需序列化整棵 DOM 树，**DOM 越大，首次录制开销越高**（见大表格页）。
84+
- 通过 MutationObserver 持续记录增量变更，**DOM 变更越频繁，CPU 与上报体积越高**（见高频 DOM 更新页）。
85+
- 录制数据经 Web Worker 压缩后上报，压缩在 Worker 线程进行避免阻塞主线程，但仍带来内存与网络增量。
86+
</Accordion>
87+
</AccordionGroup>
88+
89+
## 性能优化建议
90+
91+
<Steps>
92+
<Step title="按需选择 bundle">
93+
不需要会话录制时使用 `flashcat-rum-slim`，体积更小（gzip 36.2 KB vs 50.0 KB）。
94+
</Step>
95+
96+
<Step title="控制会话与录制采样率">
97+
`sessionSampleRate` 控制纳入 RUM 的会话比例；`sessionReplaySampleRate` **单独控制录制比例**（建议远低于 100%）：
98+
99+
```javascript
100+
flashcatRum.init({
101+
applicationId: "<YOUR_APPLICATION_ID>",
102+
clientToken: "<YOUR_CLIENT_TOKEN>",
103+
site: "rum-server.flashcat.cloud",
104+
sessionSampleRate: 100, // 采集 RUM 的会话比例
105+
sessionReplaySampleRate: 10, // 仅 10% 会话录制，显著降低录制开销
106+
trackResources: true,
107+
trackLongTasks: true,
108+
trackUserInteractions: true,
109+
defaultPrivacyLevel: "mask-user-input",
110+
});
111+
flashcatRum.startSessionReplayRecording();
112+
```
113+
</Step>
114+
115+
<Step title="隐私与裁剪降低录制体积">
116+
用 `defaultPrivacyLevel`（`mask` / `mask-user-input` / `allow`）脱敏；对超大/高频变更区域使用隐私标记排除，减少序列化与上报体积。
117+
</Step>
118+
119+
<Step title="谨慎使用 beforeSend">
120+
`beforeSend` 对**每个** RUM 事件回调，避免在其中编写重逻辑或同步阻塞操作。
121+
</Step>
122+
123+
<Step title="关闭不需要的自动埋点">
124+
不关注资源或长任务时，可分别关闭 `trackResources` / `trackLongTasks`。
125+
</Step>
126+
127+
<Step title="异步加载 SDK">
128+
通过 CDN `async` 加载，避免阻塞首屏关键渲染路径。
129+
</Step>
130+
</Steps>
131+
132+
## 离线缓存与上报
133+
134+
SDK 将事件先写入本地缓冲，由后台批处理按节奏批量上报（带退避重试），并在页面卸载（`visibilitychange` / `beforeunload`）时通过 `sendBeacon` 兜底发送，降低数据丢失。上报失败按重试策略退避，不会无限占用网络。
135+
136+
## 测试方法
137+
138+
- **设备/环境**：Apple M4（10 核 / 16 GB），Darwin 24.5.0 arm64，Chromium 147。
139+
- **工具**：Playwright 驱动 Chromium，配合 CDP `Performance.getMetrics` 采集 CPU / 内存 / DOM 节点；`PerformanceObserver` 采集 FCP / LCP / CLS / INP / Long Task。
140+
- **对照组**：A 无 SDK（基线）、B 基础 RUM、C RUM + 资源 + 长任务（推荐生产配置）、D + Session Replay 100%。读数对比时：`B − A` = 基础 RUM 开销，`C − B` = 自动埋点增量，`D − C` = Session Replay 额外开销。
141+
- **口径**：取 **p50**，而非平均值；JS Heap 在强制 GC 后读取"回收后"值；上报请求数与体积从真实网络统计，与传输方式（fetch / beacon）无关；无 SDK 组不加载任何 SDK 字节。
142+
143+
<Note>
144+
影响随**页面复杂度、设备性能、SDK 配置**变化，建议在自身关键页面上用基准工具实测。
145+
</Note>
146+
147+
## 相关文档
148+
149+
<CardGroup cols={2}>
150+
<Card title="SDK 接入指南" icon="plug" href="/zh/rum/sdk/web/sdk-integration">
151+
了解如何接入 Web SDK
152+
</Card>
153+
<Card title="高级配置" icon="sliders" href="/zh/rum/sdk/web/advanced-config">
154+
了解如何配置 SDK 的高级功能
155+
</Card>
156+
<Card title="数据收集" icon="database" href="/zh/rum/sdk/web/data-collection">
157+
了解 SDK 收集的数据类型
158+
</Card>
159+
<Card title="兼容性" icon="check-circle" href="/zh/rum/sdk/web/compatible">
160+
了解 SDK 支持的平台版本
161+
</Card>
162+
</CardGroup>

0 commit comments

Comments
 (0)