Page Speed Revenue Impact Calculator

How the number is derived

The revenue impact of a speed change is sessions × the conversion change attributable to speed × average order value.

The commonly cited relationship is roughly a 7% conversion change per second of load time, though the real figure varies by baseline speed, device and category.

Impact = sessions × conversion rate × (speed elasticity × seconds improved) × AOV.

An example

A site loading in 4.2 seconds improved to 2.4, a 1.8 second gain. At a 7% conversion improvement per second, that is roughly 12.6%.

Conversion rises from 2.5% to 2.82%, producing 1,128 orders rather than 1,000, $7,424 of additional revenue and $4,083 of contribution monthly.

Annually that is $49,000 of contribution from a technical improvement that is largely one-off.

The relationship is steeper at slow speeds and flattens at fast ones, so a site already at 1.5 seconds will see far less from a further half-second than this calculation suggests.

The usual mistakes

The 7% figure comes from studies on specific large sites and is applied far more widely than the evidence supports. It is a reasonable planning assumption and not a law.

Speed also correlates with other quality signals, a fast site is usually a well-built one, so some of the observed relationship is not causal.

What this changes

Measure your own relationship where traffic allows, by comparing conversion across sessions grouped by load time. That is a direct observation rather than a borrowed coefficient.

Then prioritise mobile, where speeds are slower, connections are worse and the conversion gap against desktop is already largest.

Where the time actually goes

On most ecommerce sites the dominant causes are unoptimised images, third-party scripts and render-blocking resources, in roughly that order.

Third-party tags are the most common single cause of a site that was fast at launch and is slow now, because they accumulate without anyone owning the total. Auditing them and removing the ones nobody uses is frequently worth a second or more.

Image optimisation is the largest one-off gain on image-heavy stores and is largely automatable through modern formats and responsive sizing. Neither of those is a redesign, and between them they usually recover most of the available time at a fraction of the cost of rebuilding anything.

Core Web Vitals are worth tracking as field data rather than lab scores, since real users on real connections experience something quite different from a test run on a fast machine.

The field figures are also what search engines use, which makes the same work relevant to organic visibility as well as to conversion.

Setting a performance budget and enforcing it in the build process is what prevents the gradual accumulation that returns a fast site to a slow one within a year.

Server response time is worth measuring separately from front-end rendering, since a slow backend cannot be fixed by image optimisation and is frequently the larger share on dynamic pages.

Lazy loading below-the-fold images improves the metrics that matter to visitors without reducing what is eventually available, and it is usually a single implementation change.