Three numbers Google cares about
Since 2021, Google has treated three website performance metrics as official ranking signals. They're called Core Web Vitals. If your site fails them, you rank lower and convert fewer visitors. Most small business owners across Australia have never heard of them, which is how sites end up quietly losing leads without anyone noticing.
The three metrics measure different things, but they all answer the same underlying question: is this website a good experience for the person using it?
If you want the developer-level view, we have a deeper breakdown of web performance metrics. This post is the owner's version: what each metric means, why it matters, and how to tell if your site has a problem.
LCP, Largest Contentful Paint
What it measures: how long it takes for the biggest thing on your page to load. Usually that's your hero image, the main headline, or a large banner.
Pass threshold: under 2.5 seconds
Why it matters: LCP is a proxy for "how fast does this site feel?" If your hero image takes 5 seconds to appear, visitors are already tapping back before they see your value proposition.
What causes failures:
- Huge, unoptimised images (a 6MB photo where a 200KB one would do)
- Images served from the web server instead of a CDN
- Hero images that rely on JavaScript to load, so they wait for scripts to finish
- Cheap or oversubscribed hosting
- Too many fonts or scripts blocking the initial render
Real-world example: A Sydney service business dropped a fresh hero photo straight onto the homepage. 11MB, 6000px wide, no optimisation. LCP went from 1.8s to 7.2s overnight. Rankings dropped within a fortnight.
INP, Interaction to Next Paint
What it measures: how quickly your site responds when someone taps a button, opens a menu, or fills in a form. Replaced the older "FID" metric in 2024.
Pass threshold: under 200 milliseconds
Why it matters: INP captures "this site feels broken." A page can load fast and still feel awful if the menu button takes 800ms to respond to a tap. Mobile is where most small business sites fail this metric, even ones that look fine on desktop.
What causes failures:
- Heavy JavaScript on every page (usually from over-eager page builders, chat widgets, popup tools, analytics scripts)
- Third-party tracking pixels (Facebook, TikTok, LinkedIn, heat-mapping tools) blocking the main thread
- Unoptimised WordPress themes with too many plugins
- Carousels, sliders, and animated elements running continuously
- Live chat widgets loading their full payload before they're needed
Real-world example: A clinic's site had a chat widget, Facebook pixel, Google Ads tag, Hotjar, two Google Fonts, and a popup tool all loading synchronously. INP was 680ms on mobile. Every tap felt sluggish. We removed the widgets they weren't actually using (a Facebook pixel from a campaign that ended 18 months earlier, Hotjar nobody had logged into for a year) and INP came down to 140ms.
CLS, Cumulative Layout Shift
What it measures: how much things jump around on the page as it loads. If you've ever tried to tap a button and had an ad load above it, sending your tap to the wrong thing, that's layout shift.
Pass threshold: under 0.1 (it's a unitless score)
Why it matters: Layout shift is infuriating. It's the metric most tied to "this website feels cheap." Google knows that and weights it accordingly.
What causes failures:
- Images without width and height attributes (the browser doesn't know how much space to reserve)
- Fonts loading late and changing the text layout when they appear
- Banners, cookie notices, or ads pushing content down
- Embedded videos or iframes without reserved space
- Dynamically injected content (popups, testimonial sliders, trust badges)
Real-world example: An eCommerce store had cookie consent loading 1.2 seconds after the page appeared, pushing the hero image, the headline, and the Add to Cart button down 80 pixels each time. Customers were misclicking. CLS was 0.34, three times over the fail threshold.
How to check your own site in under five minutes
You don't need a developer to diagnose the problem. Two free tools will tell you where you stand.
PageSpeed Insights
Go to pagespeed.web.dev, paste in your URL, and click Analyze. You'll get two reports, one for mobile and one for desktop. The mobile one is what Google uses for ranking.
Look for the three metrics near the top of the results. Green means pass, orange is borderline, red means failing. The tool also points to exactly which images are too large, which scripts are slow, and which elements are shifting.
Google Search Console
If your site is verified in Search Console, go to Experience → Core Web Vitals. This shows real-world performance from actual Chrome users on your site, broken down by mobile and desktop. It's the same data Google uses for ranking, so it's more reliable than a single PageSpeed Insights test (which can vary between runs).
URLs in the "Poor" column are the pages actively hurting your rankings.
What you can fix without a developer
Plenty of performance problems are content-level issues a non-technical owner can fix directly.
Compress your images. Run every hero image through tinypng.com or squoosh.app before uploading. Aim for under 300KB for most images, and under 150KB for logos and thumbnails.
Remove unused plugins. Every WordPress plugin adds CSS and JavaScript to every page load. If you haven't used a plugin in six months, deactivate it, then delete it.
Audit your tracking scripts. The pixel from a Facebook campaign you ran two years ago is still firing. Same goes for TikTok, LinkedIn, Pinterest, and Hotjar. Pull anything you're not actively using.
Resize images to the size they actually display at. If your hero shows at 1600px wide, a 4800px image is three times bigger than needed. Most image editors have a "resize to width" option.
What needs a developer
Some issues are structural and need to be fixed in the code:
- Image formats (switching JPG to WebP or AVIF, proper lazy loading)
- Font loading strategy (preload, font-display, self-hosting)
- JavaScript bundling (code-splitting, deferred loading of non-critical scripts)
- Server-side rendering vs client-side rendering decisions
- CDN configuration and caching headers
- Reserving space for dynamic content to eliminate layout shift
This is what we focus on in our website performance optimisation service: finding the root causes and fixing them properly, rather than bolting on a caching plugin and hoping for the best.
Why this matters commercially
Core Web Vitals aren't an abstract SEO thing. They affect the two numbers your business actually cares about.
Rankings. Google has been clear: when two pages are roughly equivalent in relevance, the one with better Core Web Vitals ranks higher. In competitive local searches around Melbourne, Sydney, or Brisbane, that's the difference between position 3 and position 8.
Conversions. The link between page speed and conversion rate is measurable and consistent. Each extra second of load time costs around 7% in conversions on average, more on mobile. A site converting at 2% at 2s load time converts closer to 1.4% at 4s.
If you run CRO experiments without fixing Core Web Vitals first, you're optimising a leaky bucket.
When to take it seriously
If you run a small business site and you've never checked Core Web Vitals, check them today. It takes 90 seconds. If your site passes, good. Check again every quarter. If it fails, you've found something concrete that's costing you traffic and leads, and the fixes are usually well-scoped and high-leverage.
If you'd like a proper audit of where your site stands and a plan to fix the issues, get in touch. We'll run the diagnostics and tell you honestly what needs doing and what doesn't.
