Core Web Vitals explained in plain English (and why a slow website costs you leads)

You've probably felt it yourself. You tap a link, the page is blank for a moment, then text appears, then an image pushes everything down just as you go to tap a button, and you tap an ad instead. You hit back and choose the next result.

Your visitors do exactly the same thing on your website. And most of the time, you'll never know they were there.

Google measures this experience with three numbers called Core Web Vitals. They sound technical, but they describe something very human: does the page show up quickly, does it respond when I tap, and does it stay still while I read? This guide explains each one in plain English, the scores to aim for, how to check yours and what actually fixes them.

What are Core Web Vitals?

Core Web Vitals are three measurements Google uses to judge the real-world experience of a web page: how quickly the main content loads (LCP), how quickly the page responds to taps and clicks (INP), and how much the layout jumps around while loading (CLS).

Google collects this data from real Chrome users visiting your site, so it reflects what your actual visitors experience, on their phones and their internet connections, not just what you see on your fast office Wi-Fi.

The three metrics, explained simply

LCP: Largest Contentful Paint

What it measures: how long it takes for the biggest thing on the screen to appear. Usually that's your main image, hero banner or headline.

How it feels: "Is this page actually loading?"

INP: Interaction to Next Paint

What it measures: how quickly the page visibly responds after someone taps, clicks or types. It looks across all the interactions during a visit and reports one of the slowest.

How it feels: "I tapped the menu. Did anything happen?"

INP replaced an older metric called First Input Delay (FID) in March 2024. INP is stricter, because it looks at every interaction, not just the first one.

CLS: Cumulative Layout Shift

What it measures: how much the content unexpectedly moves around while the page loads.

How it feels: "I was about to tap that and it jumped."

What scores should you aim for?

Google groups each metric into good, needs improvement and poor:

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

To "pass", a page needs a good score at the 75th percentile of visits. In simple terms, at least three out of four visits should have a good experience. That's deliberately demanding, because it includes people on older phones and slower networks.

Do Core Web Vitals affect Google rankings?

Yes, but less than many people think, and that's worth being honest about.

Core Web Vitals are part of Google's page experience signals. Google has been clear that relevant, helpful content matters far more. A fast page with weak content won't outrank a slower page that answers the question much better.

Where speed really counts is when pages are otherwise similar. In competitive searches, a better experience can be the tiebreaker.

But the bigger reason to care isn't rankings at all.

The real cost of a slow website: lost leads

Speed affects what people do on your site. Slow, jumpy pages make people leave, abandon forms and lose trust in your business.

One widely cited study by Deloitte for Google, Milliseconds Make Millions (2020), found that improving mobile site speed by just 0.1 seconds increased retail conversion rates by 8.4%, and travel conversion rates by 10.1%. Your numbers will differ, but the direction is always the same: faster sites convert better.

Think about it from a buyer's side. If your website feels slow and clunky, what does that suggest about how you run the rest of your business?

How to check your Core Web Vitals

You don't need to be a developer to check. Three free tools cover most needs:

1. PageSpeed Insights (pagespeed.web.dev). Paste any URL. The top section, "Discover what your real users are experiencing", shows real-world data if your site has enough traffic. The lower section is a lab test with specific suggestions.
2. Google Search Console. The Core Web Vitals report groups your pages into good, needs improvement and poor, using real visitor data, for both mobile and desktop.
3. Chrome DevTools. For developers, the Performance panel shows exactly what's slow and why.

One thing to remember: the lab score (the big number out of 100) and the real-user data can disagree. Google uses the real-user data. Treat the lab score as a diagnostic tool, not the final grade.

How to fix slow loading (LCP)

LCP problems are the most common, and usually the easiest to improve.

