Do Core Web Vitals affect your Google ranking?

Yes - website speed affects your Google ranking, but it is a tiebreaker, not the main lever, and the speed signal Google actually uses has a name: Core Web Vitals. These are 3 measurements of how a real visitor experiences your page loading and responding - how fast the main content appears, how quickly the page reacts when tapped, and whether things jump around while it loads. This page explains each one in plain English, tells you honestly how much they move rankings, and shows you what to check yourself before you spend a dollar fixing it.

The short version, if you read nothing else: relevant content that answers the searcher's question is what gets you ranked. Core Web Vitals decide who wins when two pages are otherwise equally good. So you want them in the "good" band - and most Australian small business sites are nowhere near it - but you do not want to torch your budget chasing a perfect score that will not, on its own, outrank a better page.

What Core Web Vitals actually are

Core Web Vitals is Google's name for 3 specific numbers that try to capture how a page feels to a real person on a real phone, rather than how it looks in a developer's lab. Google measures them from actual Chrome users visiting your site - the field data in the Chrome UX Report - and rolls them into the page-experience signals that feed ranking. If you want the one-paragraph definition, what Core Web Vitals are is the short version; the rest of this section is the same thing slower.

There are 3 of them, and each measures a different kind of "this page is annoying".

Largest Contentful Paint (LCP) - how fast the main thing shows up

LCP is the time from clicking your link to the moment the biggest piece of content on the screen has loaded - usually your hero image, headline, or main block of text. It is the closest single number to "how long until this page looks ready". Google's threshold for "good" is 2.5 seconds or less on mobile; anything past 4 seconds is "poor", and the band between is "needs improvement". The plain-English walkthrough is at Largest Contentful Paint, and what a good LCP score is spells out the thresholds.

LCP is the one most small business sites fail, and the usual culprits are boring: an enormous unoptimised hero photo straight off a phone camera, a slow or overloaded host, or a pile of third-party scripts (chat widgets, tracking pixels, font loaders) the page waits on before it can paint. None of those require a rebuild to fix.

Interaction to Next Paint (INP) - how fast the page reacts when you tap

INP measures the lag between a visitor doing something - tapping a button, opening a menu, ticking a box - and the page visibly responding. A low INP means the page feels snappy; a high one means that frustrating half-second where you tap and nothing happens, so you tap again. Google's "good" threshold is 200 milliseconds or less. We keep a plain-English note on Interaction to Next Paint.

INP is the newest of the three. It replaced an older metric called First Input Delay in March 2024 because FID only measured the first tap and was too easy to pass - what replaced FID with INP covers that switch. The common cause of a bad INP is heavy JavaScript: bloated page builders, too many plugins, or a theme doing far more work than a brochure site needs.

Cumulative Layout Shift (CLS) - whether the page jumps around

CLS measures how much the content moves while the page is still loading. You have felt bad CLS: you go to tap a link, an image or ad loads above it, everything shifts down, and you tap the wrong thing. Google's "good" threshold is a score of 0.1 or less (it is a ratio, not a time). We keep a plain-English note on Cumulative Layout Shift.

CLS is usually the cheapest to fix because the causes are specific: images and embeds without dimensions set, fonts that swap and re-flow the text, or banners injected at the top after load. A developer who knows the term can normally clear it in an afternoon.

How much speed really affects ranking

Here is the honest version, because the SEO industry has spent years overselling this. Core Web Vitals are a ranking signal, confirmed by Google, but they are a tiebreaker, not a trump card. Relevance, content quality, and the authority of your site decide the bulk of where you rank. Speed acts at the margin: between two pages that answer the query equally well, the faster, more stable one gets the edge. A blazing-fast page about the wrong thing still loses to a slower page that actually answers the question.

What that means in practice for a small business: do not expect a speed fix to vault you from page 3 to page 1. That gap is almost always a content and relevance problem, not a performance one. But if you are already competitive - ranking 4th to 10th for terms you should own - then a page sitting in the "poor" band is handing free position to whoever loads faster, and closing that gap is one of the cheaper wins available.

And the gap is real. Small-business sites are slow far more often than their owners realise - it is common for a phone to wait several seconds for the main content to appear, well past Google's 2.5-second "good" threshold. So if your site is slow, you are not unusually broken; you are normal. The opportunity is exactly that: most of your local competitors are equally slow, which makes a page in the "good" band a genuine, durable advantage rather than table stakes.

The other reason speed matters has nothing to do with Google's algorithm and everything to do with the human holding the phone. A page that takes several seconds to show its main content loses visitors before it has a chance to rank - they hit back and try the next result. Even if Core Web Vitals contributed zero to ranking, a slow site would still cost you customers at the door. The ranking signal is the smaller half of the argument.

