Core Web Vitals Explained (Plain English): The 3 Scores Google Checks and How to Fix Yours

Read this with AI

Read with ChatGPT Read with Claude Ask Gemini

Short answer: Core Web Vitals are three scores for how your page feels to a real visitor: how fast the main content loads (LCP), how quickly it reacts when someone taps (INP), and whether things jump around while loading (CLS). Good is LCP 2.5 seconds or under, INP 200 milliseconds or under, and CLS 0.1 or under.

That is the whole idea. Three numbers, all about the experience a person has when they land on your page. Not code quality, not how clever your site is. Just: did it load fast, did it react when I tapped, and did it hold still while I read it.

The names sound technical. What they measure is not. Let me take them one at a time.

What does each score actually measure?

Picture a bakery homepage with a big photo of a fresh loaf at the top.

LCP (Largest Contentful Paint) is loading. It measures how long the biggest thing on screen, usually that hero photo or a headline, takes to show up. If a visitor stares at a blank space for four seconds waiting for the loaf to appear, that is a bad LCP. Google's own documentation says the largest element should paint "within the first 2.5 seconds" of the page starting to load.

INP (Interaction to Next Paint) is responsiveness. It measures how fast the page reacts when someone taps or clicks. You tap "Add to cart" and nothing happens for half a second, then it finally responds. That lag is INP. Google says it should be "less than 200 milliseconds," which is roughly the blink of an eye.

CLS (Cumulative Layout Shift) is stability. It measures whether the page jumps around while it loads. You go to tap a button, an image or an ad loads in above it, everything slides down, and now your thumb lands on the wrong thing. That jump is CLS. Google wants it "less than 0.1," which basically means "almost none."

Loading, reacting, holding still. If you remember nothing else, remember those three words.

What counts as a "good" score?

Each metric falls into one of three bands: good, needs improvement, or poor.

LCP: good is 2.5 seconds or under. Poor is over 4 seconds.
INP: good is 200 milliseconds or under. Poor is over 500 milliseconds.
CLS: good is 0.1 or under. Poor is over 0.25.

Here is the part people miss. You do not pass by averaging the three or by scoring well on two of them. All three have to be good. One metric stuck in the middle band is enough to fail the whole page. So a page with a lovely fast load and a jumpy layout still fails, because the layout drags it down.

You also do not need a perfect 100. The tools give you a score out of 100, and owners fixate on it. Ignore the round number. What Google cares about is whether each of the three lands in "good."

Why is your score based on real visitors, not a lab test?

Run a speed test once and you get a lab result: how the page performed on that single run, on that machine, at that moment. It is useful for debugging, but it is not the number Google grades you on.

Google uses field data instead. According to web.dev, Google's own developer site, your page is assessed at the 75th percentile of real Chrome visits over a rolling 28-day window. In plain terms: 75 percent of your real visitors, on their real phones and connections, over the last month, have to get a good experience. The slowest quarter is allowed to have a rougher time.

This matters for two reasons. First, a fast test on your office wifi can hide a slow experience for a customer on a phone in a car park. Second, when you fix something, the field score takes weeks to catch up, because it is averaging the last 28 days. Make the fix, then be patient.

How do you check your own scores for free?

Two free tools, no login needed for the first one.

PageSpeed Insights. Go to the page below, type your web address, and press Analyze. It shows your field data (the real-visitor scores that count) at the top and a lab test below it, with each of the three metrics color coded.

Google PageSpeed Insights homepage where a business owner types their site URL to get free Core Web Vitals scores

The Core Web Vitals report in Google Search Console. This is the one to check monthly. Search Console is Google's free dashboard for site owners, and its Core Web Vitals report groups every page on your site into Good, Needs improvement, or Poor, for both mobile and desktop. It tells you not just that you have a problem, but which pages have it and how many. If you have never set this up, our guide to Google Search Console for beginners walks you through it.

Check mobile first. That is where most of your visitors are, and it is where most sites fail.

Fix your LCP: it is almost always your photos

Slow loading has one usual suspect. Big, uncompressed images.

A photographer or a shop owner uploads a hero image straight off the camera at 5,000 pixels wide and several megabytes in size. The browser has to drag that whole file down before it can paint the top of the page. There is your slow LCP.

The fixes, from easiest to hardest:

Compress your images before you upload them. A free tool can shrink a photo by 70 percent with no visible difference.
Resize them to the size they actually display. If the image shows at 1,200 pixels wide, it does not need to be 5,000.
Upgrade slow hosting and turn on caching. If the server itself is slow to respond, even a small image loads late.

The first two an owner can do this afternoon. The third usually means a word with whoever runs your hosting. Photos do a lot of quiet SEO work when they are done right, and our guide to image SEO and alt text covers the rest of it.

Fix your INP: it is almost always your plugins and trackers

Sluggish reactions have their own usual suspect. Too much code running in the background.

