What Are the Core Web Vitals? LCP, INP & CLS Explained (2026)

What are the Core Web Vitals?

Google's Core Web Vitals are three metrics (Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift) that measure the user experience of a website. These metrics are based on real user data collected from Chrome browsers worldwide and focus on 3 field aspects of user experience:

• Loading: how quickly page content loads
• Interactivity: how quickly a browser can respond to a user's input
• Stability: how (un)stable the content is as it loads in the browser

The Core Web Vitals are not static. Google has updated the metrics over time. Most recently, in March 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric. INP measures every interaction on a page, not just the first one. That makes it a far stricter test of responsiveness.

Passing the Core Web Vitals

Each of the Core Web Vitals metrics is assigned a rating of Good, Needs Improvement, or Poor based on thresholds created by Google. To pass the Core Web Vitals at least 75% of your visitors need to have a 'good' LCP, INP and CLS score in the Google CrUX dataset on the URL level. If URL level data is unavailable, Google may fall back to URL group or even origin level data.

Why the 75th Percentile?

Google uses the 75th percentile (p75) of real user data to determine whether a page passes the Core Web Vitals. This means that 75% of page visits must have a "good" experience for the page to pass. The 75th percentile was chosen as a balance: it captures the experience of most users (unlike the median, which ignores the slower half), while not being so strict that a handful of outlier visits on poor networks would cause a failure.

In practice, this means your site needs to perform well for the vast majority of visitors, not just those on fast devices and connections.

The Three Core Web Vitals Metrics

Largest Contentful Paint (LCP): Loading

The Largest Contentful Paint (LCP) metric represents how fast your site is loading.

The LCP element itself is the largest single 'contentful' element that has been painted on the visible part of the screen. Contentful means that not just any element can become an LCP candidate. The element needs to have some meaningful content. The definition this time is rather strict: LCP candidates that are considered are: images, text blocks or videos that are visible in the viewport, relative to when the user first navigated to the page.

The Largest Contentful Paint (LCP) value is the time in milliseconds between requesting the page and when the largest contentful element is displayed on the visible part of the screen (above the fold). A good LCP score is under 2.5 seconds. According to the 2025 Web Almanac, only 62% of mobile pages achieve a good LCP, making it the hardest Core Web Vital to pass.

The Largest Contentful Paint (LCP) is chosen because it focuses on a visitor's user experience. When the LCP occurs, you can assume that a visitor thinks the page is finished (while that may not be the case at all). The LCP was created to answer the question: ' When is the content of a page visible?'.

The most impactful ways to improve LCP include preloading the LCP image with fetchpriority="high" and optimizing image file sizes with modern formats like WebP and AVIF. For a complete guide, see our Largest Contentful Paint optimization guide.

Interaction to Next Paint (INP): Interactivity

The Interaction to Next Paint (INP) represents the interactivity of your site. The metric measures how quickly the browser can update the layout after an interaction with a web page.

INP tracks discrete user interactions: clicks, taps, and key presses. Continuous interactions like scrolling and hovering are not measured by INP. Each qualifying interaction is timed from the moment of input through JavaScript processing to the final visual update on screen.

The Interaction to Next Paint value is the time difference between each user interaction and the final presentation change on the page. The slowest of all the interactions (or the 98th percentile for pages with many interactions) will determine the final Interaction to Next Paint (INP) metric.

The INP is a pure field metric and cannot be measured by lab tools like Lighthouse because it requires real user input. In Lighthouse, the Total Blocking Time metric correlates well with the Interaction to Next Paint. While the INP is usually (a lot) lower than the Total Blocking Time, improving the TBT will also improve the INP. One of the most effective strategies is to defer non-critical JavaScript so it does not block the main thread during user interactions.

Globally, 77% of mobile pages achieve a good INP score (under 200ms), according to the 2025 Web Almanac. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 and proved to be a significantly more demanding metric. For a complete guide, see our Interaction to Next Paint optimization guide.

