Core Web Vitals, explained for business owners

What Core Web Vitals are

Core Web Vitals are three measurements Google uses to describe what it’s like to load and use a web page, as real visitors experience it (web.dev). Each has a “good” range:

Sources: LCP, INP, and CLS on web.dev.

Scores are judged at the 75th percentile. A page passes a metric when at least 75% of visits fall in the “good” range, so a single slow visit won’t fail it, but a pattern of them will. Mobile and desktop visits are measured separately, and a page can pass on one and fail on the other.

The set of metrics can change. Google says stable Core Web Vitals won’t change more than once a year, and it has swapped one out before: INP replaced an older responsiveness metric called First Input Delay.

Why they matter to your business

To Google

Google recommends good Core Web Vitals “for success with Search” and says they align “with what our core ranking systems seek to reward” (Google Search Central). They’re part of what Google calls page experience, along with serving pages over HTTPS, displaying well on phones, and avoiding intrusive pop-ups (page experience).

Speed doesn’t outrank relevance. Google says there is “no single signal” for page experience, and that “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” A fast page that doesn’t answer the search won’t beat a slower one that does. Where speed helps is when your page and a competitor’s are otherwise a close match.

To your customers

Each metric lines up with something a visitor notices. A slow LCP means staring at a blank or half-drawn screen. A poor INP means tapping “Call now” and seeing nothing happen for a moment. A high CLS means reaching for a button just as an ad loads above it, and tapping the wrong thing.

How each metric works, and what usually breaks it

LCP: the main content shows up

LCP marks the moment the largest image, video poster, or block of text in the visible part of the screen finishes appearing. Often it’s the large photo at the top of the home page.

Google’s guide to improving LCP splits that time into four parts: the server’s first response, the delay before the main image starts downloading, the download itself, and the delay before it’s drawn on screen (Optimize LCP). The guide points to these causes:

• Oversized images. A photo straight from a phone is often far larger than a web page needs, and Google recommends properly sized, compressed images in modern formats such as AVIF or WebP.
• A main image that starts loading late, because it’s added by JavaScript or set as a CSS background. Google’s advice is to put it in the page’s HTML and mark it high priority, and, in its words, “Never lazy-load your LCP image.”
• Scripts that block the page. Google notes “it is almost never necessary to add synchronous scripts” to the top of a page, since everything after them waits.
• Slow server responses and redirects. Each redirect adds a wait, and so does a server far from the visitor, which a content delivery network (CDN) helps with.

INP: the page responds when you use it

INP watches every click, tap, and key press during a visit and reports one of the slowest, measured from the interaction to the moment the screen updates (INP). Scrolling and hovering don’t count.

A poor INP usually means the browser was busy running code when the visitor tried to do something. web.dev calls JavaScript “the primary driver of interactivity” and names long tasks on the browser’s main thread as a source of delay. Improving it means giving the browser less to do: fewer and lighter scripts, with long jobs split into smaller pieces so it can respond in between.

CLS: nothing jumps around

CLS adds up unexpected movement of things already on screen. Shifts within half a second of a tap or click can be excluded, since the visitor caused them (CLS). Google’s guide to improving CLS lists these causes and fixes (Optimize CLS):

• Images and videos without set dimensions. Giving them a width and height lets the browser reserve the space before the file arrives.
• Ads, embeds, and widgets that resize after loading. Reserve their space in advance.
• Web fonts that swap in at a different size from the fallback font and reflow the text. Matching the fallback’s size reduces the jump.
• Banners and notices inserted at the top after the page loads, which push everything below them down.

Lab data and field data

PageSpeed Insights shows two kinds of results, and they answer different questions (web.dev; About PageSpeed Insights).

Field data comes from real Chrome users who visited your site over the previous 28 days, collected in the Chrome UX Report. Google uses it to judge Core Web Vitals. It appears in PageSpeed Insights and in the Core Web Vitals report in Google Search Console.

Lab data comes from one simulated page load by Google’s Lighthouse tool, on a single device with fixed network settings. It produces the 0–100 performance score, where 90 or above counts as good.

Google says lab testing is useful during development, but “it is not a substitute for field measurement.” A lab test can’t measure INP, because nobody is interacting with the page; Lighthouse reports Total Blocking Time as a stand-in.

When a page doesn’t get enough Chrome visits, PageSpeed Insights falls back to data for the whole site. If the site doesn’t have enough either, no real-user data is shown. Low-traffic sites can land here, and then the lab results and a test on your own phone are the best guides you have.

Page experience beyond the three metrics

Google’s page experience guidance includes a short list of questions, and says that if you can answer yes to them, you’re probably on track (page experience):

• Do your pages have good Core Web Vitals?
• Are your pages served securely, over HTTPS?
• Does your content display well on mobile devices?
• Does your content avoid an excessive amount of ads that distract from or interfere with the main content?
• Do your pages avoid intrusive interstitials, like pop-ups that cover the page?
• Can visitors easily tell the main content apart from everything else on the page?

Google adds that the list doesn’t cover every aspect of page experience. Each question still describes something a visitor would notice.

Check your own site

1. Go to pagespeed.web.dev, enter your home page, and start with the mobile results. The top section shows real-user Core Web Vitals when Google has enough data; the section below it is the lab test.
2. Scroll past the score to the diagnostics. PageSpeed Insights lists what’s slowing the page down, such as oversized images or render-blocking scripts, and that list is where to start fixing.
3. Test your main service page and contact page too. The home page is only one of the pages customers land on.
4. If you use Google Search Console, open the Core Web Vitals report. It groups your pages by status and shows which metric is failing.
5. Load your site on your own phone, on cellular rather than Wi-Fi. Watch whether the main content appears quickly, whether anything jumps as it loads, and whether the menu responds the moment you tap.
6. Run each test more than once. Lab results vary with network and hardware conditions, so compare a few runs.

A checklist

• Your key pages pass all three Core Web Vitals on mobile, or you know which one fails and why.
• Images are sized for the screen, compressed, and in a modern format.
• The main image at the top of each page isn’t lazy-loaded and starts loading right away.
• Every image, video, and embed has its space reserved.
• Third-party scripts (chat widgets, trackers, embeds) are limited to the ones you use.
• No scripts block the page from showing.
• Old redirects don’t chain through several hops.
• Custom fonts are limited and don’t cause big text jumps.
• Nothing pops in at the top of the page after it loads.
• You re-check after every significant change to the site.

How we handle it

Every build we do has a performance budget: we target passing Core Web Vitals on mobile and measure before launch. We write the code ourselves rather than layering plugins and page builders, which keeps the amount of code on each page down.

For a site that’s already live, our Website Improvements work covers speed through images, scripts, hosting, and caching, with before-and-after measurements so you can see what changed. The free site check grades your speed on phones in about 30 seconds.