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: src/docs/product/performance/web-vitals.mdx
+52-49Lines changed: 52 additions & 49 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,87 +8,90 @@ description: "Learn more about Web Vitals in Sentry, and how they give you a bet
8
8
9
9
The in-browser Sentry SDKs collect Web Vitals information (where supported) and add that information to frontend transactions. These vitals are then summarized in several graphs for a quick overview of how each frontend transaction is performing for your users.
|[Time To First Byte](#time-to-first-byte-ttfb) (TTFB) | Chromium, Firefox, and Safari | 200+ milliseconds | 600+ milliseconds |
11
+
21
12
22
-
<Note>
13
+
## Core Web Vitals
14
+
These Web Vitals are considered the most important by Google and directly measure the user experience. [Google reports that as of May 2021, these metrics also impact your search ranking](https://developers.google.com/search/blog/2020/11/timing-for-page-experience).
23
15
24
-
Some Web Vitals such as FP, FCP, LCP, and TTFB are measured relative to the start of the transaction. Values may differ when compared to values generated with other tools such as [Lighthouse](https://github.com/GoogleChrome/lighthouse).
16
+
### Largest Contentful Paint (LCP)
25
17
26
-
</Note>
27
-
28
-
## Distribution Histogram
18
+
[Largest Contentful Paint (LCP)](https://web.dev/lcp/) measures the render time for the largest content to appear in the viewport. This may be in any form from the document object model (DOM), such as images, SVGs, or text blocks. It is the largest pixel area in the viewport, thus most visually defining. LCP helps developers understand how long it takes before the user sees the main content on the page.
29
19
30
-
A histogram visualization showing the data distribution can help you identify and diagnose frontend performance problems by revealing anomalies.
20
+
### First Input Delay (FID)
31
21
32
-
By default, outliers will be excluded from the histograms to provide a more informative view of these vitals. Outliers are determined using the [upper outer fence](https://en.wikipedia.org/wiki/Outlier#Tukey's_fences) as the upper bound, and any data points above the upper bound are deemed an outlier.
22
+
[First Input Delay (FID)](https://web.dev/fid/) measures the response time when the user tries to interact with the viewport. Actions may include clicking a button, link, or other custom Javascript controller. FID provides critical data on successful or unsuccessful interactions on an application page.
33
23
34
-
If you notice a region of interest on any of the histograms, click and drag over the area to zoom in for a more detailed view. You may also want to see more information related to the transactions in the histograms. Click "Open in Discover" beneath the Web Vital of choice to build a custom query for further investigation. For more details, see the full documentation for the Discover [Query Builder](/product/discover-queries/query-builder/).
24
+
### Cumulative Layout Shift (CLS)
35
25
36
-
If you wish to see all of the data available, open the dropdown and click "View All". You will likely see extreme outliers when you click "View All". You can click and drag over an area to zoom in for a more detailed view.
26
+
[Cumulative Layout Shift (CLS)](https://web.dev/cls/) is the sum of individual layout shift scores for every unexpected element shift during the rendering process. Imagine navigating to an article and trying to click a link before the page finishes loading. Before your cursor even gets there, the link may have shifted down due to an image rendering. Rather than using duration for this Web Vital, the CLS score represents the extent of the disruptive and visually unstable shifts.
37
27
38
-
## Thresholds
28
+
39
29
40
-
Google's "Bad", "Needs improvement", and "Good" levels are used to classify data points into red, yellow, and green for the corresponding Web Vitals. "Needs improvement" is sometimes referred to as "Meh" in Sentry.
30
+
Each layout shift score is calculated using an impact and distance fraction. The impact fraction is the total visible area that the element affects between the two rendered frames. The distance fraction measures the distance it has moved relative to the viewport.
41
31
42
-
The vertical line for each Web Vital is the 75th percentile of the observed data points. In other words, 25% of the recorded values exceed that amount. If the value exceeds the Google Web Vitals "Bad" threshold, the Web Vital status is marked as "Fail".
Let’s take a look at the example above which has one unstable element - the body text. The impact fraction is roughly 50% of the page and moves the body text down by 20%. The layout shift score is 0.1, the product of 0.5*0.2. Thus, CLS is 0.1.
45
37
46
-
For [Performance Metrics](../metrics/), "75th percentile" and "failure threshold" normally apply to transaction duration. Here, they instead refer to the individual Web Vitals.
38
+
## Other Web Vitals
47
39
48
-
</Note>
40
+
These Web Vitals are generally less user-visible, but are useful for troubleshooting issues with the Core Web Vitals.
49
41
50
-
##Supported Web Vitals
42
+
### First Paint (FP)
51
43
52
-
44
+
First Paint (FP) measures the amount of time the first pixel takes to appear in the viewport, rendering any visual change from what was previously displayed. This may be in any form from the document object model (DOM), such as background color, canvas, or image. FP helps developers understand if anything unexpected is happening to render the page.
53
45
54
-
### Core Web Vitals
46
+
### First Contentful Paint (FCP)
55
47
56
-
These Web Vitals are considered the most important by Google and directly measure the user experience. [Google reports that as of May 2021, these metrics also impact your search ranking](https://developers.google.com/search/blog/2020/11/timing-for-page-experience).
48
+
[First Contentful Paint (FCP)](https://web.dev/fcp/) measures the time for the first content to render in the viewport. This may be in any form from the document object model (DOM), such as images, SVGs, or text blocks. FCP frequently overlaps with First Paint (FP). FCP helps developers understand how long it takes before the user sees any content change on the page.
57
49
58
-
#### Largest Contentful Paint (LCP)
50
+
###Time To First Byte (TTFB)
59
51
60
-
[Largest Contentful Paint (LCP)](https://web.dev/lcp/) measures the render time for the largest content to appear in the viewport. This may be in any form from the document object model (DOM), such as images, SVGs, or text blocks. It is the largest pixel area in the viewport, thus most visually defining. LCP helps developers understand how long it takes before the user sees the main content on the page.
52
+
[Time To First Byte (TTFB)](https://web.dev/time-to-first-byte/) measures the time that it takes for a user's browser to receive the first byte of page content. TTFB helps developers understand whether their slowness is caused by the initial response or instead due to render-blocking content.
61
53
62
-
#### First Input Delay (FID)
54
+
##Thresholds
63
55
64
-
[First Input Delay (FID)](https://web.dev/fid/) measures the response time when the user tries to interact with the viewport. Actions may include clicking a button, link, or other custom Javascript controller. FID provides critical data on successful or unsuccessful interactions on an application page.
56
+
Google's "Good", "Needs Improvement", and "Poor" thresholds are used to classify data points into green, yellow, and red for the corresponding Web Vitals. "Needs improvement" is referred to as "Meh" in Sentry.
|[Time To First Byte](#time-to-first-byte-ttfb) (TTFB) | <=100ms| <=200ms| > 600ms |
67
66
68
-
[Cumulative Layout Shift (CLS)](https://web.dev/cls/) is the sum of individual layout shift scores for every unexpected element shift during the rendering process. Imagine navigating to an article and trying to click a link before the page finishes loading. Before your cursor even gets there, the link may have shifted down due to an image rendering. Rather than using duration for this Web Vital, the CLS score represents the extent of the disruptive and visually unstable shifts.
67
+
<Note>
69
68
70
-
69
+
Some Web Vitals such as FP, FCP, LCP, and TTFB are measured relative to the start of the transaction. Values may differ when compared to values generated with other tools such as [Lighthouse](https://github.com/GoogleChrome/lighthouse).
71
70
72
-
Each layout shift score is calculated using an impact and distance fraction. The impact fraction is the total visible area that the element affects between the two rendered frames. The distance fraction measures the distance it has moved relative to the viewport.
Let’s take a look at the example above which has one unstable element - the body text. The impact fraction is roughly 50% of the page and moves the body text down by 20%. The layout shift score is 0.1, the product of 0.5*0.2. Thus, CLS is 0.1.
75
+
79
76
80
-
### Other Web Vitals
77
+
The Web Vitals histogram displays data distribution, and it can help you identify and diagnose frontend performance problems by revealing anomalies.
81
78
82
-
These Web Vitals are generally less user-visible, but are useful for troubleshooting issues with the Core Web Vitals.
79
+
By default, outliers will be excluded from the histograms to provide a more informative view of these vitals. Outliers are determined using the [upper outer fence](https://en.wikipedia.org/wiki/Outlier#Tukey's_fences) as the upper bound, and any data points above the upper bound are deemed an outlier.
83
80
84
-
#### First Paint (FP)
81
+
The vertical marker for each Web Vital is the 75th percentile of the observed data points. In other words, 25% of the recorded values exceed that amount.
85
82
86
-
First Paint (FP) measures the amount of time the first pixel takes to appear in the viewport, rendering any visual change from what was previously displayed. This may be in any form from the document object model (DOM), such as background color, canvas, or image. FP helps developers understand if anything unexpected is happening to render the page.
83
+
If you notice a region of interest on any of the histograms, click and drag over the area to zoom in for a more detailed view. You may also want to see more information related to the transactions in the histograms. Click "Open in Discover" beneath the Web Vital of choice to build a custom query for further investigation. For more details, see the full documentation for the Discover [Query Builder](/product/discover-queries/query-builder/).
87
84
88
-
#### First Contentful Paint (FCP)
85
+
If you wish to see all of the data available, open the dropdown and click "View All". You will likely see extreme outliers when you click "View All". You can click and drag over an area to zoom in for a more detailed view.
89
86
90
-
[First Contentful Paint (FCP)](https://web.dev/fcp/) measures the time for the first content to render in the viewport. This may be in any form from the document object model (DOM), such as images, SVGs, or text blocks. FCP frequently overlaps with First Paint (FP). FCP helps developers understand how long it takes before the user sees any content change on the page.
91
87
92
-
#### Time To First Byte (TTFB)
88
+
##Browser Support
93
89
94
-
[Time To First Byte (TTFB)](https://web.dev/time-to-first-byte/) measures the time that it takes for a user's browser to receive the first byte of page content. TTFB helps developers understand whether their slowness is caused by the initial response or instead due to render-blocking content.
90
+
| Web Vital | Chrome | Edge | Opera | Firefox | Safari | IE |
0 commit comments