What Are Core Web Vitals? LCP, INP & CLS, Explained

Core Web Vitals are Google's three field-measured user-experience metrics: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page rates good at LCP ≤2.5 s, INP ≤200 ms, and CLS ≤0.1 — assessed at the 75th percentile of real Chrome users, so your slowest cohorts count, and passing in a lab test settles nothing.

What are the three Core Web Vitals?

Google introduced Core Web Vitals in 2020 to compress the sprawling discipline of web performance into three numbers a non-specialist can act on, each answering a question a user would actually ask.

LCP — when can I see it? Largest Contentful Paint clocks the render time of the largest visible element, usually a hero image or headline. It is the honest successor to older load metrics because it measures the content a visitor came for rather than technical milestones no one perceives.

INP — does it respond when I touch it? Interaction to Next Paint measures the latency from an input — tap, click, keypress — to the next visual update, across every interaction in the visit, reporting close to the worst. It replaced First Input Delay in March 2024, which only timed the first interaction's queuing delay and flattered JavaScript-heavy sites badly.

CLS — does it hold still? Cumulative Layout Shift scores how much visible content jumps around during the visit. Every mis-tapped button caused by a late-loading banner is CLS in the wild.

The 75th-percentile rule deserves emphasis because it changes what you optimize. Your median user on fiber passing means nothing if the 75th percentile — older phones, cellular networks, far-from-CDN geographies — fails. Google grades the experience of your slower quartile boundary, which is usually where your incremental customers live too.

Do Core Web Vitals affect rankings?

Yes, and less than the performance industry implies. Google confirms page experience signals, Core Web Vitals included, factor into ranking — and has repeatedly framed them as lightweight: a tiebreaker among comparably relevant results rather than a lever that lifts weak content over strong. Relevance and link authority still dominate the algorithm, a proportionality you can see across the ranking-factor research compiled in our SEO statistics library.

So the ranking case for vitals is real but modest: in competitive queries where the top results are equally relevant, experience signals break ties, and failing badly can cost you those margins. The mistake is stopping the business case there, because rankings are the smaller half of what speed is worth.

There is also a crawling footnote worth knowing: faster pages are cheaper for Google to crawl, so large sites with slow responses can see crawl-budget effects independent of ranking signals. For most marketing sites this is minor; for huge catalogs it compounds.

What is speed worth in revenue?

This is where the numbers get compelling, because the conversion evidence is stronger than the ranking evidence by a wide margin.

Read the first row again: a tenth of a second, 8.4% more retail conversions. Against ecommerce sitewide conversion rates that hover around a 2 to 3% median in published cross-industry studies, speed is one of the few levers that moves every channel's performance simultaneously — paid, organic, email, all of it lands on the same pages. The bounce numbers compound the story upstream: visitors who leave during a slow load never even become conversion-rate math, and they take their consent, their email capture, and all the first-party data they would have generated with them.

Our free Speed & Revenue Calculator applies these published curves to your own traffic and AOV so you can price a performance project in expected revenue, and our Web Performance report collects the full evidence base with the methodology notes attached.

Field data vs lab data: which number counts?

Field data. Every time. The distinction trips up more teams than any other part of this topic.

Field data is collected from real Chrome users as they browse — real devices, real networks, real geographies — and aggregated in the Chrome UX Report (CrUX) over a trailing 28-day window. This is the data Google assesses, at the 75th percentile. Lab data comes from synthetic tools like Lighthouse: one simulated visit, fixed hardware profile, throttled network. It is reproducible and richly diagnostic, and it has no standing in your assessment.

The practical division of labor: judge with field data, debug with lab data. PageSpeed Insights shows both for any URL; Search Console's Core Web Vitals report shows field status across your site grouped by URL pattern, which is where template-level failures announce themselves. When you segment field data in your own analytics, disciplined campaign tagging via UTM parameters lets you see which landing pages and traffic sources bear the slowest experiences — paid social traffic on mid-tier Android devices is a classically ugly cohort that lab tests never surface.

Two lab-versus-field traps recur. Sites pass Lighthouse on a developer's machine and fail CrUX because real users bring slower devices than the simulation. And the 28-day window means fixes take weeks to reflect in your assessment — ship, then wait for the window to roll, and resist re-litigating the fix in the meantime.

What usually breaks each metric, and how do you fix it?

Each vital has a short list of usual suspects that covers most failures we audit.

LCP culprits. Oversized, unoptimized hero images; slow server response; render-blocking CSS and fonts; lazy-loading the hero (a self-inflicted classic — lazy-load below the fold only). Fixes: compress and properly size the largest element, preload it, serve modern formats, cut server response time with caching or a faster stack, and inline critical CSS.

INP culprits. JavaScript, in every flavor: long main-thread tasks, heavy hydration in JS frameworks, and above all third-party tags — chat widgets, heatmaps, and a decade of marketing scripts competing for the main thread. Fixes: break up long tasks, defer noncritical scripts, and audit the tag manager ruthlessly. Moving event collection off the browser via server-side tracking earns its keep twice here: fewer client-side scripts fighting for the main thread, and cleaner data arriving despite blockers.

CLS culprits. Images and embeds without reserved dimensions, late-injected banners and ads, and web fonts swapping mid-read. Fixes: explicit width and height on all media, reserved slots for anything injected, and font-display strategies that swap without reflow.

When the culprits are architectural — server response that no cache can save, hydration cost baked into the framework, template debt accumulated over years — the fix conversation becomes a rebuild conversation, and it helps to know what website development actually costs before scoping one.

How do you keep vitals green for good?

Passing once is a project; staying green is a practice. Three habits separate sites that hold their scores from sites that decay within two quarters.

Set performance budgets. Hard ceilings on script weight, image size, and third-party count per template, enforced in CI so regressions fail the build instead of shipping quietly. Gate the tag manager. Most INP decay arrives one marketing tag at a time; require a performance review before anything new touches the container. Monitor field data continuously. Real-user monitoring catches drift the 28-day CrUX window will confirm a month too late — run a quick check anytime with our free SEO Checker, which reads the hygiene layer alongside vitals signals.

Architecture is the durable answer: modern headless stacks with static generation, edge delivery, and disciplined hydration make good vitals the default rather than a quarterly firefight, which is precisely the ground our headless web development practice builds on. And for the rest of the vocabulary this piece leans on — CVR, first-party data, attribution — our growth marketing glossary collects every definition in the series in one place.