Does Site Speed Actually Affect Rankings and Revenue? What the Evidence Supports

Two numbers get quoted in almost every article written to justify a performance project. One second of delay costs 7% of conversions. Fifty-three percent of mobile users abandon a page that takes more than three seconds. They appear so often, usually with no source attached, that most people assume they're settled facts.

Both trace back to real documents. One is a vendor research report from 2008. The other is a Google study from 2016 built on a self-selected sample. Neither says quite what people think it says, and neither is current. Meanwhile Google's own documentation on whether speed affects rankings is clearer and more specific than the SEO industry's summary of it, and it changed in a way most articles never caught up with.

This is what's actually documented, what's genuinely uncertain, and how to make a defensible case for performance work without leaning on statistics you can't source.

TL;DR

• Google's documentation states plainly that "Core Web Vitals are used by our ranking systems," but also that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Relevance wins; speed differentiates between comparably relevant results.
• In April 2023 Google removed "page experience system," "page speed system," "mobile-friendly system," and "secure site system" from its list of named ranking systems. Google's position is these were always signals feeding core systems, never systems in their own right.
• Google has never published a numeric weight for Core Web Vitals relative to content relevance. Any article giving you a percentage invented it.
• The "1 second = 7% fewer conversions" figure comes from an Aberdeen Group report published in December 2008. It is real, but it is seventeen years old, predates mobile, and its methodology was never made public.
• The "53% abandon after 3 seconds" figure is genuinely Google's, from a September 2016 study, but it's based on roughly 3,700 sites that opted into sharing benchmark data and describes likelihood of abandonment, not an observed rate.
• The strongest evidence is the case-study set Google publishes on web.dev, which documents specific companies, specific metric improvements, and specific business outcomes.

What Google Actually Says About Speed and Rankings

Google's page experience documentation is worth reading directly, because the summarised version circulating in SEO content is consistently more dramatic than the original.

The two sentences that matter most sit close together. First: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Second: "Core Web Vitals are used by our ranking systems."

Both are true simultaneously, and holding them together is the whole answer. A slow page with the best available answer will still rank. A fast page with a mediocre answer will not outrank it on speed. What speed does is documented in Google's own framing of the case where it matters: "for many queries, there is lots of helpful content available. Having a great page experience can contribute to success in Search, in such cases."

That's the honest shape of it. Where several pages are comparably useful, page experience can differentiate. Where they aren't, it doesn't rescue the weaker one.

Google adds one more limit worth knowing: "Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results." So the broader bundle of page-experience factors people used to optimise for is not, per Google, an independent ranking lever. Core Web Vitals are the part that feeds ranking systems.

The Framing Change Most Articles Missed

In April 2023, Google removed several entries from its published list of ranking systems: the page experience system, the mobile-friendly system, the page speed system, and the secure site system. This caused a brief round of "Google says speed no longer matters" headlines, which was wrong.

Google's Search Liaison explained it at the time: "This just meant these weren't ranking systems but instead signals used by other systems," adding that "taking them off didn't mean we no longer consider aspects of page experience."

The current ranking systems documentation confirms this. There is no standalone "page experience system" listed among Google's named systems. Core Web Vitals are signals folded into core ranking, not a separate mechanism.

The practical consequence: any content still describing "the page experience ranking system" or "the Core Web Vitals update" as a distinct algorithm is working from a pre-2023 mental model.

The Weight Question

People want a number. How much do Core Web Vitals count for, relative to content?

Google has never published one. Not a percentage, not a rank, not a tier. Any article that gives you a figure like "Core Web Vitals account for roughly 10% of ranking" made it up or repeated someone who did. Google's own framing is explicitly non-quantified: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience."

Is the PageSpeed Insights Score a Ranking Factor?

This one deserves care, because the widely repeated answer is correct but the widely cited justification isn't.

PageSpeed Insights blends two data sources: lab data from Lighthouse, which is a synthetic test run in a controlled environment, and field data from the Chrome UX Report, which reflects real page loads by real users. Google's documentation on Core Web Vitals consistently ties them to real-world user experience, which points to field data as what feeds ranking.

What I could not find is a sentence where Google explicitly says "the PageSpeed Insights score is not a ranking factor." The conclusion follows from the documented lab-versus-field distinction, but it's an inference rather than a quote, and it's worth stating as such rather than pretending Google said it outright.

The practical takeaway is unaffected: chase your field data, not your Lighthouse score. A 100 score on a synthetic test and failing Core Web Vitals in the field is an entirely possible combination, and it's the field data that reflects what users experienced.

The Thresholds That Actually Define Pass or Fail

If speed is going to be a signal, it helps to know exactly where the lines sit. Google's documented Core Web Vitals thresholds:

The rule that trips people up is the 75th percentile. Google's documentation states: "To classify the overall performance of a page or site, we use the 75th percentile value of all page views to that page or site," and a site passes when "at least 75 percent of page views to a site meet the 'good' threshold."

Two consequences follow. Your average load time is the wrong number to look at; a fast median with a slow tail can still fail. And a page that feels quick on your office connection tells you nothing about the quarter of your traffic on worse hardware and networks.

The Revenue Evidence That Actually Holds Up

Here's where the case for performance work gets stronger than the folklore statistics suggest, because Google publishes a set of documented case studies on web.dev pairing specific metric improvements with specific business outcomes. A selection:

These are more useful than the generic statistics for two reasons. They name the company, and they name which metric moved. That means you can look at your own site, identify which metric is actually failing, and find a comparable case rather than citing an averaged-out industry figure.

