Site Speed Is Not SEO and You Should Stop Chasing a Perfect Lighthouse Score

A client called me in a panic last winter because his rankings had slipped and his developer had spent six weeks getting every page to a 98 in PageSpeed Insights. Green Lighthouse scores, fast load times in the lab, a performance report that glowed. The rankings kept sliding anyway. He wanted to know what else he could shave off the page load time. The honest answer was nothing, because site speed was never the problem. He had spent six weeks polishing the one part of his site that Google treats as a tiebreaker and left the part that actually decides rankings, relevance, completely alone. I watch some version of this play out every few months, and it almost always starts with the same belief: that site speed is SEO. It is not. Site speed is a small input into SEO, and the perfect score people chase is measuring the wrong thing.

What site speed actually measures

Site speed is how fast the content on a page loads and becomes usable for a real user. The important thing to understand is that it is not one number, and it is not quite the same as page speed, though people use the two terms loosely. A page can look fast on one metric and slow on another, and a single site speed score papers over that difference.

The important thing to understand is that it is not one number, and it is not quite the same as page speed, though people use the two terms loosely.

The site speed metrics that matter

Time to First Byte (TTFB) measures how long your server takes to respond before anything loads. First Contentful Paint marks when the first content appears. Largest Contentful Paint marks when the main content finishes loading, and it is the load metric Google watches most closely. Page weight, server response time, image sizes, the number of HTTP requests, and render-blocking CSS and JavaScript all feed those numbers. When most people say site speed, they mean the single blended page load time a tool reports, or worse, the 0 to 100 performance score on the dial. Performance tools roll every metric into that one friendly figure, which is why two pages with the same score can serve very different real load times to users on slower mobile devices. The important habit is to read the underlying metrics, not the headline score.

Is site speed a ranking factor for SEO

Yes, site speed is a Google ranking factor, but a small one. Site speed acts as a tiebreaker between pages of similar relevance, where a faster site speed can edge out a slower one. Site speed does not rescue weak or irrelevant content.

How much does site speed affect SEO

That answer is close to the actual mechanism in the patent, not just my opinion. Google's patent on using resource load times in ranking, granted in 2014 and dissected by Bill Slawski, describes adjusting a page's relevance score based on load time so that, between two resources of similar relevance, the faster one can win. Speed is the adjustment, not the score. Google first announced site speed as a ranking signal in 2010 and framed it around the user, not as a reward for fast sites. When the mobile Speed Update shipped in 2018, Google said plainly it would only affect the slowest sites. John Mueller has been blunter since, saying Core Web Vitals are not giant factors in ranking and that once a site is reasonably fast, more tuning will not change much. So yes, site speed affects SEO, and a slow site can lose search visibility. For SEO, site speed is one input among many. No, a faster site speed will not lift a page that does not deserve to rank on relevance.

Why your Lighthouse score is lying to you

Here is the part that costs people the most time and the most money. The Lighthouse score in PageSpeed Insights, the 0 to 100 number everyone screenshots, is lab data. It is a single simulated load on a fixed device with a throttled connection. Google does not rank on that score. Read that twice, because it inverts how most teams use the tool.

Field data is the site speed Google measures

For the page experience signal, Google uses field data from the Chrome User Experience Report, the real Core Web Vitals collected from actual Chrome users on their own phones and networks over a rolling 28-day window. A perfect 100 Lighthouse score in the lab and a failing grade in the field are completely compatible, and I have pulled exactly that mismatch out of the field data more than once. One client had a 96 performance score in PageSpeed Insights and was failing Largest Contentful Paint for three quarters of his mobile users, because the lab tested a fast desktop and his real audience was on mid-range mobile devices over cellular. The lab score said win. The field data, the data that actually feeds ranking, said lose. Check the field data for mobile and desktop separately, because your mobile users almost always get the slower experience and mobile is what Google indexes. PageSpeed Insights shows you both, and almost nobody scrolls past the lab score to read the field data underneath it. The lab score is for diagnosing what is slow. The field data tells you whether your Core Web Vitals actually pass, and that is the half that decides rankings. I use the score to find the fix and the field data to confirm it reached real users. Smaller sites have the opposite problem, no field data at all, because they lack the traffic for the Chrome User Experience Report to publish a reading, which means for those pages site speed is barely a factor Google can even measure.

Core web vitals and the page experience signal

