Page Speed vs. SEO: What the Data Actually Shows

Page speed has been a Google ranking factor since 2010, and Core Web Vitals joined the Page Experience signals in 2021. But the relationship between raw speed numbers and ranking positions is often misunderstood — and the misunderstanding leads teams to optimise the wrong things. Here's what the data actually shows.

Speed as a threshold signal, not a gradient

The most important thing to understand about speed as a ranking factor: Google applies it as a threshold-based signal, not a linear gradient. There's no evidence that a site loading in 0.8 seconds ranks better than one loading in 1.2 seconds, if both are well within the "Good" threshold. The ranking impact is concentrated at the threshold crossings: Poor → Needs Improvement, and Needs Improvement → Good.

This has direct implications for prioritisation. If your LCP is already 1.9 seconds (comfortably "Good"), investing engineering time to push it to 1.2 seconds will likely yield zero ranking improvement. That effort is better spent elsewhere — fixing pages that are still in "Poor" or "Needs Improvement" territory, or addressing structural issues like canonicals or schema.

What CrUX data reveals about competitive landscapes

One underused insight from the Chrome User Experience Report: it's public data, covering most sites with enough traffic. You can look up your competitors' Core Web Vitals scores and compare them to yours. If your competitors all have "Good" LCP and you have "Needs Improvement", that's a direct ranking disadvantage in a threshold-signal world. If you're all "Good", it's a neutral factor and your ranking differences come from elsewhere.

The mobile vs. desktop gap

Google indexes and ranks the mobile version of your site. A performance problem that only shows up on mobile — which is most of them, since mobile devices are slower and on worse connections — is a real ranking problem, even if your desktop score looks great. This is why lab tests on a desktop browser in a London office don't tell you much about your actual ranking signal.

The CrUX API segments field data by device. Pull your mobile LCP, mobile INP, and mobile CLS separately from your desktop numbers. The mobile numbers are what Google uses for ranking decisions under mobile-first indexing.

The hidden cost of third-party scripts

The single biggest pattern in sites failing Core Web Vitals isn't hosting quality or image size — it's third-party script load. Analytics platforms, heatmap tools, chatbots, A/B testing frameworks, affiliate trackers, and consent management platforms each add their own main-thread weight. The cumulative effect on INP especially is significant.

• →Audit your third-party scripts with Google Tag Manager's preview mode or the Network panel in DevTools
• →Every third-party script should have a documented business reason for being on your site
• →Load non-critical scripts asynchronously and defer them past the first interaction window
• →Consent management platforms (CMPs) are a common INP killer — test yours specifically under load
• →Consider a script observability tool that tracks main-thread time per third party across real user sessions

Speed and conversions: the stronger case

Here's the honest truth: for sites already in the "Good" range for Core Web Vitals, the conversion and UX case for further speed investment is often stronger than the ranking case. The data on speed-to-conversion is more consistent than the data on speed-to-ranking beyond threshold crossings. A 100ms improvement in response time has documented effects on bounce rate and checkout completion. It has unclear effects on ranking if you're already in the "Good" bucket.

Frame your speed work accordingly: threshold crossings are ranking work, measured against GSC data. Sub-threshold speed improvements are product work, measured against conversion and engagement metrics. Both matter, but they require different success criteria.