Cumulative Layout Shift (CLS): Visual Stability

The Cumulative Layout Shift (CLS) represents the visual stability part of the Core Web Vitals. The Cumulative Layout Shift (CLS) measures unexpected movements of elements on the page as content renders or new content is shown on the page.

The CLS value is based on 2 'fractions'. The impact fraction and the distance fraction. When an element is visually 'unstable' it will change its dimensions causing other content to shift. The distance is the number of pixels relative to the viewport. The impact is the size of the affected elements relative to the viewport.

Common causes of CLS include images without explicit width and height attributes, dynamically injected content such as ads or cookie banners, and web fonts that swap in at a different size than the fallback. You can reduce font related CLS by self hosting your fonts with proper font-display settings. Globally, 81% of mobile pages achieve a good CLS score according to the 2025 Web Almanac, making it the best performing Core Web Vital. For a complete guide, see our Cumulative Layout Shift optimization guide.

Why Do the Core Web Vitals Matter?

So why should you care about the Core Web Vitals?

• Improved User Experience. Faster loading, snappier interactions, fewer layout jumps. That is what your visitors actually notice. Sites that pass Core Web Vitals see lower bounce rates and higher conversion rates (source: Google).
• Search Engine Optimization (SEO). Google has made Core Web Vitals a ranking factor. Passing them will not catapult a mediocre page to position one, but when two pages compete for the same keyword, the faster one has the edge.
• Mobile Performance. Most of your traffic is probably mobile. 70% of people use smartphones to research products before purchasing and 62% are more likely to do business with companies that have mobile friendly websites.
• Competitive Advantage. Most of your competitors are not optimizing for Core Web Vitals. That is an opportunity. If two sites rank for the same keyword and yours loads faster and responds quicker, Google has a reason to rank you higher.
• Others. Besides the above advantages, the Core Web Vitals are quite well documented (and that is unique for a known Google ranking factor). If you use Google Ads you will get an improved Ad Score. This means you can buy your ads cheaper. Finally, passing the Core Web Vitals is one of the prerequisites for Google's top Stories box.

Real World Impact: Vodafone Case Study

The business impact of Core Web Vitals is not theoretical. When Vodafone Italy improved their Largest Contentful Paint by 31%, they saw an 8% increase in sales, 15% more leads, and an 11% improvement in their cart to visit rate. Faster pages, more sales (source: web.dev case study).

Field Data vs. Lab Data

Field data and lab data measure different things. Confuse them and you will optimize for the wrong numbers.

Field data (also called Real User Monitoring or RUM data) comes from actual visitors using your site in real conditions. This includes variations in device capability, network speed, geographic location, and browsing behavior. Google's CrUX dataset collects field data from Chrome users who have opted in. The Core Web Vitals are exclusively measured using field data.

Lab data comes from controlled tests run on a simulated device in a fixed environment. Tools like Lighthouse and WebPageTest generate lab data. Lab tests are repeatable and useful for diagnosing specific issues, but they do not reflect the diversity of real user experiences.

Why Field Data Matters for SEO

Google uses field data from the CrUX dataset to evaluate Core Web Vitals for search ranking purposes. A perfect Lighthouse score of 100 does not guarantee passing Core Web Vitals, because Lighthouse tests a single simulated visit. Your real users may be on slower devices, distant networks, or interacting with the page in ways that Lighthouse cannot replicate.

This is why monitoring your Core Web Vitals with a Real User Monitoring solution like CoreDash provides the most accurate picture of your site's performance. RUM data lets you identify issues by device type, geographic region, page template, and individual elements, giving you specific insights that lab tools cannot provide.

Measure the Core Web Vitals

Since the Core Web Vitals focus on 3 field aspects of user experience, they can only be measured by field data. Synthetic or lab tests like Lighthouse may provide insight into why your page is slow but do NOT measure the Core Web Vitals.

