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: docs/product/performance/web-vitals/index.mdx
+4-80Lines changed: 4 additions & 80 deletions
Original file line number
Diff line number
Diff line change
@@ -1,75 +1,12 @@
1
1
---
2
2
title: "Web Vitals"
3
3
sidebar_order: 60
4
-
description: "Understand the health of your application with Web Vitals by monitoring metrics such as render time, response time, and layout shift."
4
+
description: "Understand your application's performance score and how each web vital contributes to it. Drill in to explore opportunities to improve your app's overall performance."
5
5
---
6
6
7
-
[Web Vitals](https://web.dev/vitals/) are a set of metrics defined by Google to measure render time, response time, and layout shift. Each data point provides insights about the overall [performance](/product/performance/) of your application.
7
+
Web vitals are a set of metrics that measure the quality of the user experience on a web page. To learn more about these metrics, see [Web Vitals Concepts](/product/performance/web-vitals/web-vitals-concepts/).
8
8
9
-
The in-browser Sentry SDKs collect web vitals information (where supported) and adds that information to frontend [transactions](/product/performance/transaction-summary/). These web vitals are then summarized in several graphs for a quick overview of how each frontend transaction is performing for your users.
10
-
11
-
12
-
13
-
## Core Web Vitals
14
-
15
-
Google considers Core Web Vitals to be the most important metrics for measuring the user experience on web pages. According to a May 2021 [Google blog post](https://developers.google.com/search/blog/2020/11/timing-for-page-experience), these metrics also impact your search ranking.
16
-
17
-
### Largest Contentful Paint (LCP)
18
-
19
-
[Largest Contentful Paint (LCP)](https://web.dev/lcp/) measures how long it takes for the content that covers the largest pixel area in the viewport to render - in other words, how long before a user sees the main content on a page. This content may take any form from the document object model (DOM), such as an image, SVG, or text block.
20
-
21
-
### First Input Delay (FID)
22
-
23
-
[First Input Delay (FID)](https://web.dev/fid/) measures response time when a user tries to interact with the viewport by clicking a button, link, or any other custom JavaScript controller. FID data is critical for understanding whether interactions on an application page are successful or not.
24
-
25
-
### Cumulative Layout Shift (CLS)
26
-
27
-
[Cumulative Layout Shift (CLS)](https://web.dev/cls/) is the sum of individual layout shift scores for every unexpected element shift that happens during the rendering process. An example of this would be trying to click a link on a page that hasn't finished loading and having that link shift down before you've had a chance to click on it due to image rendering issues. The CLS web vital score isn't based on duration. It represents the extent of the disruptive and visually unstable shifts.
28
-
29
-
30
-
31
-
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.
38
-
39
-
## Other Web Vitals
40
-
41
-
These Web Vitals are generally less user-visible, but are useful for troubleshooting issues with the Core Web Vitals.
42
-
43
-
### First Paint (FP)
44
-
45
-
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.
46
-
47
-
### First Contentful Paint (FCP)
48
-
49
-
[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.
50
-
51
-
### Time To First Byte (TTFB)
52
-
53
-
[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.
54
-
55
-
## Thresholds
56
-
57
-
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
-
68
-
<Note>
69
-
70
-
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
-
72
-
</Note>
9
+
In Sentry, web vitals are used to calculate a [Performance Score](#performance-score) for your web application. Using these metrics, we surface the pages that have the most [opportunity](#opportunity) to improve your app's overall performance.
73
10
74
11
## Web Vitals Page
75
12
@@ -147,7 +84,7 @@ The **Performance Score** is comprised of 5 individual **Web Vital** components.
|[Time To First Byte](#time-to-first-byte-ttfb) (TTFB) |[200ms](https://www.desmos.com/calculator/ykzahw9goi)|[400ms](https://www.desmos.com/calculator/ykzahw9goi)| 10% |
149
86
150
-
Performance Scores are currently only supported on desktop web browsers. Find out which Web Vitals are required to calculate Performance Scores in the [Browser Support](#browser-support) table.
87
+
Performance Scores are currently only supported on desktop web browsers. Find out which Web Vitals are required to calculate Performance Scores in the [Browser Support](/product/performance/web-vitals/web-vitals-concepts/#browser-support) table.
151
88
152
89
## Opportunity
153
90
@@ -168,16 +105,3 @@ The vertical marker for each Web Vital is the 75th percentile of the observed da
168
105
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/).
169
106
170
107
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.
171
-
172
-
## Browser Support
173
-
174
-
| Web Vital | Chrome | Edge | Opera | Firefox | Safari | IE |
|[Time To First Byte](#time-to-first-byte-ttfb) (TTFB) | ✓\*| ✓\*| ✓\*| ✓\*| ✓\*| ✓ |
182
-
183
-
\* These Web Vitals are required to calculate [Performance Scores](#performance-score), based on the clients browser. Some browsers may not always send all Web Vitals depending on the web page and/or browser version. Page loads that are missing required Web Vitals are not scored due to low data quality.
description: "Understand the health of your application with Web Vitals by monitoring metrics such as render time, response time, and layout shift."
5
+
---
6
+
7
+
[Web Vitals](https://web.dev/vitals/) are a set of metrics defined by Google to measure render time, response time, and layout shift. Each data point provides insights about the overall [performance](/product/performance/) of your application.
8
+
9
+
The in-browser Sentry SDKs collect web vitals information (where supported) and adds that information to frontend [transactions](/product/performance/transaction-summary/). These web vitals are then summarized in the [**Performance > Web Vitals** page](/product/performance/web-vitals/) to give you a quick overview of how each page is performing for your users.
10
+
11
+
12
+
13
+
## Core Web Vitals
14
+
15
+
Google considers Core Web Vitals to be the most important metrics for measuring the user experience on web pages. According to a May 2021 [Google blog post](https://developers.google.com/search/blog/2020/11/timing-for-page-experience), these metrics also impact your search ranking.
16
+
17
+
### Largest Contentful Paint (LCP)
18
+
19
+
[Largest Contentful Paint (LCP)](https://web.dev/lcp/) measures how long it takes for the content that covers the largest pixel area in the viewport to render - in other words, how long before a user sees the main content on a page. This content may take any form from the document object model (DOM), such as an image, SVG, or text block.
20
+
21
+
### First Input Delay (FID)
22
+
23
+
[First Input Delay (FID)](https://web.dev/fid/) measures response time when a user tries to interact with the viewport by clicking a button, link, or any other custom JavaScript controller. FID data is critical for understanding whether interactions on an application page are successful or not.
24
+
25
+
### Cumulative Layout Shift (CLS)
26
+
27
+
[Cumulative Layout Shift (CLS)](https://web.dev/cls/) is the sum of individual layout shift scores for every unexpected element shift that happens during the rendering process. An example of this would be trying to click a link on a page that hasn't finished loading and having that link shift down before you've had a chance to click on it due to image rendering issues. The CLS web vital score isn't based on duration. It represents the extent of the disruptive and visually unstable shifts.
28
+
29
+
30
+
31
+
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.
38
+
39
+
## Other Web Vitals
40
+
41
+
These Web Vitals are generally less user-visible, but are useful for troubleshooting issues with the Core Web Vitals.
42
+
43
+
### First Paint (FP)
44
+
45
+
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.
46
+
47
+
### First Contentful Paint (FCP)
48
+
49
+
[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.
50
+
51
+
### Time To First Byte (TTFB)
52
+
53
+
[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.
54
+
55
+
## Thresholds
56
+
57
+
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
+
68
+
<Note>
69
+
70
+
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
+
72
+
</Note>
73
+
74
+
75
+
## Browser Support
76
+
77
+
| Web Vital | Chrome | Edge | Opera | Firefox | Safari | IE |
|[Time To First Byte](#time-to-first-byte-ttfb) (TTFB) | ✓\*| ✓\*| ✓\*| ✓\*| ✓\*| ✓ |
85
+
86
+
\* These Web Vitals are required to calculate [Performance Scores](/product/performance/web-vitals#performance-score), based on the clients browser. Some browsers may not always send all Web Vitals depending on the web page and/or browser version. Page loads that are missing required Web Vitals are not scored due to low data quality.
0 commit comments