Core Web Vitals Explained: How to Read, Diagnose and Fix LCP, INP and CLS

Core Web Vitals are Google's three measurements of real user experience: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when LCP stays within 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, all at the 75th percentile of real visits. They're measured from actual Chrome users, not from your test runs, which is exactly why so many sites think they pass while their visitors know otherwise.

I optimize these numbers for a living, and most Core Web Vitals confusion I meet isn't about code. It's about measurement: which number Google actually grades, why the lab score lies, and where the real data lives. So before the fixes, this guide spends real time on reading the instruments.

What Core Web Vitals Actually Are

Every visit to a page has three moments where the experience can fall apart, and each vital guards one of them:

The definitions live in Google's web.dev documentation, which this guide quotes throughout. The set changed once: INP became a stable Core Web Vital on March 12, 2024, replacing First Input Delay, so any advice you read about "FID" predates the current rules.

The Three Metrics and Their Thresholds

Three details worth having straight:

• LCP has a specific candidate list. Per the LCP definition: images, video posters, CSS background images, and text blocks. In practice it's almost always your hero image or your headline, which is why LCP fixes are so targeted.
• INP watches everything. Not just the first click. Per the INP definition, it measures "the time from the start of the interaction to the moment the next frame is fully presented", for clicks, taps and keypresses through the page's whole life. One janky menu on an otherwise fast page can own your INP.
• CLS is a score, not a time. Each shift is scored as impact fraction times distance fraction (how much of the viewport moved, times how far), then summed per the CLS definition. That's why one full-width banner injection hurts more than ten tiny wiggles.

The 75th Percentile Rule (Why Your Fast Laptop Lies)

Google doesn't grade your average visit. Per web.dev, the assessment uses "the 75th percentile of page loads, segmented across mobile and desktop devices". Translated: line up all real visits from slowest to fastest, walk to the 75% mark, and that visit is your score. A quarter of your visitors experiencing something worse than 2.5 seconds means you fail LCP, even if the median visit is quick.

This single rule explains the most common conversation in performance work: "it's fast on my machine". Of course it is. You're on a warm cache, fiber, and a desktop CPU. The 75th percentile visitor is on a mid-range Android phone, on mobile data, seeing your site for the first time. That's the person Google measures you by, and the person your fixes have to serve.

