“My website feels slow” is one of the most common things a business owner says to us, and it almost never turns out to be one problem. Slow can mean the page sits blank for too long before anything useful appears. It can mean the page looks finished but ignores you for half a second when you tap a button. It can mean the text shuffles down the screen just as you go to read it. Those are three different faults, with three different causes and three different fixes.
Google measures all three, publishes the thresholds openly, and feeds them into its ranking systems. They are called the Core Web Vitals. Understanding them is worth an afternoon of any business owner’s time - not because a perfect score will rocket you to the top of the results, but because each number maps to something a real customer actually feels when they land on your site.
The three numbers and what each one measures
Google’s own documentation is refreshingly plain about this. There are three metrics, and each has a target.
Largest Contentful Paint - how long until something useful appears
LCP measures loading performance. Google’s guidance is to “strive to have LCP occur within the first 2.5 seconds”. In practice, the “largest contentful” element is usually your hero image, a banner, or the big block of heading text at the top of the page. LCP is the moment that element finishes rendering - not the moment the page technically starts loading, and not the moment the last tracking script finally settles.
This is the number most people mean when they say a site is slow: someone taps your listing on their phone, stares at white space for four seconds, and goes back to the search results.
Interaction to Next Paint - how long until the page answers you
INP measures responsiveness. The target is “an INP of less than 200 milliseconds”, and Google grades anything above 500 milliseconds as poor responsiveness.
INP replaced an older metric called First Input Delay in 2024, and the change matters. As Google’s engineers put it, “FID only measured the input delay of the first interaction on a page. INP improves on FID by observing all interactions on a page.” So it is no longer enough for your site to feel snappy on the first tap. Opening the menu, expanding an FAQ, filtering a product list, submitting an enquiry form - every one of those interactions is being watched.
Cumulative Layout Shift - how much the page jumps around
CLS measures visual stability, and it is scored as a ratio rather than a time. A “CLS score of 0.1 or less” is good; anything greater than 0.25 is poor.
This is the one nobody complains about by name but everybody has suffered. You go to tap “Book now”, an ad or a late-loading image pushes the button down forty pixels, and you tap something else entirely. Google names the usual culprits: “images or videos with unknown dimensions”, “fonts that render larger or smaller than its initial fallback”, and “third-party ads or widgets that dynamically resize themselves”.
The score comes from real visitors, not from a test on your laptop
This is the part that trips up most people, and it is the reason a site can look perfect in a speed-testing tool and still fail in Search Console.
There are two ways to measure a website’s speed. Lab data comes from a simulated test under controlled conditions. Google is clear that “lab measurement is the best way to test the performance of features during development”, but equally clear that “only field measurement can accurately capture the complete picture”.
Field data comes from the Chrome User Experience Report, which “collects anonymised, real user measurement data for each Core Web Vital” from actual people browsing your site on actual devices and actual connections. A budget Android phone on patchy mobile reception in Bunyip is part of your score. A fast laptop on the NBN is part of your score. They average out very differently.
And the bar is not the average. Google recommends the 75th percentile: “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.” In plain terms, three out of four visits have to clear the threshold - so the slowest quarter of your traffic is what decides whether you pass, and mobile is scored separately from desktop.
What actually causes each problem
Once you know which of the three numbers is failing, the list of likely causes gets short.
For LCP, Google breaks the delay into four parts: time to first byte, resource load delay, resource load duration, and element render delay. The advice is to make sure “the LCP resource starts loading as early as possible”, then reduce render-blocking resources by inlining or deferring stylesheets and keeping synchronous scripts out of the page head, then compress and cache the resource itself, then look at the server. The honest caveat comes from the same page: “it’s rare that a quick fix to a single part of a page will result in a meaningful improvement to LCP.”
For CLS, the fixes are usually the cheapest of the three. Set explicit width and height attributes on every image and video. Reserve space for ads, embedded maps and booking widgets before they load. Preload the fonts you actually use, and choose a fallback that is close in size to the real thing.
For INP, the delay sits in one of three phases: input delay before your code starts running, processing duration while it runs, and presentation delay before the browser can paint the result. On a typical small-business WordPress site, the usual offender is sheer volume - a page loading a slider plugin, three tracking pixels, a chat widget, a pop-up builder and a page builder’s own scripts is asking the browser to do a great deal of work before it can respond to a tap.
Will fixing this lift your Google ranking?
Partly, and less dramatically than most agencies will tell you. Google’s page experience documentation is unusually direct on this point.
“There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience.”
It goes further and warns against exactly the behaviour the SEO industry encourages: “there’s more to great page experience than Core Web Vitals scores alone. These scores are meant to help you to improve your site for your users overall, and trying to get a perfect score just for SEO reasons may not be the best use of your time.” Google also notes that good results in the Search Console report “doesn’t guarantee that your pages will rank at the top of Google Search results”, and that Search “always seeks to show the most relevant content, even if the page experience is sub-par”.
So the case for fixing your Core Web Vitals is not really a ranking case. It is a conversion case. A visitor who waits four seconds, taps a button that moves, and gives up never appears in your enquiry inbox - and no amount of ranking fixes that.
Where to start if you’re not a developer
- Open Search Console. The Core Web Vitals report there is built on real field data for your own site, split by mobile and desktop. It tells you which URLs are failing and on which metric.
- Fix the category, not the page. Small-business sites are usually built from a handful of templates. One failing metric almost always affects every page using that template, so fixing the template fixes dozens of URLs at once.
- Audit your plugins honestly. Every plugin you are not actively using is pure cost - to LCP, to INP, and to your security exposure.
- Start with CLS. It is usually the quickest win and needs the least technical work.
- Re-check after four weeks. Field data is collected over a rolling 28-day window, so a fix made today will not show in your report tomorrow. Do not panic and undo good work.
How this fits into a website budget
Performance work sits awkwardly in most quotes because it is invisible until it is missing. If you are weighing up a rebuild against a tune-up, our guide to what a website really costs sets out where the money actually goes. It is also worth reading alongside what WCAG 2.2 means for Australian businesses - speed and accessibility overlap far more than people expect, and the same sloppy markup tends to damage both.
If you want someone to look at it
Madexify builds and maintains websites for businesses across Melbourne’s south-east - Pakenham, Officer, Beaconsfield, Berwick, Narre Warren, Cranbourne, Clyde and Bunyip. If your site feels slow and you are not sure whether it is a real problem or just the way it feels to you, send us the address and we will pull your actual field data and tell you plainly what is wrong. If the answer is “nothing much, leave it alone”, we will tell you that too - it happens more often than you would think. See our web development and design services, email contact@madexify.com, or call +61 424 485 087.
Sources: Google Search Central - Core Web Vitals, Google Search Central - Understanding page experience in Google Search results, web.dev - Web Vitals, web.dev - Interaction to Next Paint, web.dev - Cumulative Layout Shift, web.dev - Optimize Largest Contentful Paint. All accessed 15 September 2026.
This article is part of our Local SEO and Google Guide. Browse all our guides on the guides page.
