Core Web Vitals Explained: What Actually Matters for SEO

Core Web Vitals are three metrics Google uses to measure what real visitors experience: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). Google's ranking systems use them, but relevance still wins, so treat them as a tiebreaker and a conversion lever rather than a shortcut to page one.

Most advice gets this wrong in one of two directions. It either ignores Core Web Vitals or treats a green PageSpeed score as an SEO goal in itself.

Below I cover what each metric measures, the thresholds that count, why your lab score and field data disagree, and the fixes I reach for first on WordPress and Shopify sites.

You'll also get a simple way to decide whether speed work deserves your budget right now.

Key takeaways

• A page passes when LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less, at the 75th percentile of real visits.
• INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024.
• Only field data decides pass or fail. The PageSpeed Insights performance score is a lab diagnostic.
• Google still ranks the most relevant page even when its experience is weaker, so fix indexing and content problems first.
• Most small-site failures come from a few causes: heavy hero images, too many third-party scripts, and elements that load without reserved space.

What Core Web Vitals measure

Each metric covers one part of how a page feels to use. They're one line in a technical SEO audit checklist, not the whole audit, but they're the line most often misread.

• Largest Contentful Paint (LCP): how long it takes for the largest image or text block in the viewport to render. On most pages that's the hero image, a product photo or the main heading block.
• Interaction to Next Paint (INP): how quickly the page visibly responds when someone clicks, taps or types, measured across the whole visit. It reflects the slow interactions, not the average.
• Cumulative Layout Shift (CLS): how much visible content moves unexpectedly while the page is open. It's the reason you tap the wrong button when a banner loads late.

INP replaced FID in March 2024

INP officially replaced First Input Delay on 12 March 2024. FID only measured the delay before the browser started handling the first interaction.

INP covers the full response: the input delay, the time your code takes to run, and the time to paint the next frame. Because it looks at interactions throughout the visit, it's much harder to pass on a page that's busy running JavaScript. If an old report or plugin still shows FID, ignore it.

The thresholds

Google assesses each metric at the 75th percentile of page loads, split by mobile and desktop. In plain terms, at least three in four visits need a good experience before the page passes.

In Search Console, a URL group takes the status of its slowest metric. One Poor metric fails the group, however good the other two are.

How much do Core Web Vitals affect rankings?

They count, but less than most speed-tool marketing suggests. Google's page experience documentation confirms that Core Web Vitals are used by its ranking systems, and also says there is no single page experience signal.

The more useful line in that documentation is that Google aims to "show the most relevant content, even if the page experience is sub-par." Page experience tends to matter most when several pages are similarly helpful for the same search.

So a fast page that doesn't answer the query won't outrank a slower page that does. Speed helps you win close contests, and it helps the visitors you already have.

How I decide whether to work on them

• If key pages aren't indexed, or the content doesn't match intent, fix that first. No amount of speed work rescues the wrong page.
• If money pages are Poor on mobile, fix them now. Poor scores usually mean real people are waiting or mis-tapping, which costs enquiries and sales as well as rankings.
• If a few templates sit in Needs improvement and the pages you compete with are similar in quality, it's worth closing the gap.
• If everything is Good, stop. Chasing a perfect lab score past the Good thresholds is rarely a good use of budget.

Because slow pages lose sales as well as visibility, I often handle speed alongside conversion rate optimisation rather than as a pure SEO task.

Field data vs lab data: why your scores disagree

This is where most confusion comes from. Field data is what real visitors experienced over time. Lab data is one simulated test run on demand.

Field data comes from CrUX

Field data comes from the Chrome User Experience Report (CrUX), which collects anonymised timings from opted-in Chrome users on desktop and Android. Chrome on iOS and other Chromium browsers such as Edge don't contribute, so iPhone visitors are missing from the numbers.

Pages also need enough traffic to be included. PageSpeed Insights shows field data from the previous 28-day collection period, and falls back to origin-level data for the whole site when a single URL doesn't have enough.

Lab data comes from Lighthouse

The lower half of a PageSpeed Insights report is a Lighthouse test: one page load in a simulated environment with a set device and connection. It's repeatable, which makes it ideal for debugging, but it isn't what Google uses to assess the page.

• The performance score isn't part of the Core Web Vitals assessment. Only the field data at the top of the report decides pass or fail.
• INP can't be measured in a lab, because it depends on when real people choose to interact. Lighthouse shows Total Blocking Time instead, a lab metric that helps you diagnose INP problems but isn't a substitute for it.

My rule is to use field data to decide what to fix and lab data to work out how. If the lab score is red but field data is Good, your real visitors are fine and you have bigger priorities.

How to check your Core Web Vitals, step by step

1. In Search Console, open Experience, then Core Web Vitals. Start with the mobile report, since phones are usually slower and more likely to fail.
2. Open each Poor and Needs improvement issue. Each one lists example URLs from a group of pages with a similar experience, which usually means a shared template.
3. Run one example URL from each failing group through PageSpeed Insights. Read the field data at the top, then the diagnostics below, which name the LCP element and the heaviest scripts.
4. Note which template the URL uses (homepage, product, collection, service, blog post, location page) and log the failing metric against it.
5. If Search Console shows no data, the site probably doesn't have enough Chrome traffic for CrUX yet. Check PageSpeed Insights for origin data, or lab-test your key templates and treat the results as a guide.