The obvious caveat: these are companies that improved performance and reported results, so there is selection bias baked in. Nobody publishes a case study titled "we improved LCP by 40% and nothing happened." Read them as evidence that performance work can produce these outcomes, not that it reliably will on any given site.

The Two Statistics You Should Stop Citing Unqualified

"A one-second delay costs 7% of conversions"

Source: Aberdeen Group, December 10, 2008. The original language: "every additional second of the delay in the response times could cause a decline in page views by 11%, conversations [sic] by 7% and overall customer satisfaction by 16%."

It's a real, findable, dated, named source. It is not fabricated. But it is a vendor research report from 2008, which is before the modern mobile web, before Core Web Vitals existed, and before most of the frontend architecture any current site uses. Its full methodology was never published beyond the press release.

It is also frequently misattributed to Google, which it is not.

If you want to use it, attribute it properly: "a 2008 Aberdeen Group study found..." That framing is honest, and it lets your reader weigh the age themselves. What you shouldn't do is present it as a current, universal figure.

"53% of mobile users abandon a page that takes over 3 seconds"

Source: Google, "The Need for Mobile Speed," published September 2016. This one genuinely is Google's, so the common attribution is correct.

The methodology, stated in the report itself: "Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016."

Three things worth knowing before you quote it. The data is from March 2016, which predates Core Web Vitals and INP entirely. The sample is self-selected, roughly 3,700 sites that opted into benchmark sharing, not a representative sample of the web. And the finding is phrased as likelihood of abandonment from a probabilistic model, not a directly observed abandonment rate.

It's fine to cite with those caveats attached. It's misleading to present it as a current fact about all mobile users.

How to Make the Case Honestly

If you're trying to justify performance work to a client or a manager, the strongest argument isn't a borrowed statistic. It's your own data plus Google's documented position.

Start with your own field data. Search Console's Core Web Vitals report and the Chrome UX Report tell you which of your URLs are failing and on which metric. "Thirty-eight percent of our mobile page views fail LCP" is a stronger opening than any industry average.

Use Google's actual framing on rankings. Core Web Vitals are used by ranking systems; relevance still wins; page experience differentiates among comparably relevant results. That's defensible, accurate, and enough to justify not being the slowest option in a competitive set.

Cite a case study that matches your failing metric. If your problem is LCP, the Vodafone or Lazada figures are directly relevant. If it's CLS, AliExpress and iCook are closer. Specific beats general.

Be honest about the causal gap. Performance improvements and business improvements correlate in the published studies, and the mechanism is plausible, but a site that redesigns for speed usually changes other things too. Overclaiming a precise revenue figure sets you up to be wrong.

Then measure your own before-and-after. The only evidence that fully applies to your site is evidence from your site. Field data takes weeks to update after a fix, so plan for that lag rather than declaring victory on a Lighthouse score the same afternoon.

Frequently Asked Questions

Is site speed a Google ranking factor? Core Web Vitals are used by Google's ranking systems, per Google's own documentation. But Google also states it "always seeks to show the most relevant content, even if the page experience is sub-par." Speed contributes where content quality is comparable; it doesn't outrank relevance.

How much do Core Web Vitals count toward rankings? Google has never published a numeric weight, and any specific percentage you find is unsourced. Google's framing is explicitly non-quantified: no single signal, a variety of signals feeding core ranking systems.

Did Google remove page experience as a ranking factor in 2023? No. Google removed several named "systems" from its ranking systems list in April 2023, including page experience and page speed, but explained these were always signals used by other systems rather than standalone systems. Core Web Vitals remain in use.

Does the PageSpeed Insights score affect rankings? The score is a synthetic lab measurement. Google's Core Web Vitals documentation consistently refers to real-world user experience, which points to field data as what matters for ranking. Note that Google doesn't state this in exactly those words, so treat it as a well-supported inference rather than a direct quote, and prioritise field data over the lab score either way.

What are the current Core Web Vitals thresholds? LCP good at or under 2,500 ms and poor above 4,000 ms; INP good at or under 200 ms and poor above 500 ms; CLS good at or under 0.1 and poor above 0.25. Assessment uses the 75th percentile of page views, so at least 75% must hit "good."

Is the "1 second delay equals 7% fewer conversions" statistic real? It traces to an Aberdeen Group report from December 2008. It's a real source but seventeen years old, with methodology that was never fully published, and it's often misattributed to Google. Cite it with attribution and date, or don't cite it.

Does faster hosting improve SEO? Indirectly, by improving server response time, which feeds into LCP, which is a Core Web Vital used by ranking systems. There's no direct "better host equals better rankings" mechanism, and hosting only addresses the server-side portion of your performance.

How long after fixing performance issues will rankings change? Field data in the Chrome UX Report is based on a rolling window, so improvements take weeks to fully reflect. Any ranking effect would follow that, and would be modest relative to content and relevance factors. Expect slow, partial signal, not a step change.

Conclusion

The defensible version of the case for site speed is narrower than the marketing version and more useful. Google documents that Core Web Vitals feed its ranking systems while stating clearly that relevance comes first. It publishes real thresholds and real case studies. It has never published a weighting, and the two revenue statistics everyone quotes are a 2008 vendor report and a 2016 study on a self-selected sample.

None of that means speed doesn't matter. It means the honest argument is about not being the slowest credible option in your competitive set, about the documented cases where specific metric improvements produced specific business outcomes, and about your own field data rather than someone else's average. That argument holds up when someone checks your sources, which is more than can be said for the version built on the two famous numbers.