How Website Speed Affects SEO (And What Matters More)

Page speed is a ranking factor. It is also a much smaller one than the industry implies, and treating it as the main lever is how sites end up with a good score and no traffic.

Here’s a proportionate view.

What speed actually does for rankings

Google has confirmed page experience signals, including Core Web Vitals, are used in ranking. What’s usually left out is the weighting: relevance and quality dominate. A slow page that answers the question beats a fast page that doesn’t, consistently.

Where speed does matter for search:

• As a tie-breaker. Between comparable pages, the faster one has an edge.
• On mobile. Where slowness is most severe and most common.
• For crawl efficiency. On large sites, slow responses mean fewer pages crawled per visit.
• Indirectly, through behaviour. People who bounce because a page didn’t load don’t engage, don’t link and don’t return.

Why it matters more for conversion

This is the argument that should actually motivate the work.

Slow pages lose people before they read anything. The relationship between load time and conversion is well established across e-commerce and lead generation, and it’s steepest in the first few seconds — the difference between four seconds and two matters far more than between two and 1.5.

So the honest framing is: improve speed for the users, and take the ranking benefit as a bonus. That framing also stops you doing daft things to chase a score.

The three metrics, in plain terms

LCP (Largest Contentful Paint). How long until the main element appears — usually a heading or hero image. Under 2.5 seconds.

INP (Interaction to Next Paint). How long the page takes to respond to a tap or click. This is where JavaScript-heavy sites fail. Under 200 milliseconds.

CLS (Cumulative Layout Shift). How much things jump around while loading. Under 0.1. Usually caused by images without dimensions, late-loading fonts, or injected banners.

Measure with field data — real visitors, in Search Console — not only lab tools. Lab tests use a simulated device from one location and can be flattering or unfair.

Where the wins usually are

Four things account for most of the improvement on a typical business site:

Images. Almost always the largest payload. Modern formats, sized for the container, lazy-loaded below the fold, with explicit dimensions.

Unnecessary JavaScript. Tag managers, chat widgets, A/B tools, analytics, consent platforms, carousel libraries. Audit what loads and justify each one.

Fonts. Self-host, subset, preload the one that renders the headline, use font-display: swap.

Rendering strategy. Static generation or server rendering with sensible caching, rather than fetching everything client-side.

Do those four and most business sites land in acceptable territory. The remaining work has real diminishing returns.

What isn’t worth doing

• Chasing the last few Lighthouse points by deferring things users need immediately.
• Removing a genuinely useful feature to save 30 milliseconds.
• Optimising a page that gets forty visits a month while the main service page is slow.
• Treating the lab score as the goal rather than the field data.

A sensible order

1. Get field data and find the slowest template, not the slowest page.
2. Fix images on it.
3. Remove or defer third-party scripts.
4. Sort fonts.
5. Re-measure.
6. Only then look at rendering strategy and code-level work.

The bigger point

If your site is slow and your content doesn’t answer what people search for, speed is not your problem. Fix relevance first, then remove the friction.

If your content is good and the site is slow, that’s a genuinely fixable constraint — and it’s the kind of work that combines technical SEO with actual development, which is the combination most SEO engagements are missing.