Does site speed affect Google rankings?

The short answer

Site speed does affect Google rankings, but indirectly and less than most people assume. Google confirms that Core Web Vitals are part of its ranking signals — as a low-weight factor that mostly shows up when everything else is equal. A fast page with mediocre content will not outrank a slower page that fully answers the query.

The practical conclusion is simple: speed will not lift you into the top, but a genuinely slow site undermines everything else — people return to the search results, conversion drops, and on large sites crawl frequency falls too. So take speed to "fine" and stop there.

What Google actually measures

The metric set has been called Core Web Vitals since 2021, and since 2024 it includes INP in place of the retired FID.

Two things are misunderstood more often than anything else here.

First: it is the 75th percentile, not the average. A metric passes when three quarters of real visits over a rolling 28-day window fall inside the threshold. One slow visit does not spoil the picture; a consistently slow quarter of your audience does.

Second: ranking uses field data, not lab data. Field data is CrUX — aggregated measurements from real Chrome users. Lab data is Lighthouse — a simulation on an emulated device. The PageSpeed Insights score everyone chases is lab data.

That is why the only report worth starting from is Core Web Vitals in Search Console: same field data, grouped by page type.

Why speed still shows up in search results

The direct ranking effect is small. But speed has three indirect channels, and they are stronger.

1. User behaviour. If a page does not render within a couple of seconds on mobile, some people go back to the results and open a competitor. Google does not have to treat that as a behavioural signal for the outcome to be the same: the competitor got the visit, you did not.
2. Conversion. A sluggish form or product page kills enquiries regardless of position. That is a separate job — I cover it under conversion rate optimization — but it often starts on the technical side. Speed is only one block in the wider list of what technical SEO optimization covers, and far from the first by priority.
3. Crawling. Google states that slow server responses cause Googlebot to back off. For a 150-page service site that is irrelevant. For a shop with 40,000 URLs, a slow server means part of the catalogue simply gets recrawled less often — and sometimes that is the whole answer to why Google is not indexing your pages.

If someone promises you ranking growth "through speed optimization", treat it as a red flag. You fix speed because it costs you users and money, not because it will move you up five positions.

What I see on my own projects

Most of my income comes from my own sites in competitive financial niches, so I have tested this on my own money: moving LCP from red to green has never on its own produced a ranking jump for me. What it consistently produced was fewer mobile bounces and more predictable analytics.

The reverse is also true and far more painful. When a site drops into the red — usually after a new plugin, a support chat widget or one more tracking pixel — the damage shows up quickly in both traffic and enquiries. Breaking speed is much easier than improving it.

An honest limit: I have no data on genuinely large projects with hundreds of thousands of URLs, where the crawl-budget argument becomes the main one. Everything above applies to service sites, smaller shops and content projects — the typical Estonian small business.

One more observation specific to this market: on multilingual Estonian sites I far more often find a structure problem than a speed problem — broken hreflang, duplicates across language versions, blurred intent. Against that, arguing about tenths of a second is not the priority. I wrote separately about which language to target for SEO in Estonia.

What to fix first

The order matters — cheapest to most expensive.

1. Images. A modern format (WebP or AVIF), real dimensions instead of huge originals, width and height in the markup to stop layout shifts, lazy loading for everything below the fold. On sites where nobody has touched this, it is usually the main LCP problem.
2. Third-party scripts. Chat widgets, review badges, three analytics systems, heatmaps, ad platform pixels. Open the Network tab and see what loads besides your own site. Usually half can go with no loss and the rest can be deferred.
3. Server response time. A slow TTFB is not cured by front-end optimization. Caching, a decent hosting plan and a CDN are what help. The move itself is nothing to fear: changing hosting does not hurt SEO when the migration is done properly.
4. Fonts. font-display: swap plus preloading the primary weight removes the long blank page and part of the layout shift.
5. Only then, code. Bundle splitting, removing unused CSS, tuning hydration. This is the most expensive part and on a typical site it returns the least per hour spent. If you are down here, the conversation is usually about rebuilding the site rather than patching it.

How to tell whether you have a problem at all

Step by step, about fifteen minutes:

1. Open the Core Web Vitals report in Search Console and switch to the mobile tab — it is almost always worse than desktop.
2. See whether any URL groups sit in the red or amber zone and which page types landed there. Often it is one specific page category, not the whole site.
3. Take one typical URL from the failing group and run it through PageSpeed Insights. Ignore the score; read the field data block at the top and the diagnostics list.
4. If there is no field data, you do not have enough traffic for a CrUX sample. Speed is not your current problem — go work on content.
5. Re-measure no sooner than 28 days after your fixes: field data updates on a rolling window and will not react immediately.

For an example of what actually moves the needle, see the Estonian furniture e-commerce SEO case: the growth came from structure and category work, with the technical side as a precondition rather than the cause.