Every app, plugin, tracker, chat widget, and analytics tag you add is more work the browser has to do before it can respond to a tap. Install fifteen of them over two years, forget about half, and the page gets slow to react.

The fixes:

Delete plugins and apps you no longer use. Not deactivate. Delete.
Cut duplicate trackers. Owners often have two analytics tags and three pixels doing the same job.
Ask your web person to defer the scripts that can wait, so the page becomes usable before every last widget finishes loading.

Deleting the junk you recognize is an owner job. Deferring the rest is a web-person job. Between the two you clear most INP problems. If your store runs on Shopify, our Shopify SEO tips get into the app-bloat problem specifically.

Fix your CLS: reserve space so nothing jumps

The jumpy layout comes from things that load late and shove everything else out of the way.

The two big causes are images and ads with no reserved space, and fonts that load late and reflow the text. The browser does not know how tall that image will be, so it leaves no gap, then the image arrives and pushes the page down.

The fixes:

Set a width and height on every image, so the browser reserves the exact space before the image arrives.
Reserve slots for ads and embeds, so they drop into a held space instead of pushing content around.
Load fonts in a way that does not reflow the whole page when they swap in.

Most of these live in the theme code, so CLS is the metric most likely to need a web person. The good news is it is often a one-time fix.

When we go through a new owner's site, the pattern is almost always the same. One giant uncompressed photo at the top, and a stack of apps they forgot they had switched on. Compress the photo, delete the dead apps, and the scores usually start climbing before anyone touches a line of theme code. The scary-looking problem is rarely the real one.

Who does what, so you know when to call someone

Split the list in two and it stops feeling like a developer job.

You can do yourself: compress and resize images, delete plugins and apps you do not use, remove duplicate trackers. This is most of the work on most small sites.

Hand to a web person: hosting and caching, deferring scripts, editing theme code to set image dimensions and reserve ad slots. This is the code layer, and it is fine to delegate it.

A real Shopify store owner captured the whole arc in one post: "Need help: How to pass Core Web Vitals and get 90+ mobile score on Shopify?" They had a decent desktop score but a mobile score stuck below 90. The community's practical answer was exactly this fix list, compress and lazy-load images, defer and remove unused scripts and apps, and one merchant reported that a single lazy-loading tweak lifted their mobile score from 40 to 63. Owner-doable changes, real movement.

How much do Core Web Vitals actually matter?

Enough to fix, not enough to panic over.

Google is direct about it. Its documentation says, "We highly recommend site owners achieve good Core Web Vitals for success with Search," and that these scores, along with other page experience aspects, "align with what our core ranking systems seek to reward." So it is a genuine ranking input.

But it is a tiebreaker, not the main event. Good scores will not rescue thin content or a page that does not answer the question. If two pages are otherwise even, the faster, steadier one wins. If one has what the searcher needs and the other does not, speed does not save the loser. Fix your Vitals after your content is solid, not instead of it.

And you are not behind. The 2025 Web Almanac, which measures millions of real sites, found only 48 percent of mobile websites passed all three Core Web Vitals, up from 44 percent the year before. More than half of mobile sites fail. Getting to green does not just avoid a penalty. It puts you ahead of most of your competitors, because most of them have not done it.

While you are tidying up performance, it is worth checking that your pages fit a phone screen properly too, which is a separate thing from speed. Our guide to checking if your website is mobile friendly covers that side, and the bigger picture on site speed and SEO ties it all together.

Frequently asked questions

What replaced First Input Delay?

INP, Interaction to Next Paint, replaced First Input Delay (FID). According to web.dev, INP officially became a Core Web Vital on March 12, 2024. It replaced FID because it measures responsiveness across every tap and click a visitor makes, not just the first one, which is a truer picture of how the page feels to use.

Do I need a perfect 100 score to pass?

No. The score out of 100 is not what Google grades. What matters is that all three metrics land in the "good" band: LCP 2.5 seconds or under, INP 200 milliseconds or under, and CLS 0.1 or under. You can pass comfortably without a perfect round number.

Why did my score not change after I fixed the problem?

Because the score that counts uses field data, real visitor experiences averaged over a rolling 28-day window. When you make a fix, it takes weeks for that window to fill with the improved experience. The lab test in PageSpeed Insights updates instantly, so use that to confirm the fix worked, then wait for the field score to catch up.

Which metric is hardest for small business sites?

For most small sites, LCP is the common failure and the easiest to fix, because it usually comes down to oversized images. CLS is the one most likely to need a web person, since reserving space for images and ads often lives in the theme code. Check both, but start with your photos.

Core Web Vitals come down to three plain questions about your page: did it load, did it react, did it hold still. Compress your photos, delete the apps you forgot about, and let a web person tidy the code layer, and most small sites move from red to green without a rebuild. That is the kind of quiet, ongoing upkeep Fonzy is built to keep an eye on, so the score stays green while you get back to running the business.

Sources

Roald

Founder Fonzy. Obsessed with scaling organic traffic. Writing about the intersection of SEO, AI, and product growth.