Core Web Vitals Explained, LCP, INP, and CLS

Google uses three numbers to judge whether your page feels fast. They are called Core Web Vitals, and they influence search rankings, ad quality scores, and, most importantly, whether a visitor stays or leaves. Yet most teams misunderstand what these metrics actually measure, optimizing for the wrong layer of the stack and wondering why scores barely move.

What Are Core Web Vitals, Exactly?

Core Web Vitals are a subset of Google’s broader Web Vitals initiative. They single out three dimensions of user experience that Google considers universal: perceived load speed, responsiveness to input, and layout stability. Each dimension is captured by a single metric with a defined “good” threshold, measured on real devices through the Chrome User Experience Report (CrUX).

The three metrics in the current set are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). INP replaced First Input Delay (FID) in March 2024, so if your monitoring dashboards still report FID, you are watching a retired number.

These are field metrics, not lab metrics. That distinction matters. Lighthouse might hand you a score of 95 on your developer’s MacBook while real users on mid-range Android phones over a 4G connection see something quite different. CrUX aggregates data from opted-in Chrome users over a rolling 28-day window, and Google uses the 75th percentile (p75) of each metric for ranking signals. In other words, you need 75 percent of your visits to clear the threshold, not just the median.

Largest Contentful Paint: When the Page Feels Loaded

LCP measures the render time of the largest visible element within the viewport. That is usually a hero image, a headline block, or a background video poster frame. The threshold for “good” is 2.5 seconds or less from when the user first navigates to the page.

Notice the word “visible.” LCP does not care about every resource on the page. It watches the viewport and identifies the single largest image, video, or text block that the user can see without scrolling. Once that element finishes painting, LCP is recorded. If the largest element changes (for instance, a placeholder is replaced by a larger hero image), LCP updates to reflect the later, bigger paint.

Common misconceptions trip teams up here. A fast Time to First Byte (TTFB) does not guarantee a fast LCP. The browser still has to discover the critical resource, download it, and render it. An image behind three redirect hops or loaded via a JavaScript-based lazy loader that fires late will drag LCP well beyond 2.5 seconds even on a server that responds in 200 milliseconds.

LCP is not a server metric or a network metric. It is a rendering metric. You can have a fast server and still fail LCP if the browser does not discover the hero asset early enough in the document.

The practical fixes are straightforward but require discipline. Preload the LCP resource with a <link rel="preload"> tag. Serve images in modern formats (AVIF, then WebP as a fallback). Set explicit width and height attributes. Avoid render-blocking CSS that delays the first paint. If you use a CDN, make sure the origin responds quickly, because edge caching only helps if the cache is warm.

Interaction to Next Paint: Does the Page Respond?

INP replaced FID because FID had a fundamental blind spot. FID measured only the delay of the first interaction. A page could freeze on every subsequent tap and still earn a perfect FID score. INP fixes that by observing every discrete interaction (clicks, taps, key presses) throughout the full page lifecycle and reporting a single value that represents the worst-case latency, with some statistical smoothing applied.

Specifically, INP selects the interaction with the highest latency, ignoring one outlier for every 50 interactions. For most pages with fewer than 50 interactions, that means it reports the single slowest one. The “good” threshold is 200 milliseconds or less.

What does that 200 milliseconds cover? Three phases: input delay (time between the user’s tap and the event handler starting), processing time (how long the event handler itself runs), and presentation delay (time from handler completion to the browser painting the next frame). All three phases are summed into one number.

This is where JavaScript becomes the villain. A long-running task on the main thread delays input processing. Heavy frameworks hydrating components, third-party analytics scripts, consent management platforms firing synchronously: all of these compete for the same single thread in the browser. The user taps a button and nothing happens for 400 milliseconds while the browser finishes executing unrelated code.

Diagnosing INP problems requires different tools than LCP. The Chrome DevTools Performance panel now highlights long interactions. The PerformanceObserver API with type: 'event' entries lets you log interaction latencies in production. Without field data broken down by interaction type, you are guessing.

Cumulative Layout Shift: Stop Moving Things

CLS quantifies how much visible content shifts unexpectedly during the page’s lifetime. The threshold is 0.1 or less. Unlike LCP and INP, CLS is unitless. It is a score derived from two factors for each layout shift: the fraction of the viewport affected and the distance the affected elements moved.

