Core Web Vitals, explained for the client who asks

Sooner or later a client forwards you a screenshot of a PageSpeed Insights score in the red and asks whether they should be worried. The honest answer is "it depends", which is also the least satisfying answer you can give.

This post is the longer version of that answer: what Core Web Vitals actually measure, where the numbers come from, how much they matter, and how to explain them to someone who runs a business rather than a website.

What Core Web Vitals are

Core Web Vitals are three measurements Google uses to describe how a page feels to use: 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.

The important detail is where the numbers come from. Google's assessment is based on field data: measurements from real Chrome users who visited the page, collected in the Chrome User Experience Report. A page passes a metric when at least 75% of those visits meet the "good" threshold. Mobile and desktop are assessed separately, and mobile is usually the harder one.

That 75th-percentile rule is worth explaining to clients. It means a page that is fast on the office Wi-Fi can still fail, because a quarter of real visitors are on slower phones and weaker connections.

Largest Contentful Paint: when the main content appears

Largest Contentful Paint, or LCP, measures how long it takes for the largest visible element to render. On most pages that is the hero image, a large heading or a featured product photo.

Google's thresholds are:

• Good: 2.5 seconds or less.
• Needs improvement: between 2.5 and 4 seconds.
• Poor: more than 4 seconds.

The usual causes on small-business sites are an oversized hero image, a slow server response and scripts or stylesheets that block rendering. Of those, the image is the most common and the cheapest to fix: serve it at the size it is displayed, in a modern format, and do not lazy-load the image that is meant to appear first. Our issue pages on slow LCP and large images cover the fixes for common platforms.

In plain terms for a client: "When someone opens this page on their phone, it takes about four seconds before they see what the page is about. Many people leave before that."

Interaction to Next Paint: whether the page responds

Interaction to Next Paint, or INP, measures how quickly the page visibly responds after someone interacts with it: tapping a menu, pressing a button, typing in a form. It looks across the interactions during a visit and reports one of the slowest, so a page that is usually responsive but freezes on the booking form will still score badly.

INP replaced First Input Delay as a Core Web Vital in March 2024. If a client's old report mentions FID, that is why the numbers no longer line up.

Google's thresholds are:

• Good: 200 milliseconds or less.
• Needs improvement: between 200 and 500 milliseconds.
• Poor: more than 500 milliseconds.

Poor INP almost always comes down to JavaScript doing too much work on the main thread. On small-business sites the usual suspects are third-party additions: chat widgets, review carousels, tracking tags, cookie banners and page builders that ship far more code than the page uses. See poor INP for where to start.

In plain terms: "When someone taps a button, the page takes a noticeable moment to react. On a booking form, that moment is where people give up or tap twice."

Cumulative Layout Shift: whether the page jumps

Cumulative Layout Shift, or CLS, measures how much visible content moves unexpectedly while the page is in use. It is the reason someone goes to tap "Call now" and hits an advert that loaded above it instead.

Google's thresholds are:

• Good: 0.1 or less.
• Needs improvement: between 0.1 and 0.25.
• Poor: more than 0.25.

CLS is a score rather than a time, which makes it hard to explain. Skip the maths. The causes are concrete: images and embeds without width and height set, banners and cookie notices that push content down after loading, and web fonts that change the size of text when they swap in. The fixes are usually small and often live in one template. There is more detail in poor CLS.

In plain terms: "Parts of the page move while it loads, so people tap the wrong thing."

Why the PageSpeed score and the real-user data disagree

This is the source of most client confusion, so it is worth getting right.

PageSpeed Insights shows two different things on one page. The top section, when a page has enough traffic, is field data from real Chrome users over the previous 28 days. That is what Google uses for the Core Web Vitals assessment. The performance score below it comes from Lighthouse, which loads the page once in a simulated mid-range phone on a throttled connection.

They measure different things in different conditions, so they disagree often. A page can have a mediocre Lighthouse score and pass Core Web Vitals for real users, or the other way round.

Search Console has a Core Web Vitals report too. It groups similar URLs together and shows which groups pass, which is often more useful than testing pages one at a time, because the groups usually map to templates.

How much it matters for rankings

Be careful here, because this is where agencies oversell.

Google includes page experience signals, Core Web Vitals among them, in how it ranks pages. It has also been consistent that relevance and helpful content come first, and that a great page experience does not make up for a page that does not answer the search. Passing Core Web Vitals is not a ranking guarantee, and failing them is rarely the only reason a page does not rank.

Fix Core Web Vitals because slow, jumpy pages lose customers. Treat any ranking benefit as a bonus, not the pitch.

That framing is also easier to defend with a client. Conversion effects of a faster booking page are something they can see in their own numbers. A ranking effect from a CLS fix is usually impossible to isolate.

What to fix first

Start with the pages that bring in visitors and customers, not the homepage by default. Pull the top landing pages from analytics or Search Console, then:

• Check which of those pages fail on mobile in field data.
• Group the failures by template, because a fix to a template fixes every page built on it.
• Fix LCP images first. It is usually the fastest improvement and the easiest to show.
• Audit third-party scripts next. Every widget on the page should earn its place.
• Leave the Lighthouse score chasing for last. Going from 78 to 95 in the lab rarely changes anything a customer notices.

Field data updates over a rolling 28-day window, so warn the client that improvements take a few weeks to show up in the assessment, even when the fix is live on day one.

The one-minute version for the client

If you only have a minute, this is the script:

"Google measures three things about how your pages feel for real visitors on their phones: how fast the main content shows up, how quickly the page reacts when someone taps, and whether things jump around while it loads. Your service pages are slow to show the main image and the booking form is slow to react. We are going to fix the image first, then look at the scripts slowing the form down. You should see it in Google's data within about a month."

Every AuditOpti audit includes Google's field data for the homepage and the top crawled pages. If you want to see where a client site stands, start with a free audit.