The case in three numbers
Web performance is my day job. I own it across a marketing web at Universe, and before any budget conversation, somebody always asks the same fair question: what is site speed actually worth in dollars? There's a lot of junk math in circulation, so I hold the answer to three studies that were measured properly, with the caveats attached.
The biggest is the Milliseconds Make Millions study (opens in a new tab) that Deloitte ran with Google: 30 million user sessions across 37 brands, watching what happened when a site got faster by just 0.1 seconds. Retail conversions rose 8.4% and average order value rose 9.2%. Travel conversions rose 10.1%. They measured the same brands over time rather than comparing fast companies against slow ones, which kills the usual "rich companies have fast sites" objection.
The second number is the cleanest causal evidence in the field. Vodafone A/B tested two versions of the same landing page (opens in a new tab), identical except one loaded with a 31% better Largest Contentful Paint. The faster version sold 8% more, with a 15% better lead rate and an 11% better cart rate. Same page, same traffic, same offer. Speed was the only variable.
The third is interactivity rather than loading: redBus improved Interaction to Next Paint by 72% (opens in a new tab), mostly by cleaning up event handlers and cutting wasted re-renders, and sales rose about 7%. That one matters because it's the kind of unglamorous JavaScript work that never makes a redesign deck.
The bounce math nobody escapes
Conversion lift is the upside. Bounce is the tax you pay before anyone converts at all. Google's research with SOASTA modeled real mobile ecommerce sessions and charted how the probability of a bounce climbs with load time (opens in a new tab). The curve is steep and it starts immediately.
Source: Google/SOASTA mobile page speed research (opens in a new tab) · drafted July 2026, verify before publish
View this chart as a table
| Load time change | Bounce probability increase |
|---|---|
| 1s to 3s | +32% |
| 1s to 5s | +90% |
| 1s to 6s | +106% |
| 1s to 10s | +123% |
Read that against your own analytics. If a paid click costs you $4 and your landing page takes five seconds on a phone, the bounce curve says you're paying a meaningful surcharge on every dollar of ad spend before design, copy, or offer get a vote. Speed is the only line item in that funnel that gets cheaper to operate after you fix it once.
Why these metrics move revenue at all
None of these studies found magic. They found friction being removed. LCP is the moment the page looks usable; INP is whether it responds when someone touches it. When either one is slow, users don't file a bug report, they just quietly trust the site less, and a percentage of them leave. The revenue lift in every study above is that missing trust coming back.
The honest caveats belong in the pitch too, and I always include them. The Deloitte numbers are correlational, brand-by-brand over time, strong but not a controlled experiment. The Vodafone and redBus numbers are real tests but on their sites, not yours; a site that's already fast will see smaller gains than one that's slow. What the whole body of evidence supports is more modest and still very bankable: on a slow site, performance work is among the highest-probability revenue work you can buy. My working breakdown of the metrics themselves lives in the Core Web Vitals field guide, and the platform-specific fixes are in the WordPress speed checklist and the Shopify performance sheet.
What it costs against what it returns
Here's the buying math I'd want if I were the client. A focused performance pass on a marketing site, audit, fixes, and verification, is priced like a small project, not a rebuild; my ranges are in the website cost guide. Set that against the studies: if your site does $500,000 a year through the funnel and the work moves conversions a conservative 2%, not the 8% from the studies, it returns $10,000 a year, every year, against a one-time cost. The break-even case doesn't need the headline numbers to be true for you. It needs a fraction of them.
The discipline that makes the math honest is measuring. Before and after, field data, not a single lab run: Core Web Vitals from real users, conversion rate over a comparable window, bounce on the pages that were touched. When I run performance work at my day job, the dashboard exists before the first fix ships. If someone sells you speed work without a measurement plan, they're selling you the vitamin version.
How to buy performance work well
Ask three things of whoever does it. First, which metric they're targeting and why, because "make it faster" isn't a scope; "get LCP under 2.5 seconds on the money pages" is. Second, what the field data says today, because the baseline is the contract. Third, what stays fixed after they leave: a performance budget, an image pipeline, a check in the build. Speed that isn't defended regresses in about two quarters of normal feature work.
This is a solved problem with an unusually clear payback, which is rare in this business. If you want the numbers above translated into a plan for your site, with the baseline measured first and the results measured after, get in touch. Performance is the part of the craft where the spreadsheet finally agrees with the engineer.