Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: how quickly the main content appears, how quickly the page responds when someone taps or clicks, and how much the layout jumps around while it loads. They’re part of how Google evaluates page experience, and more importantly, they describe the difference between a site people use and a site people leave.

If someone has sent you a PageSpeed report full of red numbers and acronyms, this post is for you. I’ll explain what each metric means in plain language, what “good” looks like, how to check your own site, and the fixes that usually matter most.

The three metrics, in plain language

Largest Contentful Paint (LCP): does it load?

LCP measures how long it takes for the biggest visible element on the screen, usually a hero image or a large headline, to appear. It’s the moment a visitor feels the page has arrived. Good is 2.5 seconds or less. Over 4 seconds is rated poor.

Interaction to Next Paint (INP): does it respond?

INP measures how long the page takes to visibly react after someone interacts with it: tapping a menu, pressing a button, typing in a form. It looks across the whole visit, not just the first click. Good is 200 milliseconds or less. Over 500 milliseconds is poor. INP replaced an older metric, First Input Delay, in March 2024, so if you read advice that still talks about FID, it’s out of date.

Cumulative Layout Shift (CLS): does it stay still?

CLS measures how much content unexpectedly moves while the page loads. You’ve felt this: you go to tap a link and an ad or image loads above it, pushing everything down, and you tap the wrong thing. Good is 0.1 or less. Over 0.25 is poor. It’s a score rather than a time, so there’s no unit.

Real visitors, not lab tests

This is the part most people miss. The scores that count come from real Chrome users visiting your site, collected in what Google calls the Chrome User Experience Report (CrUX). A page passes when at least 75 percent of visits meet the “good” threshold for each metric. That’s the 75th percentile, and it means your slowest quarter of visitors still matters.

That’s also why your site can feel fast on your office Wi-Fi and still fail. Your customers might be on an older phone, on a patchy connection in a parking lot, with twenty other tabs open. The field data reflects their experience, not yours.

Lab tests, like the Lighthouse score in the lower half of a PageSpeed report, run a single simulated load on a throttled device. They’re excellent for diagnosing problems and testing fixes, but the big performance score out of 100 isn’t what Google uses. Treat it as a flashlight, not a grade.

How to check your own site

You don’t need special software. Two free tools cover it.

  1. PageSpeed Insights. Paste in a URL. The top section, “Discover what your real users are experiencing,” shows field data for that page or your whole site if there’s enough traffic. The lower section shows lab diagnostics with specific suggestions.
  2. Google Search Console. The Core Web Vitals report groups your URLs into Good, Needs improvement and Poor, separately for mobile and desktop. It’s the best way to see patterns, for example every blog post failing CLS because of the same template.

If your site is small or new, you may see “not enough data.” That’s normal. Use the lab results to spot obvious problems and check again once traffic builds.

What usually fixes LCP

Slow loading is the most common failure I see on small business sites, and it’s usually caused by a handful of things.

  • Oversized images. A 4 MB photo straight from a camera, scaled down with CSS, is still a 4 MB download. Resize images to the size they display at, serve modern formats like WebP or AVIF, and compress them.
  • A hero image that loads late. The main image above the fold should load first, not be lazy-loaded. Lazy loading is great for images further down the page and harmful for the one that defines LCP.
  • Slow hosting. If the server takes a second to respond before anything else can start, every other optimization is fighting uphill. Good hosting with caching and a CDN matters.
  • Render-blocking fonts and scripts. Too many font files, or scripts that must run before the page can show, hold everything up.

What usually fixes INP

Poor responsiveness almost always comes down to too much JavaScript running on the main thread. When the browser is busy executing code, it can’t respond to a tap.

  • Audit third-party scripts. Chat widgets, heatmaps, ad pixels, social embeds and multiple analytics tools each add work. Every one should earn its place.
  • Be wary of heavy page builders. Some visual builders ship a lot of code for every page, whether it’s used or not.
  • Break up long tasks. On custom builds, developers can split heavy work into smaller chunks and defer anything that isn’t needed immediately.

What usually fixes CLS

Layout shift is the easiest to fix once you know the causes.

  • Always reserve space for images and video. Set width and height, or an aspect ratio, so the browser knows how much room to leave before the file arrives.
  • Reserve space for ads, banners and embeds. Cookie banners and promo bars that push content down are frequent offenders. Overlay them or give them a fixed slot.
  • Load web fonts carefully. A fallback font that’s a very different size from your brand font can make text reflow when the real font loads.

How much do Core Web Vitals affect rankings?

Honestly: less than content and relevance. Google has been clear that great content on a slower page can still outrank a fast page with weak content. Core Web Vitals work more like a tiebreaker between pages that are otherwise comparable.

But I think that framing undersells them. The metrics exist because they track things that make people give up. A page that takes too long to show anything, ignores a tap, or jumps under your finger is a page that loses enquiries, regardless of where it ranks. Speed is part of the experience of your brand. It belongs on the same list as your logo and your copy, which is something I think about in every brand identity system I design.

Build it in, don’t bolt it on

Performance is much cheaper to design in than to retrofit. The platform you choose sets a lot of the ceiling, which is one of the reasons I wrote how I choose between Next.js, WordPress, Webflow and Framer. It also belongs alongside the rest of the fundamentals in my technical SEO checklist.

On every site I build, image sizing, font loading, reserved space for media and a short list of scripts are decided before launch, not after the first bad report. You can see some of that work in my portfolio. If your current site is failing its Core Web Vitals and you’re not sure where to start, send me the URL and I’ll tell you what’s causing it and what I’d fix first.