Core Web Vitals Explained: LCP, INP, and CLS in Plain English
Core Web Vitals are Google's three measurements of how a page feels to a real user: how fast the main content shows up (LCP), how quickly the page responds when you tap or click (INP), and how much the layout jumps around while it loads (CLS). Each has a "good" threshold, and passing all three means most of your visitors are getting a smooth experience. That's the whole idea, stripped of jargon.
The thresholds are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Hit all three and you're in the green. This guide explains what each one actually measures with an analogy you'll remember, why the two places you check them often disagree, where to see your numbers for free, and an honest answer to the question everyone actually has: how much does this affect my rankings?
LCP: how long until the page looks ready
Largest Contentful Paint measures the time from when you click a link to when the biggest visible thing (usually a hero image, a headline, or a video poster) has rendered. It's the "has this page loaded yet" feeling.
Think of walking into a restaurant. LCP is how long before someone hands you a menu. You don't care that the kitchen is technically open; you care that you have the main thing in front of you. On a web page, the main thing is that big block of content, and LCP is the wait for it.
Threshold: good is under 2.5 seconds, needs-improvement is 2.5 to 4 seconds, poor is over 4. The usual culprits are a slow server response, a hero image that's too large or loads too late, and render-blocking CSS or JavaScript in the <head>.
INP: how quickly the page answers you
Interaction to Next Paint replaced First Input Delay in 2024, and it's stricter. INP measures the delay between you interacting (tap, click, key press) and the page visibly responding, across the whole time you're on the page, reporting roughly the worst interaction. It's the "why is nothing happening when I tap this" feeling.
The analogy: you press a lift button and wait for the light to come on. If it lights instantly, the building feels responsive. If there's a half-second lag, something feels broken even if the lift is fine. INP is that button-to-light delay for every interaction on your page.
Threshold: good is under 200 milliseconds, needs-improvement is 200 to 500, poor is over 500. INP problems are almost always JavaScript: a long task hogging the main thread so the browser can't respond to your click until it finishes. Heavy third-party scripts, large hydration bundles, and expensive event handlers are the common causes.
CLS: how much the page jumps around
Cumulative Layout Shift measures how much visible content moves unexpectedly while the page loads. It's the "I went to tap the button and an ad pushed it down and I tapped the wrong thing" feeling. It's scored as a ratio, not a time.
The analogy: reading a newspaper where the paragraphs keep shuffling as you read. Even if every word eventually arrives, the experience is maddening because you lose your place. CLS quantifies that shuffle.
Threshold: good is under 0.1, needs-improvement is 0.1 to 0.25, poor is over 0.25. The classic causes are images and ad slots without reserved dimensions (the page reflows when they load), web fonts that swap and change text size, and content injected above what you're already reading.
Field data versus lab data (and why they disagree)
This trips up everyone. You run one tool and CLS is perfect; you run another and it's failing. Both can be right, because they measure different things.
Field data (also called CrUX, the Chrome User Experience Report) is real measurements from real Chrome users who visited your page over the previous 28 days. It reflects actual devices, actual networks, actual behavior. This is what Google uses for ranking, and it's what the Search Console Core Web Vitals report shows.
Lab data is a single simulated load in a controlled environment, which is what Lighthouse and the "Performance" tab of PageSpeed Insights produce on demand. It's reproducible and great for debugging, but it's one synthetic run on one simulated device.
They disagree for good reasons. Lab CLS is often near zero because a synthetic run doesn't scroll, click, or trigger the lazy-loaded ad that shifts layout for real users. Lab INP can't be measured at all in a pure lab run because there's no real interaction; tools estimate it with Total Blocking Time instead. So when field and lab disagree, trust field data for "is this actually a problem for users and rankings," and use lab data to reproduce and fix it. If you optimize purely to the lab score, you can pass Lighthouse and still fail CrUX.
Where to check yours for free
Three free sources, in order of usefulness:
PageSpeed Insights. Enter any URL and it shows both the field data (the CrUX numbers at the top, if your page has enough traffic to have them) and a fresh lab run below. Start here for a single page.
Search Console, Core Web Vitals report. Under "Experience," this groups all your URLs by status (good / needs improvement / poor) using field data, so you see which page templates are failing at scale rather than one URL at a time. This is where you find out that every product page shares one LCP problem.
Chrome DevTools and the web-vitals JavaScript library. For debugging a specific interaction, DevTools' Performance panel shows you the long task causing a bad INP. The web-vitals library lets you log real INP and CLS from your own users if you want your own field data.
The usual fixes, ranked by effort
Not all fixes cost the same. Roughly lowest effort to highest:
- Set explicit
widthandheight(oraspect-ratio) on every image and reserve space for ad slots. This is often a one-line-per-image change and it kills most CLS. - Add
loading="lazy"to below-the-fold images and preload the LCP image so it arrives sooner. - Use
font-display: optionalor preload fonts to stop the text-swap layout shift. - Defer or remove non-critical third-party JavaScript. This is usually the biggest INP win and the biggest political fight, because the scripts are often marketing tags.
- Break up long JavaScript tasks and reduce hydration cost. Highest effort, needed when INP is still bad after clearing third-party scripts.
Fix CLS first because it's cheap, then LCP, then INP, which usually costs the most engineering time.
The honest take on ranking impact
Core Web Vitals are a ranking signal, confirmed by Google as part of the page experience signals. But they are a tie-breaker, not a moonshot. Relevance, content quality, and links dominate. A page that fully answers the query with poor CWV will usually still outrank a fast page that answers it badly.
Where CWV actually earns its keep is twofold. Between two pages of similar relevance and authority, the better experience can win the tie. And independent of ranking, faster pages reduce bounce and lift conversions, which is often worth more than the ranking nudge. So do the cheap fixes because they pay for themselves in user behavior, and don't expect green vitals alone to rescue thin content. Vitals belong on your technical checklist alongside the rest of the on-page SEO checklist, not at the top of it.
Frequently Asked Questions
What are the three Core Web Vitals and their thresholds?
The three are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). "Good" thresholds are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. LCP measures loading speed, INP measures responsiveness to interaction, and CLS measures visual stability.
Why do PageSpeed Insights and Lighthouse show different Core Web Vitals scores?
They measure different things. Field data (CrUX) is real measurements from Chrome users over 28 days and is what Google uses for ranking. Lab data (Lighthouse) is one simulated load for debugging. Lab CLS is often near zero because no real scrolling or clicking happens, and lab INP is estimated from Total Blocking Time. Trust field data for real impact, use lab data to reproduce fixes.
Where can I check my Core Web Vitals for free?
Use PageSpeed Insights for a single URL, which shows both field and lab data. Use the Core Web Vitals report in Google Search Console (under "Experience") to see which page templates fail at scale using field data. For debugging a specific slow interaction, Chrome DevTools' Performance panel shows the JavaScript task causing bad INP.
Do Core Web Vitals actually affect Google rankings?
Yes, but as a tie-breaker rather than a major factor. Google confirms they are part of page experience signals, but relevance, content quality, and links matter far more. Between two similarly relevant pages, better vitals can win the tie. Their bigger practical value is reducing bounce and improving conversions, which is often worth more than the ranking effect.
What is the fastest Core Web Vital to fix?
CLS is usually cheapest. Setting explicit width and height (or aspect-ratio) on images and reserving space for ad slots often eliminates most layout shift with a small change. LCP comes next (optimize and preload the hero image), and INP is typically the most work because it means reducing or deferring JavaScript.