What to check yourself

You can measure all of this for free in about 5 minutes, no developer needed. The point of doing it yourself first is simple: you want to walk into any conversation with a developer already knowing whether you have a real problem, and which of the 3 numbers is the culprit.

Run your page through Google PageSpeed Insights. Open pagespeed.web.dev, paste your homepage URL, and read the mobile tab (not desktop - most of your visitors and most of Google's judgement are mobile). The numbers that matter are the 3 Core Web Vitals at the top. Green is good, orange needs improvement, red is poor.

Read the field data, not just the lab score. PageSpeed Insights shows two things: a "lab" test it runs live, and a "field" panel labelled something like Discover what your real users are experiencing - that field data is the Chrome UX Report, built from actual visitors, and it is the half that feeds ranking. If your site is too quiet to have field data, Google falls back to broader signals; either way, the lab score is a useful guide but the field data is the real verdict.

Test more than the homepage. Check a service page and a blog post too. Speed problems often live in one heavy template - a gallery page, a page-builder landing page - while the rest of the site is fine.

Read the reference when a term confuses you. Google's own web.dev Core Web Vitals guide is the authoritative definition of every metric and threshold. It is written for developers, but the metric explanations are readable. For the small-business translation of the same material, our plain-English Core Web Vitals walkthrough covers it without the jargon.

That is the whole self-check. You now know your 3 numbers, which band each sits in, and whether the problem is one bad page or the whole site. That is enough to decide whether to act and what to ask for.

What to ask your developer

If your numbers are poor and you have a web developer or agency, the goal of the conversation is to get specific, scoped fixes - not an open-ended "make it faster" that turns into a rebuild quote. The questions below map to the 3 metrics and keep the work bounded.

For a bad LCP: "Are our hero images compressed and correctly sized for mobile? Is our hosting fast enough, or are we on oversold shared hosting? Which third-party scripts is the page waiting on before it shows content, and can any be deferred or removed?"

For a bad INP: "How much JavaScript is this page loading, and how much of it do we actually use? Are there plugins or page-builder features we could drop? Is our theme heavier than this site needs?"

For a bad CLS: "Do our images and embeds have width and height set so they reserve their space? Is a font swap or an injected banner shifting the layout after load?"

For all three: "Can you show me the before-and-after PageSpeed numbers when you are done?" That last one matters most. It turns a vague invoice into a measurable result you can verify yourself in the same free tool you started with. A developer confident in the work will happily give you the before-and-after; one who deflects is telling you something.

A reasonable developer can usually move a site from "poor" to "good" through image optimisation, script cleanup, and caching alone - hours of work, not a project. Be wary of anyone whose answer to a slow page is "you need a whole new website". Sometimes that is true, but far more often the existing site is fixable, and "rebuild it" is the easier thing to sell.

When it's time to bring in outside help

Most small business speed problems are fixable by your existing developer with the scoped questions above. A few are not, and the signs are fairly clear.

It is time for specialist help when the easy wins have been done and the numbers are still poor - when images are optimised, plugins trimmed, caching on, and LCP still will not come under control. At that point the problem is usually structural: a theme or platform fundamentally too heavy, or a host that cannot deliver pages fast enough no matter what sits on top. That is a genuine performance-engineering or migration job, and it is worth paying for once the cheap fixes are exhausted - not before.

The other honest trigger is opportunity cost. If you are ranking just off page 1 for terms that drive real revenue, and your competitors load faster, the speed gap is costing you money every week - and that is the case where paying a specialist to close it pays for itself. If you are nowhere near the first page, spend the money on content and relevance first; speed is not your bottleneck yet.

What we don't do

Red Bridge Cyber scans and explains the public-facing speed signal - we measure your Core Web Vitals from the outside, score them against the Australian small business baseline, and tell you in plain language which of the 3 numbers is hurting you and why. What we do not do is rebuild your website, optimise your images, or rewrite your code. We are the layer that tells you whether you have a problem and how big it is; the fix happens with your developer, or a performance specialist, or sometimes a different host.

Think of it as the difference between the diagnosis and the surgery. Google's PageSpeed Insights gives you the raw numbers for one page; our scan puts those numbers next to every other public-facing weakness - email, certificates, DNS, security headers - and against what's normal for a business your size, continuously, so the speed regression that creeps in after a site change gets caught the week it happens rather than the year after. Then you take the diagnosis to whoever does the work. We are deliberately not that whoever - and a service that both scores your speed and sells you the rebuild has a conflict we would rather not have.