Core Web Vitals explained for business owners

Core Web Vitals sound like something only developers need to care about, and the reports that show them do little to change that impression. In practice they measure three things every buyer notices without knowing the names: waiting for a page, tapping a button that does nothing, and the page jumping just as you go to tap. This guide explains each score in plain English, uses Google's current thresholds, and helps you decide which problems are worth paying to fix.

What are Core Web Vitals?

Google describes Core Web Vitals as a set of metrics that measure real-world user experience for loading, interactivity and visual stability. There are three of them, each with a target Google considers a good experience. They are part of what Google calls page experience, alongside things like whether the site works on a phone and uses a secure connection.

The set has changed once. In 2024 Interaction to Next Paint (INP) replaced First Input Delay (FID) as the measure of responsiveness, because INP looks at every tap and click during a visit rather than only the first. Any guide or report that still talks about FID is out of date.

What do the three scores measure, and what counts as good?

These are Google's published thresholds, from its Web Vitals documentation and the Search Central page on Core Web Vitals.

CLS has no unit; it is a score that combines how much of the screen moved and how far. A page where nothing jumps scores zero.

How are they measured?

This is the part most owners, and some agencies, get wrong. There are two kinds of data:

• Field data comes from real visitors using Chrome, collected anonymously by Google in the Chrome User Experience Report. This is what Search Console's Core Web Vitals report uses, and it reflects the phones, connections and behaviour of your actual audience.
• Lab data comes from a single simulated visit, run by a tool such as Lighthouse or the lab section of PageSpeed Insights. It is useful for finding causes and testing fixes, but it is one visit under test conditions, not your customers.

Google judges each score at the 75th percentile, measured separately for mobile and desktop. In plain terms, a page passes LCP only if at least three in four visits load the main content within 2.5 seconds. A fast connection in your office tells you very little about the slowest quarter of your visitors on mobile data.

The performance score out of 100 that speed-test tools show is not a Core Web Vitals result. A page can score modestly in a lab test and still pass with real visitors, or the reverse. Decide on field data wherever you have it.

Do Core Web Vitals affect your Google rankings?

Yes, but less than many sales pitches suggest. Google says its core ranking systems seek to reward the kind of experience Core Web Vitals measure. Its page experience guidance is equally clear that Google always seeks to show the most relevant content even if the page experience is poor, and that good results in Search Console's Core Web Vitals report do not guarantee top rankings.

So a fast page that does not answer the search will not outrank a slower one that does. Where speed matters most is with your visitors. People who wait for a page, or tap a button that does nothing, leave, and that costs enquiries whether or not it costs rankings. If your site gets visitors but few enquiries, speed is one of the checks in website traffic but no enquiries.

How do you check your own site?

1. Open Google Search Console and go to the Core Web Vitals report under Experience. If you have not set Search Console up yet, the Search Console guide for business owners shows how.
2. Start with the mobile report, since most service searches happen on phones. Pages are grouped into poor, needs improvement and good.
3. Open an issue to see which metric is failing and example pages. Search Console groups pages with a similar experience together, and a group's status is set by its worst metric.
4. Test an example page in PageSpeed Insights. The top section shows field data if your page has enough visits; the lower section runs a lab test and lists what is slowing the page down.
5. After fixing, click Validate fix in Search Console. Google then monitors the pages for 28 days of new visitor data before confirming the issue is resolved.

If the report says there is no data, your site may not have enough Chrome visitors for Google to report on. That is common for small business sites, and it is not a penalty. Use PageSpeed Insights lab tests on your most important pages instead.

What usually causes poor scores?

Slow LCP: the main content takes too long to appear

• A large photo at the top of the page that was never resized or compressed. This is the single most common cause on business websites.
• A video or slideshow as the first thing on screen.
• Slow hosting, or a site that builds every page from scratch on each visit.
• Fonts, scripts and styles that must load before anything can be shown.

Poor INP: the page is slow to respond

• Too much JavaScript, the code that makes pages interactive, especially from page builders and plugins.
• Third-party scripts: chat widgets, review carousels, tracking tags, social feeds and booking embeds, each doing work every time someone taps.

High CLS: the layout jumps

• Images and embeds without reserved space, so text moves down when they arrive.
• Cookie banners, promotional bars and pop-ups that push content rather than sitting over it.
• Web fonts that load late and reflow the text.

Which problems are worth paying to fix?

Fix in this order:

1. Poor scores on the pages that bring enquiries: your homepage, main service pages and any landing page you pay to send traffic to. Landing pages for paid ads explains why speed matters doubly there.
2. Cheap fixes anywhere: compressing images, removing unused plugins and widgets, reserving space for images and banners.
3. Needs improvement scores on key pages, once poor ones are fixed.
4. Structural problems, such as a page builder that loads heavy code on every page. These can mean rebuilding rather than tuning; moving off Wix, Squarespace or WordPress covers when that is worth it.

Be wary of anyone who wants to spend weeks taking passing pages from good to perfect. Past the good thresholds, extra speed is rarely the thing holding your enquiries back. Muhammad Afzal worked as a frontend engineer from 2021 before founding M/AFZAL, including work at Nextbridge that made application loads 40% faster through code splitting and lazy loading, and the lesson carries over: measure first, fix the biggest cause, then stop. For where speed fits among the other reasons a site misses out on work, see the guide to getting enquiries from Google.