Web Vitals Concepts
Learn more about web vitals and how each metric relates to your application's performance.
This view is only available on Team and Business plans. Team plans can access the last 7 days of data, while Business plans can access the last 90 days. To enable extended data access, upgrade to the Business or Enterprise plan.
Web 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 of your application.
The in-browser Sentry SDKs collect web vitals information (where supported) and adds that information to frontend transactions. These web vitals are then summarized in the Performance > Web Vitals page to give you a quick overview of how each page is performing for your users.
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, these metrics also impact your search ranking.
Largest Contentful Paint (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.
On March 12, 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital. Prior to this, INP was an experimental metric that Sentry did not collect. To begin collecting INP measurements, make sure your Javascript SDK version is 7.104.0 or higher and that the option enableInp is on.
Interaction to Next Paint (INP) measures the time from when a user interacts with a page (through a click, tap, or keyboard input) to when the next paint (rendering of content on the screen) occurs. INP aims to assess how quickly users see a response from the website after taking an action, which is crucial for providing a smooth and responsive user experience.
Cumulative Layout Shift (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.
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.
Layout Shift Score = Impact Fraction * Distance Fraction
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.
These Web Vitals are generally less user-visible, but are useful for troubleshooting issues with the Core Web Vitals.
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.
First Contentful Paint (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.
Time To First Byte (TTFB) 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.
As of March 12, 2024, First Input Delay (FID) was replaced as a Core Web Vital by INP. While Sentry no longer includes FID in our performance score calculations nor on the Web Vitals performance page, we continue to collect FID metrics. You can query FID measurements in Discover.
First Input Delay (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.
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.
| Web Vital | Good | Meh | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | <= 2.5s | <= 4s | > 4s |
| Interaction to Next Paint (INP) | <= 200ms | <= 500ms | > 500ms |
| Cumulative Layout Shift (CLS) | <= 0.1 | <= 0.25 | > 0.25 |
| First Paint (FP) | <= 1s | <= 3s | > 3s |
| First Contentful Paint (FCP) | <= 1s | <= 3s | > 3s |
| Time To First Byte (TTFB) | <= 100ms | <= 200ms | > 600ms |
| First Input Delay (FID) | <= 100ms | <= 300ms | > 300ms |
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.
Not all browsers fully support all web vitals. Sentry uses available web vitals to calculate Performance Score.
| Web Vital | Chrome | Edge | Opera | Firefox | Safari |
|---|---|---|---|---|---|
| Largest Contentful Paint (LCP) | ✓ | ✓ | ✓ | ✓ | |
| Interaction to Next Paint (INP) | ✓ | ✓ | ✓ | ||
| Cumulative Layout Shift (CLS) | ✓ | ✓ | ✓ | ||
| First Paint (FP) | ✓ | ✓ | ✓ | ||
| Time To First Byte (TTFB) | ✓ | ✓ | ✓ | ✓ | ✓ |
| First Contentful Paint (FCP) | ✓ | ✓ | ✓ | ✓ | ✓ |
| First Input Delay (FID) | ✓ | ✓ | ✓ | ✓ |
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").