Core Web Vitals: The Performance Basics That Matter

Most small business sites I audit fail at least one Core Web Vitals metric, and almost none of those failures need a rebuild. The site loads, the pages work, and nobody has ever looked at the numbers Google collects from real visits.

This is the version I would give you across a table: the three thresholds Google publishes, the difference between a field reading and a lab score, the four fixes that clear most failures, and an honest list of what Core Web Vitals will not fix.

What Core Web Vitals actually measure

Core Web Vitals are three measurements Google takes from real visits to your pages. They are not a single speed score, and they are not the same thing as the score in a testing tool.

The three metrics: LCP, INP and CLS

Largest Contentful Paint measures how long the main content takes to appear. Interaction to Next Paint measures how quickly the page responds when someone taps, clicks or types. Cumulative Layout Shift measures how much the layout moves around while the page loads.

The thresholds are published, not secret. web.dev, which is Google's own guidance, states: "To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading." The same page states: "To provide a good user experience, pages should have a INP of 200 milliseconds or less." For visual stability, Google Search Central says: "Cumulative Layout Shift (CLS): Measures visual stability. To provide a good user experience, strive to have a CLS score of less than 0.1."

Why the 75th percentile matters more than your average

Google does not judge your site on the average visitor. It looks at the slowest quarter of visits. web.dev is explicit about it: "To ensure you're hitting the recommended target for these metrics for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices."

That one line explains most of the confusion business owners have about performance. Your desktop in the office is not the measurement. The customer on a four year old phone on a busy mobile network is.

The published thresholds, and how to read them

Each metric passes or fails on its own, and Google reports mobile and desktop separately. Mobile almost always looks worse, which is why it is the one to look at first.

LCP: 2.5 seconds or less

2.5 seconds for the largest element on the page. On a service business site that element is usually the hero image or the main headline. When LCP fails, the cause is typically a large unoptimised image, a slow server response, or a render blocking resource that holds up everything behind it.

INP: 200 milliseconds or less

200 milliseconds between an interaction and the page visibly responding. INP replaced First Input Delay, and the difference is the reason the number is harder to pass. FID only measured the delay before the browser began handling the interaction. INP measures the full time until something happens on screen. Heavy JavaScript, chat widgets and a pile of tracking tags all push it up.

CLS: 0.1 or less

A score under 0.1. Layout shift is the metric most people have experienced without having a name for it. You go to tap a button and it moves out from under you, or the text jumps down as something loads above it. The usual causes are images with no dimensions set, late loading ads, cookie banners and fonts that swap and change size after the text has already painted.

Do Core Web Vitals affect rankings? What Google actually says

This is where most of the marketing around the topic goes wrong, in both directions.

What Google says about page experience and its core systems

Google Search Central describes the relationship carefully: "This, along with other page experience aspects, aligns with what our core ranking systems seek to reward." Aligns with. Not a lever you pull to lift a weak page. It is just as direct about the rest of the page experience bucket: "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results."

Read the two sentences together and you have the honest position. These metrics sit inside page experience, page experience aligns with what the core systems reward, and the other signals in that bucket do not move rankings directly at all.

What you should not expect them to fix

Speed will not fix the wrong search intent. If your page targets a query it does not actually answer, a perfect LCP does not help, because the page is not what the searcher wanted. It will not fix a weak offer, unclear pricing, or copy that fails to explain what you do and who for. It will not rescue a page that has no reason to exist.

The order that works is intent first, then technical performance, then conversion work. Doing the third before the first is the most common way a small business spends money on a website and sees nothing change.

How many websites actually pass

Ahrefs measured the field and reported the result plainly: "33% of websites pass the Core Web Vitals threshold." Two thirds do not. Sit with that number for a moment, because it means failing this is normal rather than a sign your web developer did something careless.

There is a second layer to it. web.dev explains how a whole site is classified, not just one page: "if at least 75 percent of page views to a site meet the 'good' threshold, the site is classified as having 'good' performance for that metric. Conversely, if at least 25 percent of page views meet the 'poor' threshold, the site is classified as having 'poor' performance." It is a proportion of your traffic, not one unlucky URL.

If your Core Web Vitals have been sitting in Needs improvement for months, that is usually a build problem rather than a settings problem. You can read how I approach a technical SEO and performance audit, or send me the Search Console screenshot and I will tell you whether it is worth fixing first.

Field data vs lab data: which number should you trust

A lab test runs your page in a controlled environment. Field data is collected from the people who actually visited. Both are useful, and they answer different questions, which is why the two numbers rarely agree.

Search Console field data and the 28 day window

The Core Web Vitals report in Search Console uses field data from real visits over a rolling 28 day window. That delay is deliberate, because it smooths out one bad day. It also means a fix you deploy today will not show cleanly for a fortnight, and it may not settle for a month. If you check the report the morning after a fix and the URLs are still red, nothing has gone wrong. You are reading history.

Why a PageSpeed Insights score is not a ranking score

PageSpeed Insights gives you both halves in one report. There is a lab section with a score out of 100, and a field section with the real numbers from real users. The score out of 100 is a modelled estimate produced from a single test environment. It is not what Google measures. I have seen sites score 100 in the lab while failing INP on mobile in the field, and sites sit in the sixties while passing all three metrics on live traffic. Read the field section before you either celebrate or panic.

