You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: flashduty/en/2. RUM/3. Performance Monitoring/2. Metrics.md
+26-7Lines changed: 26 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,6 +25,10 @@ In addition to core metrics, it also supports other auxiliary metrics:
25
25
26
26
These metrics are automatically collected when users visit pages and reported to the Flashduty platform through the SDK. You can view detailed performance data in the analysis dashboard.
27
27
28
+
:::tip
29
+
Interaction to Next Paint and Largest Contentful Paint are not collected for pages opened in the background (for example, in a new tab or a window without focus).
30
+
:::
31
+
28
32
## Metric Calculation Methods
29
33
30
34
### 1. Largest Contentful Paint (LCP)
@@ -53,6 +57,18 @@ These metrics are automatically collected when users visit pages and reported to
53
57
-**Use case**: Optimize response speed for interaction-intensive pages (such as forms, navigation menus).
54
58
55
59
60
+
## Monitoring Single Page Applications (SPA)
61
+
62
+
For Single Page Applications (SPA), the RUM browser SDK distinguishes between two navigation types through the `loading_type` attribute: `initial_load` and `route_change`.
63
+
64
+
1. History Single Page Applications
65
+
If an interaction on a webpage causes the URL to change but the page does not refresh completely, the RUM SDK will start a new `view` using `loading_type:route_change`. RUM uses the [History API](https://developer.mozilla.org/en-US/docs/Web/API/History) to track URL changes.
66
+
67
+
2. Hash Single Page Applications
68
+
The RUM SDK automatically monitors frameworks that rely on hash (`#`) navigation. The SDK listens for `HashChangeEvent` and issues a new `view`. Events from HTML anchors that do not affect the current view context are ignored.
69
+
70
+
For SPA applications, if you need to monitor performance after route changes, it is recommended to use the [Custom Performance Monitoring](#Custom%20Performance%20Monitoring) feature to measure performance metrics of specific components or interactions.
71
+
56
72
## Custom Performance Monitoring
57
73
58
74
### 1. Component-level Performance Measurement
@@ -122,13 +138,7 @@ document.addEventListener("scroll", function handler() {
122
138
- Use descriptive naming (such as `login_form_render`).
123
139
- Maintain naming consistency.
124
140
125
-
### 2. SPA Scenario Handling
126
-
127
-
- When route changes, timing is based on the start time of the current RUM view.
128
-
- Some timers need to be reset.
129
-
- Pay attention to metric continuity during page transitions.
130
-
131
-
### 3. Performance Impact Control
141
+
### 2. Performance Impact Control
132
142
133
143
- Control the number of custom metrics.
134
144
- Avoid frequent timing.
@@ -154,6 +164,15 @@ document.addEventListener("scroll", function handler() {
154
164
- Ensure timers are started and stopped correctly.
155
165
- Check timestamp accuracy in asynchronous scenarios.
156
166
167
+
### 4. Empty Web Vitals Metrics Collection
168
+
169
+
-**Background pages**: Pages opened in new tabs or unfocused windows, causing INP and LCP to be uncollectable
170
+
-**SPA route changes**: During `loading_type:route_change`, Core Web Vitals metrics (LCP, CLS, INP, FCP) will not be re-collected
171
+
-**Integration method**: Page loads completely before SDK is fully initialized
172
+
-**Page lifecycle**: Page is closed or navigated away before metrics collection is complete
173
+
-**Browser compatibility**: Older browser versions do not support certain Web Vitals APIs
174
+
-**Empty page content**: Page has no measurable content elements (such as blank pages)
0 commit comments