How speed affects rankings

Site speed is a genuine Google ranking factor, primarily through Core Web Vitals — the metrics that measure real-user loading, responsiveness and visual stability. But it’s important to be accurate about how much it matters: speed is a relatively minor ranking factor compared to relevance, content quality and authority. It acts mostly as a tie-breaker, deciding close contests between pages that are otherwise well-matched — which is exactly the situation on competitive commercial terms.

So a fast site won’t rocket a weak page to the top, and a slightly slow site won’t sink a genuinely great one. But when you’re competing against strong rivals for valuable terms, speed can be the deciding edge. And because it’s a fixable, foundational factor, getting it right removes a disadvantage and lets your content and authority work pay off fully.

How speed affects conversions (the bigger story)

The larger, more immediate impact of speed is on conversions, and this is where slow sites really cost you. Study after study links faster pages to lower bounce rates and higher conversion rates — visitors, especially on mobile, abandon slow sites quickly, often within a couple of seconds. So a slow site doesn’t just cost you some ranking positions; it costs you a share of the visitors who do find you, who leave before converting.

This reframes the business case entirely. The reason to fix speed is rarely ‘it will transform our rankings’; it’s ‘it will stop us quietly leaking the traffic and conversions we already earn.’ Framed that way, speed is a conversion investment with an SEO bonus — a far more compelling and accurate case than chasing a green score for its own sake.

What actually slows sites down

In our experience auditing sites, the most common speed culprits are, roughly in order: slow server response (often cheap or overcrowded hosting), oversized and unoptimised images, render-blocking and excessive JavaScript (frequently from third-party scripts like chat widgets, analytics and ad tags), and heavy, bloated themes or page builders. Each has a clear fix, and most sites have just one or two dominant problems rather than all of them.

The key is to diagnose before prescribing. Tools like Google PageSpeed Insights and the Core Web Vitals report in Search Console show you what’s actually slow and why, so you fix the real bottleneck rather than guessing. Server response and image optimisation account for the majority of wins on most sites, and both are usually quick to address.

A practical approach to improving speed

Start by measuring your real-world status in Search Console (field data from actual users), then diagnose the cause of any failing pages with lab tools like PageSpeed Insights. Fix the highest-impact, lowest-effort issues first: optimise and properly size your images (serve modern formats like WebP), ensure fast hosting and caching, and rein in heavy or unnecessary third-party scripts. Then re-measure and give the field data a few weeks to reflect your changes.

Treat speed as an ongoing discipline rather than a one-off project — performance regresses over time as new features and content are added, so re-check periodically. And keep it in perspective: get your speed genuinely good, then direct your energy to the content and authority that move rankings hardest. For the full technical detail on the metrics involved, see our Core Web Vitals guide; to find out exactly what’s slowing your specific site, a free SEO audit will tell you.

What actually moves the needle on Core Web Vitals

Most speed work fails because it optimises the wrong layer. The biggest LCP gains usually come from three places: serving properly sized, modern-format images (AVIF/WebP) from a CDN; eliminating render-blocking CSS and JavaScript in the critical path; and cutting server response time (TTFB) with caching or better hosting. Everything else — minification, icon sprites, micro-optimisations — is decoration by comparison.

INP, which replaced FID, punishes heavy JavaScript. The fix is structural: ship less JS, defer what isn’t needed for first interaction, and break up long tasks. CLS is almost always reserved space: give images and embeds explicit dimensions, and never inject banners above content after load. Measure with field data (CrUX, Search Console’s Core Web Vitals report), not just lab scores — Google ranks on what real users experience.

Common speed mistakes that waste budgets

Speed as a conversion lever, not just a ranking signal

Speed pays twice. Beyond rankings, the conversion evidence is consistent: faster pages convert meaningfully better, and every additional second of load time measurably increases abandonment — which is why we treat speed work as CRO work. A second saved on a high-traffic landing page compounds into real revenue regardless of what rankings do.

In the AI search era this doubles again: fast, cleanly rendered pages are easier for AI systems to fetch and cite. The sites winning AI citations are overwhelmingly the ones that already pass Core Web Vitals — slow sites are quietly filtered out of a growing share of search surfaces.

A practical speed-optimisation workflow

Diagnosing the slow page nobody can explain

When a page is slow and the usual suspects are clean, work the waterfall: in DevTools, find the single longest bar. A slow TTFB points at hosting, database queries or missing cache — server-side work no front-end optimisation can rescue. A long gap before the LCP image loads points at discovery order — the browser found it too late; preload it. A pile of purple (scripting) means JavaScript is the tax — audit third-party tags first, they’re usually the heaviest and least necessary.

Most ‘mystery’ slowness is one of those three patterns. The discipline is measuring before touching anything: optimisation without a waterfall is guesswork with a deploy step.

Related guides

Frequently asked questions