Page-Speed Revenue Impact Calculator
Speed is conversion you can buy once and keep forever. Enter your current and target load times, your conversion rate, traffic and order value — and see the revenue a faster site is worth.
Faster pages convert better. This tool multiplies the seconds you save by a per-second conversion sensitivity (a documented rule of thumb you can change), applies that to your conversion rate, and projects the change in conversions and revenue. The output is a planning estimate to validate with an A/B test — real elasticity varies by audience, device and how slow your starting point is.
Page-Speed Revenue Impact Calculator inputs and result
| Measure | Current | Projected |
|---|
How to use this calculator
- Measure your current loadUse a consistent metric — Largest Contentful Paint or fully-loaded time — from PageSpeed Insights, CrUX or your real-user monitoring. Enter it as your current load.
- Set a realistic targetEnter the load time you expect after optimisation. A jump from 4.0s to 2.5s is ambitious but common; be honest, because the model scales linearly with the seconds saved.
- Enter conversion, traffic and AOVAdd your current conversion rate, the monthly sessions affected, and your average order value or value per lead.
- Set the sensitivity you believeThe default per-second sensitivity is a published rule of thumb. If you have run a speed test, enter your measured number instead — that is always better than a benchmark.
- Read the projection, then test itUse the revenue delta to justify the engineering work, then validate it with a real before/after or A/B test. Export the result to share the business case.
RGM Expert Says
Engineering teams ask for speed budgets; finance teams fund revenue cases. This tool exists to translate one into the other. We use it to turn ‘LCP is 4 seconds’ — which means nothing to a CFO — into ‘here is the projected monthly revenue we are leaving on the table’, which gets the work prioritised. The number is a hypothesis, but a hypothesis with a dollar sign moves roadmaps.
We are deliberate about the sensitivity input because the famous studies are not laws. Deloitte and Google’s ‘Milliseconds Make Millions’ work found roughly a tenth of a second of improvement lifted retail conversion by around eight percent — but that was measured on already-fast mobile sites, and elasticity is steepest when you start slow and flattens once you are quick. We set the default conservatively and tell clients to replace it with their own tested number the moment they have one.
The pattern that wins budget is pairing this with the Core Web Vitals score and the funnel drop-off analyzer. The vitals check says what is slow, this tool says what it costs, and the funnel analyzer shows where the lost conversions were leaking. Three views of the same problem, framed so the business funds the fix instead of debating whether speed matters.
How it works
The model is intentionally transparent. It converts the seconds you save into a relative change in conversion rate using a sensitivity you control, applies that to your current CVR, and then re-prices conversions and revenue against your traffic and order value.
- Seconds saved — current minus target load time; positive means faster.
- Sensitivity — relative CVR change per second, as a percent of your CVR.
- Sessions & AOV — volume affected and revenue per conversion.
Default sensitivity reflects retail findings in Deloitte & Google’s Milliseconds Make Millions and Google’s web.dev speed case studies. Elasticity is non-linear — treat the output as a hypothesis to A/B test, not a guarantee.
Why a second of load is a revenue lever
Speed is one of the few growth levers that helps every visitor on every page at once, with no recurring media cost. A faster site lifts conversion across paid, organic and direct traffic simultaneously, which is why a one-time engineering investment often beats another quarter of bid tuning on return.
The relationship is real but non-linear. Going from 6 seconds to 4 buys far more conversion than going from 2 seconds to 1, because most of the damage happens while users are still deciding whether to wait. That is why we let you set the sensitivity: a slow site has more to gain per second than a fast one.
Beware over-claiming. The headline statistics — Deloitte and Google’s ‘Milliseconds Make Millions’ finding that a 0.1s improvement lifted retail conversion meaningfully — come from specific samples and should anchor your estimate, not replace your own test. The honest use of this tool is to size the prize, then prove it.
Published speed-to-conversion findings
Use these to sanity-check your sensitivity input. They are directional — each was measured on a specific sample and context.
| Source / study | Finding |
|---|---|
| Deloitte & Google — Milliseconds Make Millions | A 0.1s improvement in mobile load lifted retail conversions by ~8% |
| Google / web.dev case studies | Sites repeatedly report double-digit conversion gains from major speed work |
| Rule-of-thumb default here | ~7% relative CVR change per second saved — calibrate with your own test |
What practitioners say about speed
Performance is conversion you only pay for once; the slowest page in the funnel is usually the cheapest fix nobody has prioritised.
Treat a speed win like any other experiment — size the expected lift, ship it, and measure the real number against the model.