Core Web Vitals are the three field metrics Google watches: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. The three metrics are Google's shorthand for real user experience, how fast the page feels and how steady it stays while it loads. They sit inside a broader idea Google calls page experience, and the status of that idea matters more than most people realize. In April 2023 Google removed page experience from its list of ranking systems and clarified it was never a system at all, just a signal that other systems read. A system orders pages. A signal is one input among many that those systems consider. That quiet demotion is the clearest statement Google has made about how much weight site speed carries, and it lines up with what I have written about Core Web Vitals as a tiebreaker. The metrics are real and worth passing. Their job inside the ranking is small.

What actually affects your site speed

If you do want to fix a genuinely slow site, it helps to know what drags page load time down. Most of the weight comes from a handful of repeat offenders, and the same ones show up on almost every slow site I audit.

Server response time and hosting

Server response time is where I start, because a slow server makes every other optimization cosmetic. A server that takes two seconds to send the first byte has already lost the race before the browser downloads a single image. Cheap shared hosting and a distant hosting location both add seconds, since content that has to travel farther arrives slower. I have seen a bad host add a full second to the first byte on every request, and no amount of image work or caching claws that second back. TTFB, your time to first byte, is the metric to watch here, and a fast server is the cheapest big win in site speed because it speeds up every page at once.

Images, files, and page weight

After the server, page weight is the problem, and images are usually the heaviest thing on the page. Oversized images, uncompressed files, and the wrong file format inflate page size fast. Most slow pages I audit carry two or three megabytes of images and a stack of unused files the browser still has to download. Audit your image sizes first, because trimming a few large image files often does more for real load time than any other single fix, then lazy-load the images below the fold so the browser only loads what the user can actually see. The goal is the smallest files that still look right, not the smallest file size a tool can report.

Render-blocking CSS and JavaScript

Then there are the render-blocking resources. Bloated CSS and JavaScript files, too many HTTP requests, and third-party scripts that load before your content all hold up the first paint. The browser has to download, parse, and render the HTML, the CSS, and the JavaScript before the user sees anything on the page. Every extra file is another HTTP request. A page firing eighty requests feels slow on mobile no matter how small each file is. When I pull a request waterfall on a slow site, the same culprits show up every time: unoptimized images, a heavy theme loading dozens of files, a slow server, and a pile of analytics and chat widgets nobody audits. Trim the CSS, defer the JavaScript that is not needed for the first paint, and your render metrics improve right away.

How to improve site speed without chasing a perfect score

The fixes are well understood, and none of them are exotic.

Compression, caching, and a CDN

Compress and resize your images and serve modern formats. Minify your CSS and JavaScript and delete the files you do not use. Turn on browser caching so the second page load skips the download entirely, add server-side caching so the server is not rebuilding the page every time, enable compression so files arrive smaller, and put a content delivery network in front of your static assets. A CDN moves your files closer to the user, which cuts load time for distant visitors without your touching the code. Image optimization and caching together fix most slow sites, and they are the highest-impact performance work you can do. A CDN plus solid caching covers most of it.

Improve server response time first

Improve server response time before you touch anything cosmetic, because it gates everything downstream. That whole list will move a slow site into the green for real users, which is the entire point. What it will not do is justify chasing a 100. The gap between a 92 and a 99 in the lab is almost always invisible to your users and invisible to your rankings, and the engineering hours it costs are hours not spent on the content and the links that actually move you. I have watched a team burn a month dragging a performance score from 90 to 98 and gain nothing in search, then fix one genuinely broken page with an eight-second load time and watch it climb. Fix slow. Do not chase perfect.

When site speed actually moves SEO rankings

Site speed moves rankings in exactly one direction. A genuinely slow site, the kind that makes mobile users bail, can be held back, and the user data backs that up. Google's research found the probability of a bounce climbs 32 percent as page load time goes from one to three seconds and 90 percent from one to five seconds, and that 53 percent of mobile visits are abandoned past three seconds. That is a real business problem and a real ranking risk on the slow end. The asymmetry is the whole point, and it is the thing most SEO advice gets backwards. Slow can hurt you. Fast does not boost you. Once you clear the bar, the next gains come from relevance, not milliseconds, and relevance is decided by systems like the ones that parse what your page actually means, not by your load time. So measure your real users, watch the field data the same way you would content decay signals in Search Console, and fix site speed only when it is genuinely broken. Then spend the rest of your budget where rankings are actually won. If you want the full picture of where speed fits in a technical program, my Nashville SEO playbook lays it out, and a real technical SEO audit will tell you whether site speed is even your problem. Most of the time, it is not.

Figure 132 percent

Figure 290 percent

Figure 353 percent

By Michael McDougald