Core Web Vitals Explained: LCP, INP, CLS and What to Fix First

Core Web Vitals are three metrics Google uses to measure real-world page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page is “good” when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of real visits on mobile and desktop separately.

Google says Core Web Vitals are used by its ranking systems. It also says relevance comes first. So they matter, but they’re a tiebreaker among good pages, not a shortcut past better content.

This is my hub for the whole topic. I’ll explain how the three metrics work, where to read them, how much weight they really carry, and then send you to the right deep-dive based on the symptom you actually see.

What Are Core Web Vitals, in Plain Terms?

Think of them as three questions a visitor asks without saying a word. Did the main thing show up fast? When I tapped, did the page react? Did the layout stay still while I was reading?

Each question has one metric and one threshold. Google’s web.dev Core Web Vitals overview lists all three as stable metrics and recommends measuring them at the 75th percentile of page loads, segmented by mobile and desktop.

The “needs improvement” and “poor” bands come from Google’s Search Console Core Web Vitals help page, which uses the same boundaries. I like having all three bands in one place, because “orange” and “red” call for very different levels of urgency.

Why Does the 75th Percentile Matter So Much?

Because it means your slower visitors decide the result. Three out of four visits must hit the target, so a page that flies on your office laptop can still fail on the phones your customers actually carry.

In my experience, this single detail explains most of the confusion I hear from clients. They test on a fast connection, see a quick page, and can’t understand why Google calls it poor. The answer is usually sitting in their mobile audience on mid-range Android phones.

INP Replaced FID: What Changed in March 2024?

On March 12, 2024, Interaction to Next Paint officially replaced First Input Delay as the responsiveness Core Web Vital. Google announced the swap on web.dev and removed FID from Search Console the same day.

The difference is bigger than it sounds. FID only measured the delay before the browser started handling your very first interaction. INP looks at clicks, taps and key presses across the whole visit and reports one of the slowest. A page could pass FID easily and still feel sluggish every time someone opened a menu.

Honestly, if a guide, plugin or agency report still lists FID as a Core Web Vital, I treat everything else in it with suspicion. It’s been out of date since 2024.

Field Data vs Lab Data: Which One Counts?

Field data comes from real Chrome users through the Chrome UX Report (CrUX). Lab data comes from a single simulated load in a tool like Lighthouse. Google’s Core Web Vitals assessment, and the Search Console report, run on field data.

Lab data is still useful. It’s instant, it works on staging sites, and it points at the exact image or script causing trouble. But it can’t measure INP directly, because nobody clicks anything during a lab run. Lighthouse uses Total Blocking Time as a stand-in.

My rule is simple. Field data tells me whether there’s a problem and where. Lab data tells me why.

The PageSpeed score itself is a separate thing again. If you want the full breakdown of why a 95 in Lighthouse and a passing assessment aren’t the same, I wrote it up in page speed vs Core Web Vitals, which owns that comparison. Here I’ll just say that the score is a lab diagnostic, and Google doesn’t rank on it.

Where Can You See Your Core Web Vitals?

You need three tools. Each answers a different question, and I use them in this order.

1. Search Console’s Core Web Vitals report. This is the site-wide view. It groups URLs with a similar experience, splits mobile from desktop, and labels each group Good, Need improvement or Poor. A group takes the status of its slowest metric, so one Poor metric makes the whole group Poor.
2. PageSpeed Insights. This is the single-URL view. The top section shows 28 days of CrUX field data for that URL, or for the whole origin if the URL lacks traffic. Below that sits the lab report with diagnostics.
3. CrUX data directly. For trends over time, Google offers the CrUX API, the CrUX History API and CrUX Vis. The older Looker Studio CrUX Dashboard was retired at the end of November 2025, so CrUX Vis is the place to look now.

On Shopify, the built-in web performance dashboard shows real-user Core Web Vitals inside the admin, which is often the quickest start for store owners.

One catch. If a page or site doesn’t get enough Chrome traffic, it won’t appear in CrUX at all. Search Console omits URL groups without enough data for LCP and CLS, and PageSpeed Insights will show no field data. That’s not a failure. It just means you work from lab data until traffic builds.

The Condition Map: Four Things Decide Your Next Step

Before I touch a single line of code on a client site, I check four things. Each one changes which path you take.

1. Which metric fails. LCP, INP and CLS have almost nothing in common under the hood. One failing metric means one family of fixes.
2. Which device fails. Mobile usually fails first. Desktop-only failures point at desktop-only elements like wide sliders and mega menus.
3. Whether you have field data. No CrUX data means no assessment, and you work from lab numbers.
4. Which platform you’re on. WordPress, Shopify and custom builds each control different layers, so the same symptom has a different owner.

Skip them and you can spend weeks compressing images while a chat widget blocks every tap.

The Main Path: Read the Report, Then Fix One Template

Most sites I audit follow the same route. Open Search Console, go to the Core Web Vitals report, and start with mobile. Sort the issues so Poor sits on top, then pick the URL group with the most pages.

Next, open one sample URL from that group in PageSpeed Insights. Confirm which metric fails in the field section, then scroll to the lab diagnostics to find the culprit. Usually it’s one template, like every product page or every blog post, so one fix repairs hundreds of URLs at once.

If LCP fails, then your main content loads late. Look at server response time, how early the browser discovers the hero image, and how big that image is.

If INP fails, then JavaScript is busy when people tap. Count your third-party scripts before anything else.

If CLS fails, then something moves after rendering starts. Check images without dimensions, late ads and injected banners.

If two or three fail, then start with the worst one. Shared causes are common, and a heavy page builder can drag LCP and INP down together.

