Core Web Vitals Explained for Business Owners (LCP, INP, CLS)

Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: how fast the main content appears (LCP), how quickly the page responds when someone taps or clicks (INP), and how stable the layout is while it loads (CLS). To pass, a page needs LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less, measured on real users.

That is the short answer. The longer answer, and the one that matters for your business, is what these numbers mean in practice, where to find your own scores, and which fixes are worth paying for. I will cover all of that in plain English, without assuming you are a developer.

What Core Web Vitals actually measure

Google introduced Core Web Vitals as a small set of user-focused metrics. Instead of asking “how many kilobytes is this page?”, they ask “what did the visitor experience?”. Each one covers a different moment of a visit.

LCP: Largest Contentful Paint (loading)

LCP is the time from when someone opens your page to when the biggest visible element finishes rendering. On most business sites that is the hero image, a banner, or a large block of heading text.

Example: a visitor taps your clinic’s page from Google. The logo and menu appear quickly, but the large photo of your reception with “Book an appointment” over it takes 4 seconds. Your LCP is roughly 4 seconds, and the visitor has spent most of that time looking at an unfinished page.

INP: Interaction to Next Paint (responsiveness)

INP measures how long the page takes to visibly react after a visitor interacts with it: tapping a menu, opening an accordion, pressing “Add to cart” or typing in a form. It looks across the whole visit and reports one of the slowest interactions, so a single sluggish button can drag the score down.

INP replaced the older First Input Delay (FID) metric as a Core Web Vital in March 2024. FID only measured the delay before the browser started handling the first interaction. INP is stricter because it covers every interaction and includes the time until the screen actually updates.

CLS: Cumulative Layout Shift (visual stability)

CLS scores how much content jumps around unexpectedly while the page loads. It is not measured in seconds; it is a unitless score where lower is better.

Example: someone is about to tap your phone number, an ad or cookie banner loads above it, everything shifts down, and they tap “Directions” instead. That frustration is exactly what CLS is designed to capture.

The thresholds: what counts as good, needs improvement and poor

Google groups each metric into three bands. These are the figures published on web.dev’s Web Vitals guide:

Metric	Good	Needs improvement	Poor
LCP (loading)	2.5 s or less	2.5 s to 4 s	Over 4 s
INP (responsiveness)	200 ms or less	200 ms to 500 ms	Over 500 ms
CLS (stability)	0.1 or less	0.1 to 0.25	Over 0.25

One detail people often miss: the score is taken at the 75th percentile of real visits, split by mobile and desktop. In simple terms, at least three out of four visits need a good experience for that metric to be rated good. Your fast office broadband does not count for much if most customers visit on a mid-range phone over mobile data.

Field data vs lab data: why your scores disagree

This is the single biggest source of confusion I see with clients. They run a speed test, get a score of 90, and then Search Console says their pages are “Poor”. Both can be true, because they measure different things.

• Field data comes from real Chrome users visiting your site over the previous 28 days (the Chrome User Experience Report, often called CrUX). This is what Google uses when it assesses Core Web Vitals for Search.
• Lab data is a simulated test run on one device with one network setting, such as Lighthouse or the lower section of PageSpeed Insights. It is excellent for diagnosing problems, but it is a single snapshot.

Lab tests also cannot measure INP properly, because nobody is actually clicking anything. They show a related metric called Total Blocking Time instead. Google explains these differences in detail in why lab and field data can be different.

My rule of thumb: use field data to decide whether you have a problem, and lab data to work out why. If your site is small or new, you may see “not enough data” for field metrics. In that case lab data is all you have, so treat it as a guide rather than a verdict.

Do Core Web Vitals affect Google rankings?

Yes, but probably less than you have been told. Google’s own documentation says its core ranking systems reward content that offers a good page experience, and Core Web Vitals are part of that. It also says clearly that great page experience does not override relevance. A slow page with the best answer can still outrank a fast page with a weak answer.

In my experience, Core Web Vitals tend to matter most in two situations:

1. When competing pages are similar. If you and three local competitors all have decent, relevant service pages, experience can be one of the things that separates you.
2. When the problems are severe. A 9-second mobile LCP or a page that jumps around badly is not a fine-tuning issue. People leave before they read anything, and that hurts you regardless of what any algorithm does.

The conversion side is often the stronger business case. A visitor who waits, mis-taps or gets stuck on a slow form is a lost enquiry, even if your rankings never move. So I treat Core Web Vitals as a lead-generation issue first and a ranking issue second.

How to check your own Core Web Vitals (step by step)

You do not need paid software. These checks take about fifteen minutes.