Not every shift counts. Shifts that happen within 500 milliseconds of a user interaction (a tap, a click, a key press) are excluded. The browser assumes you intended to move something in response to input. The shifts that hurt your CLS score are the ones the user did not ask for: an ad slot expanding after load, a web font swapping in and reflowing text, an image without dimensions pushing content down.

CLS also uses a “session window” model. Shifts are grouped into windows of up to five seconds, with no more than one second between consecutive shifts. The score reported is the largest single session window, not the sum of every shift over the whole page lifetime. This change, introduced in 2021, made CLS fairer for long-lived pages like single-page applications where minor shifts might accumulate over minutes of interaction.

The most common CLS offenders are images and iframes without explicit dimensions, dynamically injected content above the fold, and late-loading font files that trigger text reflow. Setting width and height on every <img> and <video> element is the single highest-impact fix for most sites. Using font-display: optional or preloading font files eliminates the flash of unstyled text that causes reflow.

A CLS problem is almost always a sequencing problem. The browser renders content before it has the information needed to size or position it correctly. Fix the sequence and the shifts disappear.

How Google Uses These Numbers in Rankings

Core Web Vitals feed into the “page experience” ranking signal alongside HTTPS, mobile-friendliness, and absence of intrusive interstitials. Google has been explicit that relevance and content quality still dominate. Page experience acts as a tiebreaker when multiple pages are roughly equal in topical authority.

That said, the indirect effects are larger than the direct ranking boost. A page that loads in 1.8 seconds and responds instantly to taps keeps users engaged. Bounce rates drop. Session depth increases. Those engagement signals do feed back into rankings through separate systems. Treating Core Web Vitals as “just an SEO checkbox” misses the compounding benefit of a genuinely fast, stable experience.

Google Search Console surfaces Core Web Vitals data grouped by URL pattern, drawn from CrUX field data. PageSpeed Insights combines CrUX data for a specific URL with a Lighthouse lab audit. Use both. CrUX tells you what real users experience. Lighthouse tells you why.

Measuring in the Field, Not Just the Lab

Lab tools run a synthetic test on a single device profile. Field data reflects the full distribution of hardware, networks, and user behavior. You need both, but field data is the source of truth for ranking purposes.

Real User Monitoring (RUM) libraries like Google’s web-vitals JavaScript library let you capture LCP, INP, and CLS for every session and send the data to your analytics pipeline. Segment by device type, connection speed, geography, and page template. A site might pass Core Web Vitals globally while failing badly on a specific product detail page viewed mostly on low-end devices in a particular market.

Our digital product team routinely finds that aggregate CrUX data masks template-level problems. A fast homepage can pull up the average while category pages with heavy filtering and lazy-loaded product grids drag real user experience down. The fix is always to look at URL groups, not site-wide averages.

The Metrics Will Change. The Principles Will Not.

Google has already swapped FID for INP and adjusted CLS calculation methodology. Future updates are likely. But the underlying principles remain stable: load the most important content quickly, respond to user input without delay, and do not move things the user is trying to interact with. Any engineering work anchored to those principles will survive the next metric revision. Teams that chase individual scores without understanding the mechanisms will be re-optimizing every time Google adjusts the formula.

If you want a deeper look at how we approach these problems for client projects, the pattern is consistent: instrument first, diagnose at the template level, fix the root cause rather than the symptom, and validate with field data after the change ships.

FAQs

What are Core Web Vitals?

Core Web Vitals are three specific metrics Google uses to evaluate user experience on web pages: Largest Contentful Paint (LCP) for loading performance, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. They are measured using real-user field data from the Chrome User Experience Report.

What replaced First Input Delay?

Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. INP measures the latency of all interactions throughout the page lifecycle, not just the first one, giving a more accurate picture of overall responsiveness.

What are the “good” thresholds for Core Web Vitals?

LCP should be 2.5 seconds or less, INP should be 200 milliseconds or less, and CLS should be 0.1 or less. Google evaluates these at the 75th percentile of real-user visits, meaning at least 75 percent of page loads must meet each threshold.

Do Core Web Vitals directly affect search rankings?

Yes, but as one factor among many. Core Web Vitals contribute to Google’s page experience ranking signal. Content relevance and authority still dominate. Page experience acts primarily as a tiebreaker between pages of similar quality and relevance.

What is the difference between lab and field data for Core Web Vitals?

Lab data comes from synthetic tests run on a single simulated device and network profile, using tools like Lighthouse. Field data is collected from real Chrome users over a 28-day rolling window via the Chrome User Experience Report (CrUX). Google uses field data for ranking purposes.