Site speed and SEO: what it changes, how to measure it honestly, and the fixes in order of payoff

Site speed affects your search results in two specific ways and your revenue in a much larger one. Google has used page speed as a ranking signal on desktop since 2010 and on mobile since 2018, and it now sits inside what Google calls page experience, where it helps decide close contests between comparably relevant pages. Separately, a slow or unreliable server reduces how much of your site Googlebot fetches. The biggest effect is commercial: fewer people abandon a fast page. Measure at the 75th percentile of real visits, by template and by device, then fix in this order: server response, images, render blocking files, third party scripts, fonts, JavaScript.

This page covers what speed does and does not change, how to run a test you can trust, and which fixes pay for themselves first.

What speed changes

• Close contests. Between two pages that answer the query about equally well, the better experience can win. Google's guidance on page experience is consistent on the order of priority: relevant, helpful content first, then the experience of reading it.
• How much of your site gets crawled. Google's documentation on managing crawl budget is explicit: when a site responds quickly the crawl limit rises, and when it slows down or returns server errors the limit falls. On a site with thousands of URLs that decides how fast new pages are discovered.
• Revenue per visit. This is where most of the money is. A faster page gets more of the people who arrived to the point of enquiring or buying, on every channel, not only search.

What speed does not do is substitute for the page being the best answer. A thin page that loads in 400 milliseconds still loses to a thorough page that loads in two seconds. If a page does not rank and the content is weaker than what ranks above it, speed work is not the fix. Diagnose the content first, then make it fast.

How to measure it honestly

Five rules, and they settle most arguments between a marketing team and an engineering team.

• Use real visits, at the 75th percentile. An average hides the slow quarter of your audience, and the slow quarter is who you are losing.
• Measure templates, not the homepage. Pick one URL each for the homepage, a category, a product or service page, a blog post and the checkout or enquiry form. Those five tell you where the problem is.
• Keep mobile and desktop separate. They usually have different causes and different fixes.
• Test under the same conditions each time. Same tool, same device setting, same throttling, logged out, with extensions off.
• Report one number per template per month, so a trend exists. A single test is a data point, not a measurement.

Tool	What it is good for
PageSpeed Insights	Both at once: real user data at the top, a Lighthouse run underneath with the specific files to fix
Chrome DevTools, Lighthouse and the performance panel	Diagnosis, before and after a change, with throttling you control
The Core Web Vitals report in Search Console	Which templates fail across the whole site, grouped
The Chrome User Experience Report	Field history, and your competitors' numbers on the same basis
A real user monitoring script	Your own field data, including pages with too little traffic to appear elsewhere

A site speed test that takes fifteen minutes

• Run your five template URLs through PageSpeed Insights on mobile and write down the field numbers.
• For each one, note the largest element on screen and how long it took to paint.
• Open the network panel on the slowest template and sort by size. The top three rows are usually the whole story.
• Count the third party scripts loading before first paint, and ask who reads the output of each.
• Check time to first byte. Google's reference on TTFB treats 800 milliseconds or less as good. Above that, the problem is the server or the cache, not the front end.

The fixes, in order of payoff

Fix	Why it is high on the list	Effort
Cache the page and put a CDN in front of it	Removes server work from the critical path for every visitor, every page	Low to medium
Fix the hero image	Modern format, sized for display, eager loaded with high priority, explicit dimensions. The single most common cause of a failing load metric	Low
Compress and resize every other image	Images are usually most of a page's weight	Low, and automatable
Remove render blocking CSS and JavaScript	Inline what the first screen needs, defer the rest, and the page paints before the rest arrives	Medium
Audit third party tags	Chat, consent, testing and analytics scripts often cost more than every image combined. Delete the unread ones and delay the rest	Low, and political
Fix fonts	Preload the one you use, subset it, set a size adjusted fallback, and stop loading five weights	Low
Reduce the JavaScript payload	Code split by route, drop unused libraries, and server render content people read first	High, and the most durable
Remove redirect chains and fix 404s in your own markup	Every extra hop is a round trip before anything renders	Low

Work down that list and stop when the templates pass. Most sites get the whole way there on the first five rows.

What to stop doing

• Chasing a perfect Lighthouse score. The thresholds that matter are the field ones, and the last few points usually cost more engineering time than they return.
• Minifying files while a 3MB photograph sits at the top of the page.
• Installing a speed plugin on top of an unfixed template, which adds another script to the queue.
• Judging the site on one homepage test. The homepage is rarely the page that earns your search traffic.
• Removing a feature that makes money to save 200 milliseconds. Make it load later instead.

This page covers how speed relates to search and how to prioritise the work. For the exact definitions and thresholds of LCP, INP and CLS, and how to read the Search Console report, see a dedicated Core Web Vitals guide.

Where people get stuck on site speed and SEO

Is site speed a Google ranking factor?

Yes, and a modest one. It has been a desktop signal since 2010 and a mobile signal since 2018, and it now sits inside page experience. It decides close contests and it influences how much of your site gets crawled. Content relevance remains the larger factor by a wide margin.

How fast is fast enough?

Use the Core Web Vitals thresholds as the target: largest contentful paint at 2.5 seconds or less, interaction to next paint at 200 milliseconds or less, layout shift at 0.1 or less, for three quarters of real mobile visits. Add a server target of 800 milliseconds or less to first byte.

My score is good on desktop and poor on mobile. Where do I start?

Start with mobile, because that is what the assessment is weighted toward and it is usually most of your traffic. The gap is normally JavaScript execution on a slower processor and images served at desktop dimensions.

Will speeding up the site recover traffic I lost?

It will recover revenue from the traffic you already have, which is the faster payback. If the traffic drop coincided with a content or ranking change rather than a performance change, diagnose that separately and fix both.

Does the hosting plan matter?

It matters for time to first byte, which sits in front of everything else. Caching and a CDN usually buy more than a bigger server, so try those first and upgrade the origin if the cache cannot cover your pages.

Speed does not buy a place in the answer

The test results here tell you how fast a page loads, and whether that matters for ranking, crawling or sales. They say nothing about the paragraph an assistant writes when a buyer asks for the best option in your category. A fast site can be left out of it, and a slow one can be named.

That number is its own measurement. Count how often you are named across ten buyer questions in ChatGPT, Gemini and Perplexity, and repeat monthly. AI Knows Us automates the counting.