1. Start with a broad health check. Run your homepage through my free SEO audit tool. It flags speed and mobile issues alongside other problems such as missing titles and indexing blocks, so you see whether performance is actually your biggest issue.
2. Open Google Search Console. Go to Experience > Core Web Vitals. Look at the mobile report first. It groups similar URLs together and shows which metric is failing (for example, “LCP issue: longer than 2.5 s (mobile)”).
3. Test a sample URL in PageSpeed Insights. Pick one URL from each failing group. The top section (“Discover what your real users are experiencing”) is field data; the lower section is the Lighthouse lab test with specific suggestions.
4. Check the important pages, not only the homepage. Your service pages, product pages and contact page are where enquiries happen. They often use different templates and can perform very differently.
5. Write down the failing metric for each template. Fixing one template usually fixes dozens of URLs at once, which is why Search Console groups them.

If you want the bigger picture beyond speed, my guide on how to do an SEO audit of your website walks through the other areas worth checking in the same session.

How to fix each metric

Below are the fixes that, in my experience, solve most problems on small and medium business sites. They are ordered roughly by how often they are the cause.

Fixing a slow LCP

• Compress and resize the hero image. A 3 MB banner photo straight from a camera or stock site is the most common culprit I find. Serve it in WebP or AVIF at the size it is actually displayed.
• Do not lazy-load the main image. Lazy loading is great for images further down the page, but applying it to the hero image delays LCP. The hero should load immediately and can be given a high fetch priority.
• Improve server response time. Cheap shared hosting can take over a second just to start sending the page. Page caching and a CDN help a lot here.
• Avoid sliders and heavy background videos at the top. They usually load late and add a lot of weight for little benefit.

Fixing a poor INP

• Cut unnecessary JavaScript. Chat widgets, multiple tracking tags, pop-up tools and heavy page builders all compete for the browser’s attention. Remove anything that is not earning its place.
• Delay non-essential scripts until after the page has loaded or until the visitor interacts.
• Check your forms and menus. Test them on an actual mid-range Android phone. If tapping the menu takes a noticeable moment to respond, that is your INP problem in action.

Fixing a high CLS

• Give images and videos width and height attributes so the browser reserves space before they load.
• Reserve space for banners, ads and embeds such as maps or review widgets, rather than letting them push content down.
• Watch web fonts. A font that loads late and swaps in can shift text. Preloading the main font or using a closely matching fallback reduces this.

A note for WordPress sites

Most WordPress Core Web Vitals problems come from three places: an overweight theme or page builder, too many plugins loading scripts on every page, and slow hosting. A good caching plugin, an image optimisation plugin and a careful plugin clean-up solve a surprising amount. Test after each change, because some “optimisation” settings (such as aggressive JavaScript delay) can break menus or forms. Speed is one part of a wider set of checks I cover in my technical SEO checklist for business websites.

Common mistakes to avoid

• Chasing a perfect 100 lab score. Google assesses field data against thresholds. Going from “good” to “perfect” rarely changes anything for your business.
• Testing only on desktop. In India especially, most of your visitors are probably on mobile. Look at the mobile report first.
• Expecting instant results in Search Console. Field data covers a rolling 28-day window, so improvements take a few weeks to show up. Use the “Validate fix” button once you have made changes.
• Installing three speed plugins at once. Overlapping caching or minification plugins often conflict and can make things slower or break the layout.
• Ignoring content to focus on speed. A fast page that does not answer the searcher’s question will still struggle. Speed supports good content; it does not replace it.

When to get expert help

Many owners can handle image compression, plugin clean-up and caching on their own. It is worth bringing in help when:

• your pages fail even after the basic fixes above;
• the problem is in the theme or page builder itself, and fixing it means rebuilding templates;
• INP is poor and you cannot tell which script is responsible;
• your site is an online store or booking system where breaking something would cost you sales.

Sometimes the honest answer is that a heavy, ageing theme will never perform well, and a lighter rebuild is cheaper in the long run than endless patching. That is the kind of work I do through my website development services, where performance is planned in from the start rather than bolted on later.

Practical next steps

If you only do three things this week, make it these:

1. Open the Core Web Vitals report in Search Console and note which metric fails on mobile.
2. Fix the obvious causes: oversized hero images, unused plugins and scripts, and images without set dimensions.
3. Re-test in PageSpeed Insights, then use “Validate fix” in Search Console and check back in about four weeks.

Before you start, run your site through the free SEO audit tool linked above to see how performance compares with your other SEO issues. If you would rather have the problems found and fixed for you, you can contact me directly and I will take a look at your site.

Frequently asked questions