The fixes that resolve most failures

Four categories cause the overwhelming majority of the failures I find. None of them require a new website, and three of them you can finish this month.

Images, hero media and video embeds

This is where most LCP failures come from. A 3 MB hero image rendered at 1,600 pixels wide is being sent at several times the size it needs to be. Compress it, serve it in a modern format, set width and height attributes so the browser reserves the space, and load anything below the fold lazily. Video and map embeds have the same problem in a worse form, because they pull in an entire third party player. Delay them until the visitor scrolls near them.

Fonts and render blocking resources

Every stylesheet and font file the browser must fetch before it can draw the page adds to LCP. The usual culprits are an icon library loaded in full to display six icons, three font weights nobody uses, and CSS loaded in the document head that could just as easily load later. Trim the font weights to what the design actually uses, host the fonts yourself rather than calling a third party, and remove the plugins that inject their own stylesheets on every page.

Layout shift caused by ads, banners and consent tools

Layout shift is straightforward to fix once you know to look for it. Anything injected above your content after the page has already drawn will push things around. Reserve the space: give ad slots and promotional banners a fixed height in CSS, set dimensions on every image and iframe, and check what your cookie consent banner does to the page when it appears.

Third party scripts and tag bloat

Every analytics tool, chat widget, heatmap, review widget and advertising pixel adds JavaScript the browser has to run before it can respond to a tap. Most sites carry several of them because each was added for a valid reason years ago and none has been removed since. List every script on the page, find out what each one does, and delete the ones nobody can justify. This is usually the cheapest INP win available.

A 30 minute Core Web Vitals check for a small business site

Do it on mobile first, on the live site rather than a staging copy.

Open the Core Web Vitals report in Search Console and note which metric is failing and whether it affects the whole site or a small group of URLs. Then run your homepage and your main service page through PageSpeed Insights, and read the field data section rather than the score. Look at the three heaviest resources the page loads and see whether any single image or script is disproportionately large. Then open the site on a real phone on mobile data and watch for anything that moves or delays.

Those four steps tell you whether you have an image problem, a script problem, or something structural in how the site was built. Most owners find the answer is the first two.

What to fix first when every metric is red

Start with the metric failing on the most traffic. One metric passed across the site is worth more than three metrics improved on a page nobody visits.

Then work in this order. Images and media first, because they fix LCP and often clear CLS in the same change. Scripts next, because they drive INP. Fonts and stylesheets last. If the site runs on a page builder that ships a large CSS and JavaScript bundle onto every page, image compression alone will not get you to a pass, and that is the point where reviewing the build honestly is the more useful conversation. A technical SEO checklist run over the site will surface the same structural causes.

Measuring progress without breaking the site

Change one thing at a time, then leave it alone. Field data needs 28 days to reflect a change, so batch your work into fortnightly releases and read the trend rather than the daily reading. Keep a dated note of what changed, because without it you cannot explain a movement in either direction.

Before you touch anything, export your current Search Console performance figures so you have a baseline. After the change, watch the vitals and the traffic together. A fix that improves speed and costs you rankings is not a fix. If you want the performance data sitting alongside the commercial numbers, connect the performance data to your Google Analytics reporting so a speed change and a conversion change are visible in the same place rather than in two different tools.

A slower site that answers the question is worth more than a fast site that does not. Fix the intent, then fix the speed, then measure both.

Frequently Asked Questions

What are Core Web Vitals in simple terms?

Three measurements Google takes from real visits to your pages. Largest Contentful Paint is how long the main content takes to appear, Interaction to Next Paint is how quickly the page responds when someone taps or clicks, and Cumulative Layout Shift is how much the layout jumps around while loading. Google publishes a target for each one: 2.5 seconds, 200 milliseconds and 0.1.

Do Core Web Vitals affect my Google rankings?

They are part of page experience, and Google states that page experience "aligns with what our core ranking systems seek to reward". Treat them as a condition that helps rather than a lever that lifts a weak page. Excellent vitals on a page that does not answer the query will not outrank a slower page that does.

How often should an Australian small business check them?

Monthly is enough for most sites. Open the Core Web Vitals report in Search Console, look at mobile first, and check whether any URL group moved from Good to Needs improvement. Check more often after a redesign, a plugin update, or a new advertising or chat script going live.

I got 100 in PageSpeed Insights. Do I still have a problem?

Not necessarily, but a lab score is a modelled estimate from a single test environment. Google assesses the 75th percentile of real page views across 28 days, so your customers on older phones and mobile networks can be failing while the lab reports a perfect score. Check the field data section of the report before celebrating.

Will fixing Core Web Vitals increase my sales?

It can remove friction, particularly on mobile checkout and enquiry forms where delay causes people to give up. It will not fix a bad offer, unclear pricing, or a page that targets the wrong search intent. The honest sequence is intent first, technical performance second, conversion work third.

Is it worth paying someone to fix this, or can I do it myself?

If the failures trace back to images, fonts or a single heavy plugin, most site owners or their web person can resolve it in an afternoon. If the failures come from how the template is built, how JavaScript loads, or a stack of third party tags, a technical review will usually cost less than the trial and error.