Core Web Vitals Explained in Plain English (and How to Fix Them)

Core Web Vitals are three numbers Google uses to judge how a page feels to a real visitor. How quickly the main content shows up. How quickly the page reacts when you tap something. And whether things jump around while it loads. Google collects them from real Chrome users, not from a test in a lab, and uses them as one of its signals in search.

The names sound technical, but the ideas aren't. If you've ever tapped a button on your phone and nothing happened, or gone to tap a link just as an ad pushed it down, you've already met all three.

The three numbers, in plain English

Largest Contentful Paint (LCP): how fast the main content appears

LCP is the time from opening the page to the moment the biggest thing on screen has finished showing. That's usually the hero image, a banner or the main heading. It's the point where a visitor thinks "OK, the page is here".

Interaction to Next Paint (INP): how fast the page reacts

INP watches every tap, click and key press during a visit and measures how long the page takes to show a response. A menu that takes half a second to open, or an "Add to cart" button that seems frozen, means a poor INP. It replaced an older metric called First Input Delay (FID) in March 2024, so if an article still talks about FID, it's out of date.

Cumulative Layout Shift (CLS): whether the page jumps around

CLS scores how much visible content moves unexpectedly while you're looking at it. Text that jumps down when an image or ad loads above it is the classic example. Unlike the other two, it's a score without a unit, and lower is better.

To pass, a page needs all three in the green for at least 75% of visits, checked separately for mobile and desktop. That 75% part matters. Google isn't looking at your fast office Wi-Fi. It's looking at the slower end of your real visitors, on mid-range Android phones and patchy 4G.

Do Core Web Vitals affect Google rankings?

Yes, but less than most people think. Google's ranking systems use them as part of what it calls page experience. Google also says plainly that relevance comes first: a slow page with the best answer will still beat a fast page with a weak one.

So treat them as a tie-breaker and, more importantly, as a sales problem. When two pages are equally useful, the faster one has the edge. But the bigger cost of a slow site isn't a lower ranking. It's the people who give up before it finishes loading.

That hits local businesses hardest. If you've put work into your Google Business Profile, a lot of people will tap through to your website from it, usually on a phone. A slow site loses them at the very last step.

Check your scores in two minutes

1. Open PageSpeed Insights and enter the address of the page you want to check. Start with your home page.

2. Look at the top section, which shows what your real users are experiencing. That's data from real Chrome visitors over the last 28 days, and it's what Google uses. Check the mobile tab first.

3. The section below it, with the performance score out of 100, is a lab test run on Google's servers. It's great for finding problems, but it isn't what Google ranks on. A lab score of 65 with all three real-user numbers in the green is fine.

If your site is new or doesn't get much traffic yet, the top section may say there's no data. Google only shows real-user numbers once enough Chrome users have visited. Until then, use the lab results as a guide. Once traffic builds, the Core Web Vitals report in Google Search Console groups similar pages together and tells you which ones fail and why.

How to fix a slow LCP

On most websites, the biggest thing on screen is an image, so that's where to look first.

• The hero image is far too big. A photo straight from a phone or a stock site can be 3 to 5 MB and 4000 pixels wide, shown in a box a quarter of that size. Resize it, compress it and save it as WebP. When we converted the cover images for this blog, each one went from about 1.3 MB to under 80 KB, with no difference you can see.

• The hero image is lazy-loaded. Lazy loading is great for images further down the page, but on the first image it tells the browser to wait, which is the opposite of what you want. Mark that one image as important instead, with fetchpriority="high".

• The server is slow to respond. If the server takes a second just to start sending the page, everything else waits behind it. Crowded cheap shared hosting, or a server in the US for visitors in India, are the usual reasons. PageSpeed Insights shows this as Time to First Byte (TTFB); under 0.8 seconds is a good target.

• Too much loads before the page can show. Several web fonts, big CSS files from a page builder and scripts in the page head all hold up the first paint. Fewer fonts and fewer plugins help more than any clever trick.

How to fix a slow INP

INP is almost always about JavaScript. Every script on a page competes for the same bit of the browser that responds to taps, and while one is busy, your visitor's tap waits.

• Audit what's actually running. Plenty of sites carry scripts nobody remembers adding: a pixel from an ad campaign that ended last year, two analytics tools doing the same job, a chat widget nobody answers. Remove what you don't use.

• Be careful with plugins and page builders. On WordPress, each plugin can add its own scripts to every page. Ten small plugins can cost more than one big one.

• Keep pages lean. Huge menus, endless carousels and pages with thousands of elements take longer to update after every tap.

If your site is custom-built, your developer can also break long tasks into smaller pieces so the page can respond in between. That's the real fix for heavy apps, but on a typical business site, removing scripts gets you most of the way.

How to fix a high CLS

• Set a width and height on every image and video. The browser then saves the right amount of space before the file arrives, so nothing moves when it does.

• Reserve space for things that load late. Ads, embedded maps, review widgets and "Book now" bars that slide in at the top push everything else down. Give them a fixed slot, or show them as an overlay that doesn't move the page.

• Watch your fonts. When a web font replaces the fallback font and the two are different sizes, every line of text shifts. Use fewer web fonts, load the main one early, and pick a fallback with a similar size.

• Cookie banners at the top of the page that push content down count too. A banner fixed to the bottom of the screen doesn't.

What to fix first

If you only have an afternoon, do these in order:

1. Resize and compress the three or four biggest images on your home page.

2. Remove scripts, apps and plugins you don't use.

3. Add a width and height to every image.

4. Test again. If TTFB is still over a second, look at your hosting.

One honest note: don't chase a perfect 100 in the lab score. It's satisfying, but it's not what Google ranks on, and the last few points take far more effort than they're worth. Get the three real-user numbers green, then spend your time on content and on making the site more useful.

On Wix, Shopify and similar builders, you can't change everything under the hood. Your images and the apps you install are still in your hands, though, and they're usually the biggest wins anyway.