Overhead view of a laptop showing data visualizations and charts on its screen.

Core Web Vitals Explained for Business Owners

“The developer says we’re failing Core Web Vitals. Should I be worried?” That question usually turns up with a screenshot full of red and amber attached. It depends which vital is failing, on which pages and for whom. Once you know what each of the three numbers is watching, the reports start pointing at fixes.

In brief

  • There are three of them. LCP is loading, INP is how quickly the page reacts to a tap, and CLS is stuff jumping about.
  • They’re judged on real visitors over 28 days, so one quick test proves very little.
  • In Search Console, the worst of the three sets the status for a whole group of pages.
  • Good scores help, though they won’t push your page above more relevant content.

What Core Web Vitals actually measure

Core Web Vitals put numbers on how a page feels to use once someone’s on it. Each of the three has a ‘good’ line to get under.

  • Largest Contentful Paint (LCP) is loading. You want it at 2.5 seconds or less.
  • Interaction to Next Paint (INP) is how fast the page responds when someone taps or clicks. Good means 200 milliseconds or under, which is a fifth of a second.
  • Cumulative Layout Shift (CLS) is visual stability. It’s a score, and 0.1 or less counts as good.

Each also has a ‘poor’ line, with an amber band in between. For LCP that band runs from 2.5 to 4 seconds. INP turns poor once it’s past 500 milliseconds. CLS goes red above 0.25.

Our plain-English guide to website speed and performance introduces all three. This goes a layer further down. The set does change occasionally, with notice, which is how INP took over from First Input Delay in March 2024. Any plugin still banging on about FID is behind the times.

LCP, or how long the main thing takes to show

Picture an online shop’s product page. Someone taps through from Google and stares at a grey box where the product photo should be. That photo is very likely the LCP element, the biggest image, video or block of text in view. LCP is the time from the page starting to load to that thing appearing.

Google splits that time into four chunks, and each one points at a different culprit.

  • Time to First Byte, which is the server answering at all.
  • Resource load delay, the gap before the browser even starts fetching the image.
  • Resource load duration, how long the image itself takes to download.
  • Element render delay, the wait between the image arriving and it actually being drawn.

In a healthy page the two delays are small, each under a tenth of the total, and most of the time goes on the server reply and the download. A big load delay usually means the browser couldn’t spot the image early. Maybe it’s buried in a slider script. Maybe it’s been lazy-loaded, which web.dev bluntly says you should never do to your LCP image. A slow first byte usually points at the server, though redirects add to it too, and that’s where decent business website hosting earns its keep.

INP, or why the button feels sticky

INP is the one people feel without being able to name it. Someone on a physio clinic’s site taps ‘Book now’ and nothing happens. They tap again. Half a second later the booking form finally opens. That lag between the tap and the screen changing is what INP measures.

It keeps an eye on every click, tap and key press through the whole visit and reports one of the slowest. On busy pages with lots of interactions it ignores one of the worst for every 50, so a single random hiccup doesn’t skew things. Scrolling, hovering and zooming don’t count at all.

Every interaction has three parts. There’s the wait before the page can start responding, the time its code takes to run, and the time to draw the result. That first wait grows when the browser’s already busy. If it’s chewing through a chat widget, a review carousel and four tracking scripts, your visitor’s tap just has to queue. Google’s fixes boil down to doing less work when someone interacts, breaking long jobs into smaller pieces and keeping the page itself lean.

CLS, or the page that won’t sit still

You go to tap ‘Donate’ on a charity’s appeal page and an image loads in above it. The button drops. You hit ‘Read our annual report’ instead. That’s a layout shift, and CLS adds them up.

There’s no stopwatch involved. CLS is a score worked out from how much of the screen moved and how far it went. Shifts that happen close together get bundled into bursts, with less than a second between each shift and five seconds at most for the whole burst. CLS reports the worst burst. Movement within half a second of someone tapping, clicking or pressing a key is left out, because people expect a page to change when they’ve just asked it to.

The usual causes are dull and very fixable. Images and videos with no width and height set. Adverts, embeds and widgets that resize themselves after loading. Content dropped in once the page has already appeared, like a promo bar. Web fonts that swap in and change the size of the text. Our piece on user experience priorities for 2026 covers the design habits that keep pages steady.

Where the numbers come from, and why yours might say there’s no data

Google doesn’t judge your Core Web Vitals from one test. It uses the Chrome User Experience Report, or CrUX, which gathers data from real Chrome users on real sites. Search Console and the field data in PageSpeed Insights both draw on it over a rolling 28 days.

The figure that counts is the 75th percentile, worked out separately for mobile and desktop. So three in four page loads need to hit ‘good’. Your office broadband doesn’t get the casting vote. The customer on an old phone with two bars of signal counts just as much.

In Search Console, pages with a similar experience are grouped together and each group takes the status of its worst metric, separately for mobile and desktop. Good LCP and good INP won’t save a group with poor CLS. PageSpeed Insights passes a page when all three are good. If there isn’t enough INP data, LCP and CLS decide it on their own.

CrUX only includes public pages and sites with enough visitors to make a statistically meaningful sample. A specialist manufacturer selling to a few hundred trade buyers might never get there. When a single page is short of data, PageSpeed Insights falls back to figures for the whole site. If the site’s short too, you get no field data whatsoever. That leaves the lab test as your guide. Its score out of 100 is a separate thing from the Core Web Vitals assessment.

Do Core Web Vitals affect your Google rankings?

Yes, but less than the sales emails suggest. Core Web Vitals do feed into Google’s ranking systems, and Google wants site owners to get them to good. Relevance still wins. Google says plainly that it shows the most relevant content “even if the page experience is sub-par”, so a slower page that answers the question better can still come out on top. A row of green in Search Console won’t guarantee a top spot by itself.

Treat them as one part of proper search engine optimisation. We’d argue the bigger payoff is with visitors, and a surprising amount of our list of common website faults worth fixing first overlaps with Core Web Vitals.

What to do with a failing report

  • Open the Core Web Vitals report in Search Console. Note which metric is failing, whether it’s mobile or desktop, and on which group of pages.
  • Start with the pages that bring in money. Service, product, booking and contact pages come before old blog posts. Any page you’re sending paid clicks to belongs near the front, and it’s worth checking your Google Ads match types while you’re at it, so you’re paying for the right visitors in the first place.
  • Run one example from each failing group through PageSpeed Insights and read the diagnostics for that metric.
  • Make the fix, then click ‘Start Tracking’ on the issue in Search Console. Monitoring runs for 28 days, so don’t expect the colour to change by Friday.

Compressing a hero image or reserving space for a banner can be a morning’s work. Sometimes, though, every fix breaks something else because the theme and plugins underneath are fighting each other. If that rings a bell, read these warning signs that a site needs a redesign before spending more on patches.

Getting your vitals into the green

Core Web Vitals are far easier to get right while a site’s being built, with page weight and scripts planned in from day one. That’s how we handle website design and development for businesses of all sizes. Got a report full of red and no idea what it’s telling you? Send it over to Scott and we’ll tell you which bits matter.

Keep reading

Sources