• Compress and resize images. A 4,000 pixel photo straight from a camera has no place on a phone screen. Use modern formats such as WebP or AVIF and serve sizes that match the screen.
• Don't lazy-load the main image. Lazy loading is great for images further down the page, but your hero image should load straight away. You can even tell the browser it's important with a priority hint.
• Use good hosting and a CDN. A content delivery network serves your site from a location close to each visitor. For businesses with customers across India or abroad, this alone can make a big difference.
• Cut render-blocking code. Large CSS and JavaScript files that load before the page can show anything delay everything else.
• Be careful with sliders and video backgrounds. Big hero sliders and autoplay videos are often the single slowest element on the page, and they rarely help conversions.
• Limit custom fonts. Load only the weights you use, and host them yourself if you can.

How to fix slow responses (INP)

INP is usually about JavaScript doing too much work at the wrong time.

• Remove scripts you don't need. Old tracking pixels, unused chat widgets and plugins you tried once all add up. Audit them every few months.
• Delay non-essential scripts. Chat widgets, heatmaps and social embeds can usually load after the page is ready.
• Keep tag managers tidy. Google Tag Manager is useful, but containers often grow into a pile of forgotten tags.
• Watch heavy page builders and themes. Some website builders ship a lot of code for every page, whether you use the features or not.
• Break up long tasks. For developers: split heavy work into smaller chunks so the browser can respond to the user in between.

How to fix jumping layouts (CLS)

CLS is usually caused by things loading without space being reserved for them.

• Set width and height on images and videos, so the browser saves the right amount of space before they load.
• Reserve space for ads, banners and embeds. Cookie banners and promo bars that push content down are a classic cause.
• Avoid inserting content above what the user is reading, unless it's in response to something they did.
• Load fonts sensibly. A font that swaps in late can change text size and shift the layout. Using a fallback font with similar sizing reduces the jump.

Quick wins for common website platforms

• WordPress: use a lightweight theme, keep plugins to a minimum, add a good caching plugin and an image optimisation plugin, and choose quality hosting rather than the cheapest plan.
• Shopify: remove apps you no longer use (they often leave code behind), compress product images and be careful with heavy theme sections.
• Wix and Squarespace: you have less control, so focus on image sizes, fewer animations and fewer third-party embeds.
• Custom or modern frameworks: static generation, image optimisation and code splitting usually get you most of the way.

A simple plan if your scores are poor

1. Check Search Console to see which groups of pages fail and on which metric.
2. Fix the templates, not single pages. If your product template is slow, fixing it once fixes every product page.
3. Start with images and scripts. They cause most problems and are the quickest to fix.
4. Re-test with PageSpeed Insights after each change.
5. Wait for real-user data to update. Search Console uses a rolling 28-day window, so improvements take a few weeks to show.

Frequently asked questions

What is a good PageSpeed Insights score?

A lab score of 90 or more is considered good, but don't obsess over the number. What matters most for Google is passing Core Web Vitals in the real-user data, and what matters most for your business is whether visitors stay and convert.

Why is my website fast on my computer but slow for customers?

You're probably on a fast connection with a powerful device, and the site may be cached in your browser. Many customers browse on mid-range phones and mobile data, which is why Google measures real visitors rather than your experience.

How long do Core Web Vitals take to update after fixing my site?

PageSpeed Insights lab tests update immediately. The real-user data in PageSpeed Insights and Search Console is based on the previous 28 days, so it usually takes three to four weeks to fully reflect your improvements.

Will a faster website get me more leads?

Usually, yes. Faster pages keep more visitors on the site, and more visitors reaching your forms and buttons means more enquiries. Speed works best combined with clear messaging and an easy way to contact you.

Do I need to rebuild my website to fix Core Web Vitals?

Not always. Many sites pass after fixing images, removing unused scripts and improving hosting. A rebuild makes sense when the platform or theme itself is the problem and quick fixes no longer move the scores.

The bottom line

Core Web Vitals are simply Google's way of measuring whether your website respects your visitors' time. Fast to load, quick to respond, steady to read.

You don't need a perfect 100. You need a site that feels effortless on a normal phone, on a normal connection, for the people you want as customers. Get that right and both Google and your leads will follow.