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: content/en/real_user_monitoring/_index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -141,7 +141,7 @@ Select an application from the top navigation, or follow the setup instructions
141
141
142
142
The [RUM Performance Monitoring summary][1] page provides relevant and actionable insights for both web and mobile applications. You have a tailored experience for each platform that helps you:
143
143
144
-
-**Focus on key data points** by platform, such as the UI latency for web or mobile crashes
144
+
-**Focus on key datapoints** by platform, such as the UI latency for web or mobile crashes
145
145
-**Monitor application health** through familiar KPIs, such as Core Web Vitals for web apps or hang rate for iOS, to assess app reliability
146
146
-**Dive into investigations directly** from interactive widgets without leaving the page
Copy file name to clipboardExpand all lines: content/en/real_user_monitoring/browser/data_collected.md
+15-15Lines changed: 15 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,9 +27,9 @@ further_reading:
27
27
28
28
## Overview
29
29
30
-
The RUM Browser SDK generates events that have associated metrics and attributes. Every RUM event has all of the [default attributes](#default-attributes), for example, the URL of the page (`view.url`) and user information such as their device type (`device.type`) and their country (`geo.country`).
30
+
The RUM Browser SDK generates events that have associated telemetry and attributes. Every RUM event has all of the [default attributes](#default-attributes), for example, the URL of the page (`view.url`) and user information such as their device type (`device.type`) and their country (`geo.country`).
31
31
32
-
There are additional [metrics and attributes specific to a given event type](#event-specific-metrics-and-attributes). For example, the `view.loading_time`metric is associated with view events, and the `resource.method` attribute is associated with resource events.
32
+
There are additional [attributes specific to a given event type](#event-specific-attributes). For example, the `view.loading_time`telemetry is associated with view events, and the `resource.method` attribute is associated with resource events.
@@ -48,11 +48,11 @@ The following diagram illustrates the RUM event hierarchy:
48
48
49
49
See a complete list of [Standard Attributes][1] for RUM Browser. By default, the attributes are attached to each event type, so you can use them regardless of the RUM event type being queried.
|`resource.duration`| number | Entire time spent loading the resource. |
120
120
|`resource.size`| number (bytes) | Resource size. |
121
121
|`resource.connect.duration`| number (ns) | Time spent establishing a connection to the server (connectEnd - connectStart). |
122
-
|`resource.ssl.duration`| number (ns) | Time spent for the TLS handshake. If the last request is not over HTTPS, this metric does not appear (connectEnd - secureConnectionStart). |
122
+
|`resource.ssl.duration`| number (ns) | Time spent for the TLS handshake. If the last request is not over HTTPS, this attribute does not appear (connectEnd - secureConnectionStart). |
123
123
|`resource.dns.duration`| number (ns) | Time spent resolving the DNS name of the last request (domainLookupEnd - domainLookupStart). |
124
124
|`resource.redirect.duration`| number (ns) | Time spent on subsequent HTTP requests (redirectEnd - redirectStart). |
125
125
|`resource.first_byte.duration`| number (ns) | Time spent waiting for the first byte of response to be received (responseStart - RequestStart). |
@@ -141,9 +141,9 @@ Detailed network timing data for the loading of an application's resources are c
141
141
|`resource.provider.domain`| string | The resource provider domain. |
142
142
|`resource.provider.type`| string | The resource provider type (for example, `first-party`, `cdn`, `ad`, or `analytics`). |
Frustration signals appear as high-level data points representing sources of user frustration on the [**RUM Applications** page][1]. To display a list of frustration counts in the [RUM Explorer][2], click the **Options** button and add a column for `@session.frustration.count`.
68
+
Frustration signals appear as high-level datapoints representing sources of user frustration on the [**RUM Applications** page][1]. To display a list of frustration counts in the [RUM Explorer][2], click the **Options** button and add a column for `@session.frustration.count`.
Copy file name to clipboardExpand all lines: content/en/real_user_monitoring/browser/monitoring_page_performance.md
+11-11Lines changed: 11 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,45 +23,45 @@ further_reading:
23
23
24
24
## Overview
25
25
26
-
RUM view events collect extensive performance metrics for every pageview. Monitor your application's pageviews and explore performance metrics in dashboards and the RUM Explorer.
26
+
RUM view events collect extensive performance telemetry for every pageview. Monitor your application's pageviews and explore performance telemetry in dashboards and the RUM Explorer.
27
27
28
28
{{< img src="real_user_monitoring/browser/waterfall-4.png" alt="A waterfall graph on the Performance tab of a RUM view in the RUM Explorer" style="width:100%;" >}}
29
29
30
-
You can access performance metrics for your views in:
30
+
You can access performance telemetry for your views in:
31
31
32
-
- Out-of-the-box [RUM dashboards][1], which provide a high-level view of your application's performance. For example, you can filter on [default attributes][2] collected by RUM to surface issues impacting a subset of users in the [Performance Overview dashboard][3]. You can also clone this dashboard, customize it to your needs, and use any [RUM performance metrics](#all-performance-metrics) in the dashboard's query.
32
+
- Out-of-the-box [RUM dashboards][1], which provide a high-level view of your application's performance. For example, you can filter on [default attributes][2] collected by RUM to surface issues impacting a subset of users in the [Performance Overview dashboard][3]. You can also clone this dashboard, customize it to your needs, and use any [RUM performance telemetry](#all-performance-telemetry) in the dashboard's query.
33
33
- A performance waterfall, accessible for every RUM view event in the [RUM Explorer][4], which enables you to troubleshoot the performance of a specific page view. It displays how your website assets and resources, long tasks, and frontend errors affect the page-level performance for your end users.
34
34
35
35
## Event timings and core web vitals
36
36
37
37
<divclass="alert alert-warning">
38
-
Datadog's Core Web Vitals metrics are available from the <ahref="https://github.com/DataDog/browser-sdk">@datadog/browser-rum</a> package v2.2.0+.
38
+
Datadog's Core Web Vitals telemetry is available from the <ahref="https://github.com/DataDog/browser-sdk">@datadog/browser-rum</a> package v2.2.0+.
39
39
</div>
40
40
41
-
[Google's Core Web Vitals][5] are a set of three metrics designed to monitor a site's user experience. These metrics focus on giving you a view of load performance, interactivity, and visual stability. Each metric comes with guidance on the range of values that translate to good user experience. Datadog recommends monitoring the 75th percentile for these metrics.
41
+
[Google's Core Web Vitals][5] are a set of three KPIs designed to monitor a site's user experience. These KPIs focus on giving you a view of load performance, interactivity, and visual stability. Each KPI comes with guidance on the range of values that translate to good user experience. Datadog recommends monitoring the 75th percentile for these KPIs.
42
42
43
43
{{< img src="real_user_monitoring/browser/core-web-vitals-1.png" alt="Core Web Vitals summary visualization" >}}
44
44
45
45
- 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).
46
-
-Metrics collected from your real users' pageviews may differ from those calculated for pages loaded in a fixed, controlled environment such as a [Synthetic browser test][6]. Synthetic Monitoring displays Largest Contentful Paint and Cumulative Layout Shift as lab metrics, not real metrics.
46
+
-Telemetry collected from your real users' pageviews may differ from those calculated for pages loaded in a fixed, controlled environment such as a [Synthetic browser test][6]. Synthetic Monitoring displays Largest Contentful Paint and Cumulative Layout Shift as lab telemetry, not real telemetry.
|[Largest Contentful Paint][7]| Load performance | Moment in the page load timeline in which the largest DOM object in the viewport (as in, visible on screen) is rendered. | <2.5s |
51
51
|[Interaction To Next Paint][19]| Interactivity | Longest duration between a user's interaction with the page and the next paint. Requires RUM SDK v5.1.0. | <200ms |
52
52
|[Cumulative Layout Shift][9]| Visual stability | Quantifies unexpected page movement due to dynamically loaded content (for example, third-party ads) where 0 means that no shifts are happening. | <0.1 |
53
53
54
54
### Core web vitals target elements
55
55
56
-
Identifying what element triggered a high Core Web Vitals metric is the first step in understanding the root cause and being able to improve performance.
56
+
Identifying what element triggered a high Core Web Vitals KPI is the first step in understanding the root cause and being able to improve performance.
57
57
RUM reports the element that is associated with each Core Web Vital instance:
58
58
59
59
- For Largest Contentful Paint, RUM reports the CSS Selector of the element corresponding to the largest contentful paint.
60
60
- For Interaction to Next Paint, RUM reports the CSS selector of the element associated with the longest interaction to the next paint.
61
61
- For First Input Delay, RUM reports the CSS selector of the first element the user interacted with.
62
62
- For Cumulative Layout Shift, RUM reports the CSS selector of the most shifted element contributing to the CLS.
@@ -90,7 +90,7 @@ RUM reports the element that is associated with each Core Web Vital instance:
90
90
91
91
For single page applications (SPAs), the RUM Browser SDK differentiates between `initial_load` and `route_change` navigation with the `loading_type` attribute. If an interaction on your web page leads to a different URL without a full refresh of the page, the RUM SDK starts a new view event with `loading_type:route_change`. RUM tracks URL changes using the [History API][16].
92
92
93
-
Datadog provides a unique performance metric, `loading_time`, which calculates the time needed for a page to load. This metric works for both `initial_load` and `route_change` navigation.
93
+
Datadog provides a unique KPI, `loading_time`, which calculates the time needed for a page to load. This KPI works for both `initial_load` and `route_change` navigation.
94
94
95
95
### How loading time is calculated
96
96
@@ -144,7 +144,7 @@ window.DD_RUM.init({
144
144
145
145
The RUM SDK automatically monitors frameworks that rely on hash (`#`) navigation. The SDK watches for `HashChangeEvent` and issues a new view. Events coming from an HTML anchor tag which do not affect the current view context are ignored.
146
146
147
-
## Create custom performance metrics
147
+
## Create custom performance telemetry
148
148
149
149
### Measure component-level performance with custom vitals
Copy file name to clipboardExpand all lines: content/en/real_user_monitoring/browser/monitoring_resource_performance.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,7 +31,7 @@ See [Connect RUM and Traces][2] for information about setting up this feature.
31
31
32
32
{{< img src="real_user_monitoring/browser/resource_performance_graph.png" alt="APM Trace information for a RUM Resource" >}}
33
33
34
-
## Resource timing and metrics
34
+
## Resource attributes
35
35
36
36
Detailed network timing data for resources is collected from the Fetch and XHR native browser methods and from the [Performance Resource Timing API][3].
37
37
@@ -40,7 +40,7 @@ Detailed network timing data for resources is collected from the Fetch and XHR n
40
40
|`resource.duration`| number | Entire time spent loading the resource. |
41
41
|`resource.size`| number (bytes) | Resource size. |
42
42
|`resource.connect.duration`| number (ns) | Time spent establishing a connection to the server (connectEnd - connectStart). |
43
-
|`resource.ssl.duration`| number (ns) | Time spent for the TLS handshake. If the last request is not over HTTPS, this metric does not appear (connectEnd - secureConnectionStart). |
43
+
|`resource.ssl.duration`| number (ns) | Time spent for the TLS handshake. If the last request is not over HTTPS, this attribute does not appear (connectEnd - secureConnectionStart). |
44
44
|`resource.dns.duration`| number (ns) | Time spent resolving the DNS name of the last request (domainLookupEnd - domainLookupStart). |
45
45
|`resource.redirect.duration`| number (ns) | Time spent on subsequent HTTP requests (redirectEnd - redirectStart). |
46
46
|`resource.first_byte.duration`| number (ns) | Time spent waiting for the first byte of response to be received (responseStart - RequestStart). |
0 commit comments