Measurement Tools Comparison

CrUX Data

The Core Web Vitals are measured by Google and are recorded in the CrUX dataset. CrUX is the official dataset of the Web Vitals program. There are a few ways to access the dataset:

1. The CrUX Dashboard is a Data Studio dashboard that allows you to query and render CrUX data into an interactive dashboard, as well as exporting PDF reports.
2. CrUX on BigQuery provides a publicly accessible database of all origin level data collected by CrUX. It is possible to query any and all origins for which data is collected, analyze any metric that CrUX supports and filter by all available dimensions. Full metric histograms are stored in the BigQuery tables allowing for visualization of performance distributions, including experimental metrics.
3. The CrUX API provides programmatic access to CrUX data by page or origin, and can be further filtered by form factor, effective connection type and metrics.
4. PageSpeed Insights uses CrUX to present real user performance data alongside performance opportunities powered by Lighthouse.

RUM Data

RUM data is collected from Real User Monitoring. RUM data is the next best thing to the CrUX dataset. The CrUX dataset is highly anonymous and does not lend itself to being analyzed in detail. The CrUX data also has a rolling 28 day collection window. That is why many Core Web Vitals professionals rely on Real User Metrics. Just like the CrUX data, real user data is being used to measure the Core Web Vitals.

A RUM solution like CoreDash provides several advantages over CrUX data alone: real time reporting (instead of a 28 day rolling window), the ability to filter by individual pages, device types, countries, and browsers, and detailed attribution data that identifies which specific elements are causing issues. This makes RUM data essential for diagnosing and fixing Core Web Vitals problems efficiently.

Lighthouse

Lighthouse is a powerful tool. But understand this: Lighthouse does not measure the Core Web Vitals! Lighthouse is a so called lab tool. Lighthouse performs an analysis under specific circumstances. It does not navigate between pages, does not cache resources, does not interact with the website and does not mimic real life circumstances.

Nevertheless, Lighthouse is a great tool and if used properly it will tell you a lot about the Core Web Vitals issues on a page.

The best way to run a Lighthouse analysis is through PageSpeed Insights in your browser or via the Lighthouse command line tool.

What Real World Data Shows

The 2025 Web Almanac provides a broad look at Core Web Vitals performance across the web. Here is how each metric performs globally on mobile:

Note: TTFB and FCP are diagnostic metrics, not Core Web Vitals. They are included here because they heavily influence LCP and overall loading performance. Learn more in our Time to First Byte guide and First Contentful Paint guide.

How to Improve the Core Web Vitals

The Core Web Vitals are an ever changing set of metrics and improving them is not a one off effort. Staying ahead means building performance into your development process: track your field metrics, fix regressions quickly, and ship small improvements with every release.

The 3 Core Web Vitals interact with each other and improving one often has a positive or even negative effect on the others. The guidelines below are a great start to understand and improve each of the individual Core Web Vitals:

• Improve the Largest Contentful Paint
• Improve the Interaction to Next Paint
• Improve the Cumulative Layout Shift

Beyond the three Core Web Vitals themselves, two diagnostic metrics play a critical role in overall performance:

• Optimize the Time to First Byte (TTFB): TTFB is the foundation of loading performance. A slow TTFB makes it nearly impossible to achieve a good LCP. You can start by configuring your CDN properly.
• Optimize the First Contentful Paint (FCP): FCP measures how quickly the first content appears on screen. It serves as an early indicator of perceived loading speed.

For a step by step guide covering all optimization areas, use our Ultimate Core Web Vitals Checklist.

Google Page Experience and Core Web Vitals

The Core Web Vitals are a subset of Google's page experience score. Page experience is a set of signals that measure how users perceive the experience of interacting with a web page beyond its pure information value, both on mobile and desktop devices.

You can find your site's Page Experience data and Core Web Vitals data in the 'Experience' section of your Google Search Console account.