After you deploy, retest in the lab to confirm the fix works, then wait. Field data runs on a rolling 28-day window, and Search Console validation runs a 28-day monitoring session.

Branch 1: When LCP Is the Failing Metric

LCP is a chain of four parts: time to first byte, resource load delay, resource load duration and element render delay. Whichever part is biggest decides your fix. A slow server is first in line, because no image trick wins back time your host already lost.

My guide to improving LCP walks through 12 fixes mapped to those four parts, including fetchpriority="high" on the hero image and why you should never lazy-load it.

Images are the other half of the LCP story. Format, size, srcset and compression all live in image optimization for SEO, which also covers the discoverability side most speed guides skip.

Branch 2: When INP Is the Failing Metric

INP splits every slow interaction into three phases: input delay, processing duration and presentation delay. Input delay means the main thread was busy when the user tapped. Processing duration means your event handlers do too much. Presentation delay means the next frame takes too long to draw.

I always start with an inventory of third-party tags. In my experience, removing two or three unused scripts fixes more INP failures than any clever code change. The full process, with attribution code you can drop into a site, is in how to improve INP.

On WordPress, the editor matters here. Builders ship extra JavaScript and DOM on every page, which I compare honestly in Elementor vs block editor SEO. My take there: the block editor is the leaner default for content sites, and Elementor can still work if you build it carefully.

Branch 3: When CLS Is the Failing Metric

CLS is usually the cheapest of the three to fix. Most repairs are a few lines of HTML or CSS: width and height on images and iframes, reserved slots for ads and embeds, no banners pushed in above content, fonts that swap without changing size, and animations built with transform.

The hard part is catching which element moved. My CLS guide starts there, with DevTools steps and a snippet that logs the culprit from real visitors.

Branch 4: When You’re on Shopify

Shopify already handles hosting, the CDN, compression and caching, so a lot of generic speed advice doesn’t apply. What you control is the theme, apps, images, fonts, third-party scripts and Liquid code. App bloat and leftover code from uninstalled apps are the usual suspects.

I cover that store-specific layer in Shopify speed optimization, and link out from it to the metric guides above rather than repeat them. The WordPress equivalent, from hosting and caching to plugins, is my WordPress speed guide.

What If the Assessment Already Says Failed?

That red “Core Web Vitals Assessment: Failed” banner in PageSpeed Insights gets its own walkthrough. It covers the URL vs origin toggle, why mobile fails while desktop passes, the no-data case and how long a fix takes to show. Start with Core Web Vitals assessment failed if that banner is what brought you here.

How Much Do Core Web Vitals Matter for Ranking?

Less than the internet thinks. More than zero.

Google’s page experience documentation states it plainly: “Core Web Vitals are used by our ranking systems.” The same page adds that good results in Search Console or third-party tools don’t guarantee top rankings, and that Google “always seeks to show the most relevant content, even if the page experience is sub-par.”

It also says there is “no single signal” for page experience. Other aspects like HTTPS, mobile display, intrusive interstitials and ad density “don’t directly help your website rank higher,” according to that page, though they make a site more satisfying to use.

So here’s how I explain it to clients. Relevance and helpfulness win the ranking. Where many helpful pages compete for the same query, Google says a great page experience “can contribute to success.” Core Web Vitals help you win close races. They won’t rescue thin content.

Honestly, I think the business case beats the ranking case. A checkout that freezes on every tap loses buyers, whatever Google thinks.

Prioritization Table: Start From the Symptom

This is the table I’d pin above a developer’s desk. Find the symptom you see, then follow the row.

Edge Cases That Change the Plan

• If desktop fails but mobile passes, then look at desktop-only elements: big sliders, autoplay hero videos and mega menus.
• If your code improved but the numbers didn’t, then check your traffic mix. A surge of visitors on slower devices or networks can raise the 75th percentile.
• If a plugin, app or theme update broke things overnight, then roll it back first and investigate after.

Decision Matrix

When Should You Bring In a Specialist?

Some problems sit below the theme layer. A server that can’t cache HTML, a custom JavaScript app with long tasks on every interaction, or a theme that ships render-blocking code site-wide all need someone who can read a performance trace. Another plugin won’t fix those.

If you’d rather hand it off, speed and Core Web Vitals work is part of our technical SEO service. If you just want to know which templates fail and why, ask for a free SEO audit and I’ll point you at the cause.

Frequently Asked Questions

What Are the Three Core Web Vitals?

Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). Good thresholds are 2.5 seconds, 200 milliseconds and 0.1, each measured at the 75th percentile of real visits on mobile and desktop.

Is FID Still a Core Web Vital?

No. INP replaced First Input Delay on March 12, 2024. FID only measured the delay before the first interaction was handled, while INP covers interactions across the whole visit. Search Console dropped FID the day INP took over.

Are Core Web Vitals a Ranking Factor?

Yes, with limits. Google’s page experience documentation says Core Web Vitals are used by its ranking systems, but that good scores don’t guarantee top positions and that the most relevant content can still win with a sub-par page experience.

How Long Do Core Web Vitals Take to Update After a Fix?

About four weeks. PageSpeed Insights field data covers a rolling 28-day window, and Search Console validation runs a 28-day monitoring session. You’ll often see movement within a week or two, but the full result needs the whole window.

Why Does My Site Have No Core Web Vitals Data?

The Chrome UX Report only includes pages and origins with enough real Chrome traffic. Newer or low-traffic sites often fall below that line, so PageSpeed Insights shows no field data and Search Console leaves groups out. Use lab data until traffic grows.

Last updated: October 2026 by Mizanur Rahman