How does page speed affect Google ranking?
Page speed is a Google ranking factor, but a minor tiebreaker - Core Web Vitals decide close calls, while relevance and content quality do the heavy lifting.
Page speed is a real but minor Google ranking factor - here is what actually moves the needle for a small-business site:
- Relevance beats speed - Google has stated that great page experience does not override great content; a fast page about the wrong thing still loses to a slower, better-matched one.
- Core Web Vitals are the signal - three numbers (LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1) measured mobile-first from real Chrome visitors, not a lab test.
- The fix is two things - oversized images and render-blocking scripts cause most slow loads; fixing those two moves LCP more than chasing a perfect lab score.
- Measure before you spend - PageSpeed Insights shows the field data Google ranks on, free, before you pay anyone to "optimise".
Don’t chase 100/100 - "good" Core Web Vitals is the whole target, and most small sites get there by compressing their hero image and cutting unused plugins.
Yes, page speed is a Google ranking factor - but a minor one, a tiebreaker between pages that are otherwise close on relevance and content quality, which is where almost all of Google's ranking weight actually sits. The specific signal Google uses is Core Web Vitals, three measurements of how a page loads and responds, rolled into the broader page-experience system.
The answer in detail
Google has been explicit about this since it merged speed into the page-experience signals. Page experience is "one of many factors" used to rank results, and it does not override relevance: "great page experience doesn't override having great content," in Google's own wording on Google Search Central. Put plainly, a fast page about the wrong thing still loses to a slower page that answers the query. Speed decides ties; it does not win the match.
The measurable part of that signal is Core Web Vitals - three numbers. LCP (Largest Contentful Paint) is how long until the main thing on screen has loaded. INP (Interaction to Next Paint) is how quickly the page reacts when someone taps or clicks. CLS (Cumulative Layout Shift) is how much the page jumps around while it settles. Google groups each into "good", "needs improvement", or "poor", and the bar for "good" is an LCP under 2.5 seconds, an INP under 200 milliseconds, and a CLS under 0.1.
Two things matter about how small the weight really is. First, Google ranks using hundreds of signals, and page experience is a single, modest one - there is no evidence that going from "needs improvement" to "good" vaults a page up the results when the content underneath is unchanged. Second, the data Google uses is field data, not a lab test: it comes from real Chrome users visiting your site (the CrUX dataset), measured mobile-first because Google indexes the mobile version of your page. A lab tool can tell you a page is slow; only field data over real visitors tells you whether Google agrees.
So the honest framing for a small business is this: fixing speed will not rescue thin content, and it will not, on its own, move you past a genuinely better-matched competitor. What it does is stop speed from being the reason a close call goes against you - and, more importantly, stop slow pages costing you the visitors who arrive and leave before anything loads.
Common variations
Does it affect mobile more than desktop? Effectively, yes - because Google uses mobile-first indexing, the page it judges for ranking is the mobile version. Core Web Vitals are reported separately for mobile and desktop in Google's tools, and mobile is almost always the worse of the two: slower networks, weaker phone CPUs, and heavier ad and image payloads. If you only have time to fix one, fix mobile.
Does HTTPS matter, and is it part of Core Web Vitals? HTTPS is a separate, long-standing ranking signal and part of the page-experience system, but it is not one of the three Core Web Vitals. It is also pass/fail rather than a sliding scale - you either serve the page over a valid certificate or you do not. For a small business it is table stakes, not a lever; nearly every host enables it free now, and if yours has not, that is the first thing to fix and it has nothing to do with speed.
What about Google Ads quality score - is that the same thing? No, and this confusion is common. Quality Score is part of Google Ads (paid search): landing-page experience, including load speed, feeds the score that decides what you pay per click and where your ad shows. That is a separate auction system from organic ranking. Speed influences both, but through two different doors - a slow page can quietly raise your ad costs at the same time it nudges your organic position. The fix for both is the same page.
What PageSpeed Insights would have told you
Before you guess at any of this, measure it. Google PageSpeed Insights is the free tool that does both halves of the picture in one report: it shows the field data Google actually uses (your real Chrome visitors' Core Web Vitals over the last 28 days, the data that feeds ranking) and a lab diagnostic that re-loads the page in a controlled environment to tell you why it is slow.
The two halves answer different questions. The field data at the top tells you whether you have a problem Google sees - if it says your mobile LCP is "poor", that is the verdict. The lab section below tells you what to do about it: it lists the specific render-blocking scripts, oversized images, and slow server responses dragging LCP up, usually with the worst offender first.
This is the layer most small-business owners never look at, and it shows. A large share of small-business sites sit well past Google's 2.5-second "good" threshold for Largest Contentful Paint - slow enough to feel it on a phone. That is not a tuning problem; it is a never-measured problem. The report was always there, free, telling owners exactly what was wrong. Almost nobody opened it.
The small-business-appropriate fix
Do not chase 100/100. The score at the top of PageSpeed Insights is a lab grade, and the last 20 points cost the most effort for the least real-world gain - agencies sell "we'll get you to 100" precisely because it sounds impressive and bills hours. Google ranks on the field data, not the lab score, and "good" Core Web Vitals is the whole target. A site sitting in green at 75/100 lab is doing better by Google's actual measure than one polished to 95 that real phones still load slowly.
For almost every small-business site, two fixes move LCP more than anything else:
Images. The single largest element on most pages is a hero image or a photo, and it is usually shipped at far more resolution than it is displayed at - a 4000-pixel photo squeezed into a 1200-pixel slot. Compress it, serve it in a modern format (WebP or AVIF), and size it to its actual display dimensions. On the average small-business site this one change is worth several seconds of LCP.
Whatever blocks the page from rendering. The second-worst offender is almost always scripts and fonts loading before the page can paint - a pile of plugins, a chat widget, three analytics tags, a custom font that hides text until it downloads. Cut the plugins you do not use, defer the ones you do, and let text render in a system font until the custom one arrives.
That is the 80/20. If you are on WordPress, a single reputable caching-and-optimisation plugin does most of both automatically. If you are on Squarespace, Wix, or Shopify, the platform handles most of the infrastructure and your job shrinks to the images. Either way: run Google PageSpeed Insights, read the field data, fix the top two diagnostics, re-run it in 28 days, and stop. You want to know whether speed is hurting your search ranking - and the answer is usually "only if you have ignored these two things for years."
If the three-letter acronyms are still a fog, read our plain-English Core Web Vitals walkthrough, which takes LCP, INP and CLS one at a time with no jargon. The short reference answers are here too: does page speed affect Google ranking, what Core Web Vitals are, and what replaced FID with INP - the one piece of trivia that trips people up, because the old responsiveness metric was retired in 2024.
When this answer isn't enough
This page assumes the ordinary case: a normal small-business site, slow for ordinary reasons, where the fix is images and a few scripts. It stops being enough in a few situations. If your site is genuinely complex - a large catalogue, a booking engine, a heavy single-page app - the LCP problem may live in server response time or JavaScript execution that no plugin will untangle, and that is a developer conversation, not a checklist. If your rankings dropped and speed was unchanged, speed is not your story; look at content, links, or a Google update instead, because a stable Core Web Vitals score cannot explain a sudden fall. And if PageSpeed Insights shows "good" field data but you still feel the site is slow, the lag is probably somewhere it does not measure - a clunky checkout, a slow search box, a third-party booking widget.
The fastest way to see where you stand is to stop guessing and look. Run your site through our scan and the Speed category will show your Core Web Vitals against the Australian small-business baseline, in plain language, beside the rest of your posture - so you find out whether speed is actually your problem before you spend a dollar fixing it.