How Page Speed Actually Affects Conversion Rate (With the Math)

The most-quoted statistic in web performance is that every 100 milliseconds of delay costs 1% of sales. It is repeated in pitch decks, tweeted at conferences and pasted into agency proposals, usually without a source. It deserves a closer look — not because it is wrong, but because knowing where it comes from tells you when it applies to your site and when it does not.

Where the numbers come from

The 100 ms figure traces back to an internal Amazon experiment from around 2006, described secondhand in a conference talk and never published. A far better source is Milliseconds Make Millions, a 2020 study by Google and Deloitte that measured real mobile sites across retail, travel, luxury and lead generation. Its headline findings: a 0.1-second improvement in load time increased retail conversion rates by 8.4% and average order value by 9.2%; travel conversions rose 10.1%; lead-generation forms saw an 8% lift in page views per session.

Two things about those numbers matter more than the numbers themselves. First, they are relative changes: a store converting at 2.0% moving to 2.17%, not 2.0% to 10.4%. Second, they were measured at the decision points — product pages, checkout steps, form pages — not averaged across a whole site. A blog post loading faster does not sell more; a product page loading faster does.

Why speed changes behaviour at all

It is tempting to think of speed as a hygiene factor — nice to have, but people who want the product will wait. The behavioural data says otherwise, for three reasons.

• Attention is the scarce input. On a phone, a visitor who is waiting is also being offered a notification, a message and the back button. Every 100 ms is another chance to lose them to something else.
• Speed is read as competence. People cannot see your code, so they judge your business by proxies. A site that stutters feels like a company that might not ship the order. That perception affects conversion even among visitors who did not leave.
• Delay compounds at decision points. A slow product image is an annoyance. A checkout button that does not respond for half a second after the tap is a reason to wonder whether the order went through — and to abandon rather than risk paying twice.

The three moments that decide it

"Load time" is too blunt to act on. The metrics that map onto behaviour are the ones Google chose for Core Web Vitals, and each corresponds to a moment in the visit.

1. When the main thing appears — Largest Contentful Paint

LCP is the time until the biggest element in the viewport — usually the hero or product image — has rendered. Under 2.5 seconds is "good". This is the moment a visitor decides whether the page is working. On product pages it is almost always the image, which means it is almost always fixable: correct dimensions, a modern format, and a high fetch priority.

2. When they tap something — Interaction to Next Paint

INP measures how long the page takes to visibly respond after a tap, click or key press, across the whole visit. Under 200 ms is good. This is the one that makes a fast-loading site feel slow, and it is usually caused by JavaScript — third-party tags, heavy frameworks, or handlers that do too much work before updating the screen. We wrote a separate guide to INP because it is the least understood of the three.

3. When the server has to think — Time to First Byte

Not a Core Web Vital itself, but it caps LCP: nothing can paint before the HTML arrives. Slow database queries, uncached pages and an overloaded shared host show up here. On checkout and search pages TTFB is often the whole story.

A worked example

Take a store with 20,000 monthly sessions, a 2.0% conversion rate and a $180 average order value. That is 400 orders and $72,000 a month. Its mobile product pages have an LCP of 4.2 seconds at the 75th percentile — squarely in Google's "poor" band — and an INP of 380 ms.

Extrapolating the Deloitte elasticity linearly across a 1.8-second improvement would be dishonest; the returns diminish as you approach "good". A conservative model uses three scenarios for moving product and checkout pages from "poor" to "good":

Even the conservative row pays for a serious optimisation project inside a quarter, before counting the second-order effects: lower cost per acquisition on paid traffic (ad platforms reward fast landing pages), better crawl coverage, and a lift in average order value that the Deloitte data suggests travels with speed.

The question is never "is speed worth it?" It is "what is a 15% relative lift on our decision pages worth, and what does it cost to get there?" Both halves are measurable.

How to measure it on your own site

You do not have to take an industry average on faith. Three steps give you your own elasticity.

1. Get your real numbers per page group. The Chrome UX Report (via PageSpeed Insights or the CrUX dashboard) and Search Console's Core Web Vitals report show LCP, INP and CLS for real visitors, grouped by template. Ignore lab scores for this exercise.
2. Send the same metrics into your analytics. The open-source web-vitals library can report each visitor's LCP and INP to GA4 as events. Register them as custom dimensions and you can segment conversion rate by speed bucket — visitors who saw LCP under 2 s versus over 4 s.
3. Correct for confounders before you believe it. Fast experiences correlate with newer phones and better connections, which correlate with income. The cleanest evidence is a before-and-after on the same pages, ideally with a small holdout group still served the old templates for two weeks.

Where speed does not help

Honesty about the limits keeps the business case credible. Speed will not rescue a page whose visitors had no intent to buy, an offer that is uncompetitive, or a checkout with a bug in the address validation. It amplifies an already-working funnel; it does not create one. If your conversion rate is 0.3% and your competitors' is 2%, look at the offer and the traffic source before you look at the image pipeline.

What to fix first

In roughly descending order of return per hour of effort, on the sites we audit:

• Hero and product images: correct dimensions, AVIF or WebP, fetchpriority="high" on the LCP image, lazy-loading on everything below the fold.
• Render-blocking CSS and fonts: inline the critical styles, defer the rest, subset and preload one font file.
• Third-party scripts: inventory every tag with its cost in milliseconds, then delete or defer. Chat widgets and heat-map tools are the usual offenders.
• Server response: page caching, object caching, HTTP/2 or 3 and, if you are on a crowded shared host, moving.
• JavaScript on the main thread: break long tasks, drop unused libraries, show visual feedback on tap before doing the work.

That list is also, in order, how we run a speed optimization engagement: audit the field data, rank the causes by gain and cost, fix them in that order, and verify the result in the same field data 28 days later. The maths above is what justifies it; the field data is what proves it.