Field vs Lab: The Two Kinds of Data (and the Score That Doesn't Count)

Every Core Web Vitals tool draws from one of two wells, and confusing them costs real money:

• Field data comes from the Chrome User Experience Report (CrUX): anonymized measurements from real Chrome users, aggregated, per Google's PageSpeed Insights documentation, "over the previous 28-day collection period". This is what Search Console reports and what matters for search.
• Lab data comes from Lighthouse simulating one page load on fixed hardware and network conditions. It's a diagnostic instrument: reproducible, detailed, and blind to what real users experience.

The trap: the big performance score at the top of PageSpeed Insights is lab-only. Google's own documentation is explicit that "having good lab data does not necessarily mean real-user experiences will also be good", and the reverse holds too. I've audited sites agonizing over a lab score of 82 while their field assessment passed comfortably, and sites celebrating a lab 98 while real users on real phones failed INP daily. Read the field section first, always. The lab score is for finding causes, not for judging outcomes.

Do Core Web Vitals Affect Rankings? An Honest Answer

Google's Search Central documentation puts it carefully: good Core Web Vitals align "with what our core ranking systems seek to reward". That's a real signal, and a deliberately modest phrasing. Vitals are not a rocket strapped to your rankings; they're one factor among many, and content relevance outweighs them every day of the week.

So here's the honest hierarchy. If your page isn't indexed, vitals are irrelevant (start with my indexing guide). If your content doesn't answer the query, vitals won't save it. But between comparable pages competing for the same intent, experience signals break ties, and more importantly: slow pages lose visitors before any ranking question arises. A visitor who bounces at second three of a five second load never sees your content, your form, or your phone number. That cost is immediate and shows up in revenue, whatever the algorithm thinks.

Fixing LCP: Make the Main Thing Arrive First

Find your LCP element first (PageSpeed Insights names it in the diagnostics). It's usually the hero image or headline. Then, in descending order of typical impact:

1. Stop lazy-loading the hero. loading="lazy" on the LCP image is the most common self-inflicted LCP wound I see. Lazy-load below the fold, never the top.
2. Tell the browser the hero matters. fetchpriority="high" on the LCP image moves it up the download queue. The featured image on this very page uses it.
3. Shrink what you ship. Serve modern formats and honest dimensions. A 2 MB PNG scaled down by CSS is pure waste; this site's hero images are optimized JPEGs under 60 KB.
4. Fix the server first if TTFB is slow. LCP includes the time before the first byte arrives. Caching, a CDN, or better hosting often beats any front-end trick.
5. Unblock the render path. Defer non-critical JavaScript, keep critical CSS lean, and load fonts with font-display: swap so text doesn't wait on font files.

<!-- above the fold: high priority, never lazy -->
<img src="/hero.jpg" width="1200" height="670" fetchpriority="high" alt="...">

<!-- below the fold: lazy is correct -->
<img src="/chart.jpg" width="640" height="357" loading="lazy" alt="...">

Fixing INP: Give the Main Thread Room to Breathe

INP suffers when the browser's main thread is too busy running JavaScript to draw the next frame after a tap. The fixes are about doing less, later:

1. Audit third-party scripts ruthlessly. Chat widgets, heatmaps, tag managers stuffed with forgotten pixels: each one competes with your visitor's tap. Remove what nobody uses; load the rest after the page is interactive.
2. Break long tasks. Any script chunk running past 50 ms blocks every interaction that arrives during it. Split heavy work and yield to the browser between chunks so input can slip in.
3. Respond first, compute second. On a click, paint the feedback (open the menu, toggle the state), then do the expensive part afterward. The visitor needs to see something happen within 200 ms; the bookkeeping can wait.
4. Watch the DOM size. Rendering cost scales with complexity. Thousand-node pages recalculate slowly, and every interaction pays that tax.

INP is the vital most likely to need a developer rather than a plugin, because the cause is usually architectural: too much JavaScript doing too much work at the wrong time.

Fixing CLS: Reserve the Space Before It's Needed

Layout shift has one root cause: content arriving without space reserved for it. The fixes are mechanical and satisfying:

1. Dimensions on every image and video. width and height attributes let the browser reserve the box before the file arrives. Every image on this site carries them.
2. Reserve slots for ads, embeds and banners. Give the container a fixed size or min-height in CSS, and let the content fill it, not create it.
3. Never inject content above existing content. Cookie notices and promo bars belong at a fixed position or in pre-reserved space, not shoving the page down after load.
4. Tame font swapping. A fallback font swapping to a web font with different proportions shifts every paragraph. Preload the font and pick a similar fallback.

<!-- the box exists before the image loads -->
<img src="/team.jpg" width="800" height="450" alt="...">

/* the ad slot holds its ground even while empty */
.ad-slot { min-height: 280px; }

Which Metric Is Your Problem?

Describe the symptom, get the diagnosis. Runs entirely in your browser.

Where to Check Your Numbers

1. Search Console's Core Web Vitals report is the verdict that matters: field data, grouped into URL groups of similar pages, each group graded by its weakest metric. If you haven't set Search Console up yet, my walkthrough gets you there in an afternoon.
2. PageSpeed Insights gives you both wells in one place: the field assessment up top (when CrUX has data for your URL), lab diagnostics below. Test your money pages individually, not just the homepage.
3. Your own phone, on mobile data, is the cheapest field tool there is. Open your site somewhere with two bars of signal and tap around. The 75th percentile visitor lives closer to that experience than to your office wifi.

The Mistakes I Keep Finding on Audits

1. Chasing the lab 100. Weeks spent squeezing Lighthouse points while the field data already passed. The score that counts is the one from real users; past green, further lab polishing is hobby, not SEO.
2. Testing only on fast hardware. The site is judged at the 75th percentile of real visits, which means mid-range phones on mediocre networks. If you never test there, you're optimizing for an audience Google doesn't measure.
3. Lazy-loading the hero image. A performance plugin set to lazy-load everything, including the one image LCP times. Instant self-sabotage, two-minute fix.
4. Images without dimensions. The page assembles itself like a slow avalanche, and CLS collects the bill. Width and height attributes, everywhere, no exceptions.
5. The third-party graveyard. Five years of marketing tools, three still in use, all still loading. Every forgotten pixel is a tax on INP.
6. Fixing desktop while mobile fails. Assessments are segmented by device. The mobile assessment is usually the failing one, and usually the one with more traffic.
7. Declaring victory the same week. Field data is a 28-day window; the report catches up gradually. Verify with lab tools now, confirm in Search Console next month.

The Core Web Vitals Checklist

Core Web Vitals: FAQ

Milan Georgijevic

Technical SEO Consultant & Developer

I'm a developer who moved into technical SEO. I audit sites, then implement the fixes myself: indexing, Core Web Vitals, structured data, rendering. Performance work is where the developer half earns its keep, because the fix is usually in the code, not in a setting. Request a free technical audit and I'll take a look personally.