Core Web Vitals

Core Web Vitals are a set of three user-centered metrics defined by Google that quantify how a page feels to real visitors: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. In web performance they serve as a shared vocabulary between developers, product owners and search engines, because each metric has a published threshold that separates a good experience from a poor one.

The set was introduced in 2020 and is reviewed periodically. The most significant change so far came in March 2024, when INP replaced First Input Delay (FID), because FID measured only the delay before the first interaction and missed slow event handling and rendering later in the visit.

The three metrics and their thresholds

Each Core Web Vital has a good, needs improvement and poor band. A page passes the assessment only when all three metrics are good at the 75th percentile of page loads, which means at least three out of four visits must meet the threshold, not just the median one.

The units differ deliberately. LCP and INP are durations in milliseconds, while CLS is a unitless score calculated from the fraction of the viewport that moved multiplied by the distance it moved. Since 2021 CLS uses session windows: shifts are grouped into bursts of at most five seconds, and only the worst burst counts.

How the metrics are measured

Core Web Vitals are fundamentally field metrics, gathered from real users through browser APIs such as PerformanceObserver with the largest-contentful-paint, event and layout-shift entry types. Lab tools can reproduce LCP and CLS, but INP requires real interactions, so lab testing relies on Total Blocking Time as a proxy.

Field and lab results frequently disagree. A lab run uses one device profile and an empty cache, while field data reflects real devices, networks, cache states and user behavior. When the two conflict, field data is the ground truth for the assessment, and lab data is the tool for finding the cause.

Core Web Vitals among other performance metrics

Core Web Vitals are a deliberately small subset of a wider set of web performance metrics. Other metrics such as First Contentful Paint and Time to First Byte remain valuable as diagnostic metrics that explain why a Core Web Vital is slow.

LCP itself can be broken into four sub-parts: time to first byte, resource load delay, resource load duration and element render delay. INP likewise splits into input delay, processing time and presentation delay. These breakdowns turn a single number into an actionable diagnosis.

Improving each metric

Each metric responds to a different set of techniques, and work on one rarely fixes another. The decision table below maps the most frequent root causes to the most effective remedies.

A frequent mistake is to lazy-load the LCP image. Lazy loading delays exactly the element that defines the metric, so the largest above-the-fold image should load eagerly with high priority, while lazy loading is reserved for content below the fold.

Role in search and common misconceptions

Core Web Vitals are part of Google’s page experience signals used in search ranking. Their weight is modest compared with relevance and content quality, so a fast page with weak content will not outrank a strong page simply by passing the thresholds.

• A Lighthouse score of 100 does not guarantee passing, because the assessment uses field data at the 75th percentile.
• Mobile and desktop are assessed separately, and mobile is usually the harder target.
• Pages without enough traffic fall back to origin-level data or have no field data at all.
• Fixes appear slowly in reports because the Chrome UX Report uses a 28-day rolling window.

The metrics also have limits. They measure perceived loading, interaction and stability, not accessibility, content usefulness or conversion. Treating them as a minimum quality bar rather than the whole definition of user experience leads to better priorities.

Explained without jargon

When people visit a website, three things shape whether it feels fast. First, does the main content appear quickly? Second, when they tap a button, does something happen right away? Third, does the page stay still instead of jumping around just as they try to click?

Core Web Vitals turn those three feelings into numbers with clear pass marks. They work like a health check for web pages: the scores are collected from real visitors, and a page counts as healthy only when most of them, not just the lucky ones on fast connections, had a good experience.

A typical use case

An online furniture store sees in its field data that mobile product pages have an LCP of 4.3 seconds and a CLS of 0.31 at the 75th percentile, both in the poor band. A trace shows that the main product photo is set as a CSS background, so the browser finds it only after downloading the style sheet, and a promotional banner pushes the page down when it loads.

The team turns the photo into a regular image element with explicit dimensions, adds fetchpriority="high" and reserves a fixed-height slot for the banner. Four weeks later, once the rolling window has refreshed, the 75th percentile LCP sits at 2.2 seconds and CLS at 0.04. Both metrics now pass, and the store’s analytics show fewer visitors leaving before the product page finishes loading.