Logging by template matters. One fix to a product template can clear hundreds of URLs at once, while fixing pages one at a time rarely moves a group's status.

How to fix LCP

LCP is usually the first metric I look at, because the cause is often a single large image at the top of the page. web.dev breaks LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay, so find which part is slow before changing anything.

1. Find the LCP element in the PageSpeed Insights diagnostics.
2. If it's an image, resize it to the size it's actually displayed at, compress it and serve WebP or AVIF.
3. Don't lazy-load it. Lazy-loading the LCP image always delays it, because the browser waits for layout before requesting it.
4. Mark it as high priority with fetchpriority="high", and use that on one or two images at most.
5. Reduce server response time with decent hosting, page caching and fewer redirects.
6. Move render-blocking scripts out of the head, or defer them, so the page can paint sooner.

Here's what a well-behaved hero image looks like:

<img src="/images/hero-1200.webp"
     width="1200" height="675"
     alt="Grass-fed beef cuts on a timber board"
     fetchpriority="high">

A common mistake is the homepage slider with five full-width images. The first slide becomes the LCP element while the others compete for bandwidth. One strong, well-compressed image almost always loads faster and converts just as well.

How to fix INP

A poor INP means the browser's main thread is busy when someone taps. Each interaction has three phases: input delay (waiting for the thread), processing (your code running) and presentation delay (painting the result).

• Audit third-party scripts. Chat widgets, review widgets, heatmaps, pop-up tools and duplicate analytics tags all compete for the main thread. Remove anything nobody uses.
• Load non-essential scripts later, or only on the pages that need them. A booking widget doesn't need to load on every blog post.
• Break up long tasks so the browser can respond between chunks of work, which developers call yielding to the main thread.
• Keep the DOM lean. Mega menus with hundreds of links and page builders that nest dozens of wrapper elements add rendering work to every interaction.
• Show feedback immediately. Update the button or show a loading state first, then do the heavy work.

For developers, the pattern looks like this:

function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function onAddToCart() {
  showLoadingState();   // visible feedback first
  await yieldToMain();  // let the browser paint
  await updateCart();   // then do the heavy work
}

To find the culprit, record the slow interaction in the Performance panel of Chrome DevTools and look for long blocks of script work right after the click.

How to fix CLS

CLS is usually the easiest metric to fix, because you can see the cause: something loads late and pushes content down.

• Set width and height attributes on every image and video, or reserve space with CSS aspect-ratio.
• Reserve space for embeds, review widgets, ads and iframes with a min-height.
• Don't insert banners above existing content after load. Cookie bars, announcement bars and free-shipping notices should overlay the page or have space reserved.
• Preload key web fonts and choose a fallback font with similar proportions, so text doesn't reflow when the font arrives.
• Animate with transform rather than properties such as top or left, which trigger layout.

.video-embed   { aspect-ratio: 16 / 9; width: 100%; }
.reviews-block { min-height: 320px; }

One helpful detail: layout shifts that happen within 500 milliseconds of a click or tap don't count towards CLS. An accordion opening when someone taps it is fine; it's the unexpected shifts you're chasing.

Platform notes: WordPress and Shopify

Every site has its own challenges, but the same platform habits cause most of the failures I see.

WordPress

• Use page caching, either at the host or through one well-maintained plugin, and serve images through a CDN.
• Avoid stacking page-builder add-ons. Each one tends to load its own CSS and JavaScript on every page.
• Check plugins that load scripts site-wide when they're only needed on one page, such as form and slider plugins.
• Don't solve a heavy theme by adding a speed plugin on top. Remove the cause first.

Shopify

• Apps are usually the weight. Shopify notes that some apps add theme code that isn't removed automatically when you uninstall them, so check your theme after removing one.
• The first product image is often the LCP element on product pages, so size it properly and don't lazy-load it.
• Watch collection templates with large grids, quick-view scripts and multiple review badges per product.

Product templates carry most of the revenue on a store, so I fix speed and product page SEO in the same pass.

How to prioritise and measure your fixes

Validate and give it 28 days

After deploying a fix, click Validate fix on the issue in Search Console. Validation monitors the group over a 28-day window, and field data only changes as new visits come in, so don't judge the result after two days.

Meanwhile, re-run PageSpeed Insights lab tests to confirm the fix behaves as expected, and keep a note of the deploy date so you can match it to the field data later.

Common mistakes

• Optimising for the Lighthouse score instead of field data.
• Testing only the homepage when product, service or blog templates carry the traffic.
• Installing a speed app or plugin on top of the problem instead of removing the cause.
• Lazy-loading every image, including the hero.
• Forgetting that every new app, widget or tracking tag can undo earlier work.

Keep speed in proportion. On a Shopify store, I'd usually put fixing orphan pages and internal links ahead of shaving another few hundred milliseconds off a page that already passes.

The bottom line

Core Web Vitals matter most where they reflect real frustration: slow hero images, laggy taps and jumping layouts on the pages that earn you money.

Get your field data into Good, then stop and put the effort into content, links and indexing.

That's how I treat speed inside my SEO strategy and content management work: one part of a bigger plan. If you're not sure where your site stands, send me your URL and I'll point you to the metric to fix first.

FAQs