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
+21-27Lines changed: 21 additions & 27 deletions
Original file line number
Diff line number
Diff line change
@@ -1,32 +1,30 @@
1
1
---
2
2
title: "Web Vitals"
3
3
sidebar_order: 60
4
-
description: "Learn more about Web Vitals in Sentry, and how they give you a better understanding of your application's health."
4
+
description: "Understand the health of your application with Web Vitals by monitoring metrics such as render time, response time, and layout shift."
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 <SandboxLinkscenario="performance"projectSlug="react">performance</SandboxLink> of your application.
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
8
9
-
The in-browser Sentry SDKs collects <SandboxLinkscenario="oneWebVitals"projectSlug="react">Web Vitals</SandboxLink> information (where supported) and adds that information to frontend <SandboxLinkscenario="oneTransaction"projectSlug="react">transactions</SandboxLink>. These vitals are then summarized in several graphs for a quick overview of how each frontend transaction is performing for your users.
10
-
11
-
You can visit the [Web Vitals](#web-vitals-page) page to get an overview of how page loads are performing in your application.
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.
12
10
13
11
14
12
15
13
## Core Web Vitals
16
14
17
-
These <SandboxLinkscenario="oneWebVitals"projectSlug="react">Web Vitals</SandboxLink> 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).
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.
18
16
19
17
### Largest Contentful Paint (LCP)
20
18
21
-
[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.
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.
22
20
23
21
### First Input Delay (FID)
24
22
25
-
[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.
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.
26
24
27
25
### Cumulative Layout Shift (CLS)
28
26
29
-
[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.
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.
30
28
31
29
32
30
@@ -40,23 +38,23 @@ Let’s take a look at the example above which has one unstable element - the bo
40
38
41
39
## Other Web Vitals
42
40
43
-
These Web Vitals are generally less user-visible, but are useful for troubleshooting issues with the Core Web Vitals.
41
+
The below Web Vitals are generally less visible to users, but are useful for troubleshooting issues with the Core Web Vitals.
44
42
45
43
### First Paint (FP)
46
44
47
-
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.
45
+
First Paint (FP) measures the amount of time it takes for the first pixel to appear in the viewport. This may be in any form from the document object model (DOM), including background color, canvas, or image. FP helps developers understand if anything unexpected is happening during page-rendering.
48
46
49
47
### First Contentful Paint (FCP)
50
48
51
-
[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.
49
+
[First Contentful Paint (FCP)](https://web.dev/fcp/) measures the amount of time it takes for the first content to render in the viewport. This may be in any form from the document object model (DOM), including 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.
52
50
53
51
### Time To First Byte (TTFB)
54
52
55
-
[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.
53
+
[Time To First Byte (TTFB)](https://web.dev/time-to-first-byte/) measures the amount of time it takes for a user's browser to receive the first byte of page content. TTFB helps developers understand whether slowness is caused by the initial response or is due to render-blocking content.
56
54
57
55
## Thresholds
58
56
59
-
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.
57
+
Google's "Good", "Needs Improvement", and "Poor" thresholds are used to classify data points as green, yellow, and red for the corresponding Web Vitals. "Needs improvement" is called "Meh" in Sentry.
@@ -75,17 +73,13 @@ Some Web Vitals such as FP, FCP, LCP, and TTFB are measured relative to the star
75
73
76
74
## Web Vitals Page
77
75
78
-
The **Web Vitals** page gives you an overview of your page load performance for the selected project(s). You can use this page as a starting point to investigate poor Web Vitals affecting your web application and drill down to better understand which pages affect your web performance most.
79
-
80
-
Open the **Web Vitals** page by clicking "Web Vitals" in the sidebar, under "Performance".
81
-
82
-
In the top left, the [Performance Score](#performance-score) ring shows the overall performance rating of your application. Each component of the ring represents a single Web Vital and its relative weight and impact on the Performance Score. The area chart on the right shows you a breakdown - by Web Vitals - of your performance score over time. You can find out more about how Performance Score is calculated [here](#performance-score).
76
+
The **Web Vitals** page, nested under the **Performance** page, gives you an overview of your page load performance for the selected project(s). You can use this page as a starting point to investigate poor Web Vitals affecting your web application and drill down to better understand which pages are affecting your web performance the most.
83
77
84
-
Below this, you can see your application's average vital values and the individual scores for each Web Vital. These metrics can help you prioritize which Web Vitals need attention most. Click on a Web Vital to open a more detailed summary of that metric and see which pages have the most [Opportunity](#opportunity) for improvement.
78
+
In the top left, the [Performance Score](#performance-score) ring shows the overall performance rating of your application. Each component of the ring represents a single Web Vital and its relative weight and impact on the Performance Score. The area chart on the right shows you a breakdown - by Web Vitals - of your performance score over time.
85
79
86
-
At the bottom of the **Web Vitals** page, a sortable table shows a list of your application's pages, along with their associated average values for each Web Vital. Each page also has its own individual Performance Score. The [Opportunity](#opportunity) column displays a page score's potential improvement to your application's overall Performance Score if maximized to 100. The search bar above this table allows you to filter for specific pages by route name.
80
+
Below this, you can see your application's average vital values and the individual scores for each Web Vital. These metrics can help you prioritize which Web Vitals need attention most. Click on a Web Vital to open a more detailed summary of that metric and see which pages have the most [opportunity](#opportunity)for improvement.
87
81
88
-
You can click through any of your application's pages from the **Web Vitals**page to get to the [Page Overview](#page-overview) display.
82
+
At the bottom of the **Web Vitals** page, a sortable table shows a list of your application's pages, along with their associated average values for each Web Vital. Each page also has its own individual Performance Score. The Opportunity column displays a page score's potential improvement to your application's overall Performance Score if maximized to 100. The search bar above this table allows you to filter for specific pages by route name.
89
83
90
84
<Note>
91
85
@@ -107,9 +101,9 @@ The **Web Vitals** page only displays data from your application's initial page
107
101
108
102
## Page Overview
109
103
110
-
From the table in **Web Vitals** or a Web Vital Summary panel, click on a page to open its **Page Overview**. Here, you can see summary of that single page's Web Vitals. In **Page Overview**, you can further drill down to a specific page load sample [Event](/product/sentry-basics/concepts/tracing/event-detail/), [Replay](/product/session-replay/), or [Profile](/product/profiling/).
104
+
From the table in **Web Vitals** or a Web Vital Summary panel, click on a page to open its **Page Overview** where you'll see a summary of that page's Web Vitals. In the**Page Overview**, you can further drill down to a specific page load sample [Event](/product/sentry-basics/concepts/tracing/event-detail/), [Replay](/product/session-replay/), or [Profile](/product/profiling/).
111
105
112
-
The **Page Overview**page displays a "Page Loads" chart in the right sidebar of the page. A mini **Aggregate Span Waterfall** is also displayed in the right sidebar, which shows you common span paths that your application's page may take. Click the "View Full Waterfall" button or the "Aggregate Spans" tab at the top of the page to see the full **Aggregate Span Waterfall**.
106
+
The **Page Overview** displays a "Page Loads" chart in the right sidebar. A mini **Aggregate Span Waterfall**, which shows you common span paths that your application's page may take, is also displayed here. Click the "View Full Waterfall" button or the "Aggregate Spans" tab at the top of the page to see the full **Aggregate Span Waterfall**.
@@ -141,9 +135,9 @@ At the center of the **Page Overview**, Web Vital average values and scores are
141
135
142
136
## Performance Score
143
137
144
-
**Performance Scores**are a number rating from 0 to 100 that summarizes the percieved performance of your web application. Each page load on your web application that gets sent to Sentry is scored based on its **Web Vitals**. These scores are aggregated to provide a score for each of your pages, and an overall score for your application.
138
+
**Performance Score**is a rating from 0 to 100 that summarizes the perceived performance of your web application. Each page load on your web application that gets sent to Sentry is scored based on its **Web Vitals**. These scores are aggregated to provide a score for each of your pages and an overall score for your application.
145
139
146
-
The **Performance Score** is comprised of 5 individual **Web Vital** components. Each **Web Vital** is given a rating between 0 to 100 through a [Log-Normal Distribution](https://www.desmos.com/calculator/o98tbeyt1t). Each **Web Vital** rating is given a weight, which is summed up to create the overall **Performance Score** with a maximum value of 100. Some browsers may not support all the **Web Vitals** used in Sentry's **Performance Score** calculation, so weights are dynamically adjusted depending on which **Web Vitals** are available on a page load. The default weights, p90, and p50 distribution values of each **Web Vital** can be found in the table below:
140
+
The **Performance Score** is comprised of 5 individual **Web Vital** components. Each **Web Vital** is given a rating from 0 to 100 through a [Log-Normal Distribution](https://www.desmos.com/calculator/o98tbeyt1t). Each **Web Vital** rating is given a weight, which is summed up to create the overall **Performance Score** with a maximum value of 100. Some browsers may not support all the **Web Vitals** used in Sentry's **Performance Score** calculation, so weights are dynamically adjusted depending on which **Web Vitals** are available on a page load. The default weight as well as the p90 and p50 distribution values for each **Web Vital** can be found in the table below.
@@ -155,7 +149,7 @@ The **Performance Score** is comprised of 5 individual **Web Vital** components.
155
149
156
150
## Opportunity
157
151
158
-
**Opportunity** scores are number values associated with each page and are meant to give you a sense of which pages are most valuable to improve. The Opportunity score is the maximum possible increase to your application's overall [Performance Score](#performance-score), if you were to raise a page's individual score to 100. If a page in your application already has a score of 100, the Opportunity score would be 0, since there is no further potential to increase your application's overall [Performance Score](#performance-score) by improving this page.
152
+
**Opportunity** scores are number values associated with each page and are meant to give you a sense of which pages are most valuable to improve. The Opportunity score is the maximum possible increase to your application's overall Performance Score if you were to raise a page's score to 100. If a page in your application already has a score of 100, the Opportunity score would be 0, since there's no way to further optimize this page.
159
153
160
154
Opportunity score calculation is also weighted based on the traffic that a page sees. Pages with high traffic tend to have higher Opportunity scores. For example, a page with a score of 70 that experiences 1000 page loads a day will have a higher Opportunity score than a page with a score of 50 that experiences only 10 page loads a day.
![getsantry[bot]](https://avatars.githubusercontent.com/in/66573?v=4&size=40){kind=avatar}
0 commit comments