Core Web Vitals are a set of metrics that measure user experience by evaluating page load time, responsiveness, and visual stability. These three metrics - Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift - are part of Google’s “page experience” ranking factor that was rolled out in June 2021.

Each Core Web Vital metric represents a distinct facet of the user experience, is measurable in the field, and reflects the real-world experience of a critical user-centric outcome.

The current set of Core Web Vitals focuses on three aspects of the user experience — loading, interactivity, and visual stability — and includes the following metrics and their respective thresholds:

To ensure you hit the recommended target for most users, a good threshold to measure is the 75th percentile of page loads for each of the following metrics, segmented across mobile and desktop devices.

The metrics that make up Core Web Vitals will evolve.

Largest Contentful Paint (LCP) measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.

In the following example, LCP happens after FCP (First Contentful Paint), when the "Larry Page" presentation text (in green) appears on the page:

Interaction to Next Paint (INP) measures page responsiveness to user actions. To provide a good user experience, pages should have an INP of less than 200 milliseconds. The following example shows poor and good responsiveness to a user request to expand an accordion element:

Cumulative Layout Shift (CLS) measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1. The example below shows a scenario where the user wants to click “No, go back”, but the page content is pushed to the bottom, and the user inadvertently clicks “Yes, place my order”:
​

Botify integrates only your Core Web Vitals Field Data from the CrUX report, but Core Web Vitals also includes Lab Data. This section explains the difference between the two types of data.

Field data is available in Botify in EngagementAnalytics, as report filters and as report columns. Field data comes from real users visiting your website, also called “Real User Monitoring (RUM)”. Your end goal should be to improve the experience of your end users. While you can always try a few page loads on your laptop and see the results, gathering data from real users is the only way to consider real-life device performance and network conditions.

Botify's source for CWV field data is the CrUX API, which is powered by real user measurement of key user experience metrics across the public web, aggregated from Chrome users who have opted-in to syncing their browsing history, have not set up a sync passphrase, and have usage statistic reporting enabled. CrUX data is important since it is available on the whole web and aggregated by Google. It is the source of truth for better rankings.

CrUX data only comes from a sample of Chrome users, and because Google needs enough traffic on a given page to display reliable insights, it is only available for pages with enough traffic (top-tail and some middle-tail pages, depending on your website traffic).

To go further and gather real-time insights on more pages, you can also complement Google’s measure with your measurement. Here are some options:

Lab data is not available in Botify. Lab measurement is the best way to test the performance of features during development before they are released to users. It is also the best way to catch performance regressions before they happen. Tooling is usually based on Lighthouse or WebPageTest.

Lab data is complementary to field data. In this case study, you can read about how Mercado Libre used both lab and field data to identify opportunities to reduce their First Input Delay Lighthouse score by as much as 90%.

You may not see CWV data for all URLs because Botify only receives CWV metrics for URLs with sufficient data. We cannot exactly define what is "sufficient" since it is determined and not shared by Google, but it is generally at least hundreds of visits a month, depending on the website. On average, for desktop, we estimate approximately 130 clicks per URL per month will give a 50% chance of having Core Web Vitals data.

See also: