Page Load Speed Leak Calculator

Turn slow load times into the sales you are quietly losing.

s
s
%
$
%
Studies cluster around 5–7% per second.
Seconds recovered
2.5s
Current − target
Projected conversion
2.94%
from 2.50%
Extra conversions / mo
350
From the speed gain
Revenue recovered / mo
$42,000
$504,000/yr

Cutting load time from 4.5s to 2.0s could recover about $42,000/month, $504,000 a year. That's the revenue case to hand engineering for a Core Web Vitals sprint.

The per-second penalty is an industry average, it's steepest on mobile and for the first few seconds. Validate against your own analytics by load-time cohort.

About this calculator

Every extra second of load time is a small tax on conversion, well-documented but rarely translated into a number engineering leadership will act on. This calculator turns the gap between your current and target load time into a monthly revenue figure, using an assumed per-second conversion penalty, so a Core Web Vitals sprint has a business case attached, not just a Lighthouse score.

How to use it

  1. Enter monthly visitors and your current conversion rate for the page or flow you're assessing.
  2. Enter current load time and a realistic target load time, the gap between them is what gets modeled.
  3. Enter the value of one conversion and a conversion-loss-per-second rate (7% is a commonly cited industry average, adjust if you have your own data).
  4. Read seconds recovered, projected conversion rate, extra conversions per month, and the monthly and annual revenue that recovers.

Methodology

Seconds recovered is simply current load time minus target load time, floored at zero.

The uplift factor is 1 + (penalty per second ÷ 100) × seconds recovered, applied multiplicatively to your current conversion rate to get a projected new rate.

Extra conversions per month is visitors × (new conversion rate − current conversion rate). Monthly revenue recovered is extra conversions × value per conversion, and the annual figure is simply ×12.

The per-second penalty is a blended industry figure, not measured from your traffic, and it isn't linear in reality: the first couple of seconds after a slow load tend to cost more than the marginal second on an already-fast page. Treat this as a planning estimate to justify the work, then validate the actual lift against your own analytics once the fix ships.

FAQ

Where does the 5-7% per-second figure come from?

It's a widely cited range from aggregated e-commerce and SaaS studies on page-speed impact, not a universal law. Penalties are steeper on mobile and on the first few seconds of load; a site already under 2 seconds won't see the same marginal gain per second as one crawling past 5 seconds.

Should I use load time for the whole page or a specific metric like LCP?

Largest Contentful Paint is usually the best proxy since it's closest to when a visitor perceives the page as usable, and it's what Core Web Vitals and Google's ranking signals track. Time-to-interactive matters more for pages with heavy above-the-fold interactivity.

How do I validate this estimate once we ship the speed fix?

Segment your analytics by load-time cohort before and after the change, and compare conversion rate for visitors who experienced fast vs. slow loads in the same period. That gives you an actual, not modeled, per-second relationship for your traffic.