Page speed conversion impact calculator

Every web performance deck repeats the same line: one second costs you 7% of conversions. Almost none of them shows the math, and none says what to do with the number afterwards. This page does both. It starts from a load time and ends in revenue, with an open and adjustable model, and it finishes where an estimate should always finish: at the sample size needed to turn the assumption into a measured fact.

If you already know which conversion lift to expect and only want to translate it into money, the right tool is a different one: the conversion rate impact calculator, which starts from a known rate change. This one solves the harder step before it: estimating which rate change to expect from a speed change.

How to use it

1. Fill in monthly traffic, current conversion rate and average value per conversion for the flow you want to speed up. Use one period and one family of pages.
2. Enter your current LCP. Take the field value, from Google's real user experience report or the real world data tab of PageSpeed Insights, not the lab number, which is usually more optimistic.
3. Set the target LCP, meaning where engineering can realistically land. With no technical estimate at hand, use 2.5 seconds, the edge of the good Core Web Vitals band.
4. Pick the elasticity. Moderate, at 7% per second, is the default reference. Use the conservative one to defend an investment in front of a sceptical finance team, and the aggressive one only as a ceiling scenario.
5. Read the output backwards: start at the test line. If the estimated lift needs more visitors than you have, the number is there to prioritise the task, never to promise a result to anyone.

How it works: the formula

The model is a constant elasticity per second, applied as compounding on top of the current rate:

Where e is the relative gain per second saved (0.07 on the moderate elasticity). Compounding, rather than a plain multiplication by seconds, is what keeps the math coherent in both directions: saving two seconds at 7% is 1.07 squared, and the way back undoes exactly the same gain, which the linear version fails to do. Two brakes keep the model honest: credit stops at 0.8 second, because below that there is no public evidence to support the extrapolation, and total lift is capped at 100%, because speed alone does not double any site's conversion rate.

Worked example (reproduces the default output)

With the values that come pre filled: 120,000 monthly visitors, a 2.2% rate, a $180 order value, LCP going from 4.2s to 2.5s and the moderate 7% per second elasticity. Credited seconds are 4.2 − 2.5 = 1.7, since both times sit above the floor. The multiplier is 1.07^1.7, that is e^{1.7 × ln 1.07} = e^0.11502 = 1.12190, a relative lift of 12.2%.

The estimated rate moves from 2.2% to 2.2 × 1.12190 = 2.47%, a difference of 0.27 percentage point. In volume, monthly conversions go from 120,000 × 0.022 = 2,640 to 2,962, meaning 322 extra conversions per month. Multiplied by the $180 order value, extra revenue is $57,925 per month and $695,097 per year.

The one second card uses a different and simpler calculation, independent of the target: current revenue for the flow is 2,640 × $180 = $475,200 per month, and 7% of that is $33,264 per month, or $399,168 per year. That is usually the number that ends the backlog priority argument, because it exists whether or not anyone approves a project: it is what slowness charges every month while the topic sits idle.

Finally, the test line. Detecting a 12.2% relative lift on a 2.2% baseline, at 95% confidence and 80% power, takes 49,759 visitors per variant. With 120,000 monthly visitors split into two groups, that is roughly 26 days. It is good news dressed as a technical detail: in this scenario the gain is big enough to be proven, not merely claimed.

The three models on the same scenario

The table below holds everything constant and swaps only the elasticity, to make visible how much the choice of model dominates the final answer.

From the most conservative to the most aggressive the answer multiplies by four on identical inputs. Hence a simple rule of use: always present the range, never a lone number. A business case that opens with the conservative figure and mentions the aggressive one as a ceiling survives the hard question in the meeting; one that opens with the aggressive figure loses all credibility the moment someone asks where it came from.

What each second is worth, at the moderate elasticity

Notice the effect compounds rather than scaling linearly: four seconds are not worth four times one second. That matters when slicing the project, because the first half of an optimisation is almost always cheaper than the second while both return a similar amount. Cutting 6s to 4s usually costs a tenth of the effort of cutting 3s to 2s, and delivers a bigger gain.

Why LCP and not total load time

The model asks for LCP because that metric sits closest to what a visitor perceives. Total load time includes things nobody is waiting for, such as tracking pixels and scripts that fire after the screen is usable, so it tends to overstate the problem. The official Core Web Vitals band is the ruler to use: up to 2.5 seconds is good, between 2.5 and 4 seconds needs improvement, and above 4 seconds is poor. The tool grades both your current time and your target on that same ruler, right below the result.

Always use field data collected from real visitors rather than lab data. The gap between them is often whole seconds, because the lab runs on a stable network, without extensions and without the tail of old devices your real audience carries. A business case built on lab numbers overstates how well you are doing and understates the size of the problem.

How to read it, and where this model misleads

The first limit is the important one: correlation is not causation. The studies behind any speed elasticity compare fast sites and sessions against slow ones, and a fast site tends to be one with a stronger engineering team, a more polished product and better qualified traffic. There is also a selection effect inside a single site, since slow sessions concentrate old devices, poor networks and lower income regions that would already convert less for other reasons. The purely causal effect of speed is smaller than the observed one, which is precisely why the conservative elasticity exists.

The second is that the response is not uniform across audiences. In high intent flows, such as a returning customer coming back to reorder, tolerance for slowness is far higher. In discovery and cold paid traffic it is lower: someone who arrived from an ad bails quickly because they had invested nothing in the visit. If your traffic skews to high intent, use the conservative elasticity.

The third is the average hiding the tail. An average LCP of 4.2 seconds can mean half your audience at 2 seconds and half at 6, and that second half carries almost all of the damage. Before estimating an average gain, look at the 75th percentile by device, which is exactly the cut Google uses. Very often the right project is not speeding up the whole site but fixing the worst segment, nearly always mobile on cellular. To size that difference, the mobile versus desktop conversion gap calculator is the natural companion to this page.

The fourth is the ceiling. Once LCP enters the good band, returns fall fast while engineering effort climbs. Going from 5s to 2.5s is usually the highest return project on the list; going from 2.0s to 1.5s rarely pays for itself, and it is where many strong teams burn a whole quarter for the pride of a score rather than for a result.

What to do with the number

• Use the estimate to prioritise, comparing the annual gain against the project cost and against everything else in the queue.
• Always present the range, from conservative to aggressive, and say which one you treat as the base case.
• If the test line shows a workable timeline, run the test and replace the estimate with real data. A measured gain beats a forecast gain in any future budget conversation.
• If the test does not fit your traffic, measure before and after carefully, comparing equivalent windows of week and channel mix, and state openly that the result carries seasonal contamination.
• Record LCP alongside the result of every test you run. Without it, a performance regression in the middle of an experiment becomes a permanent mystery.

FAQ

How much does page speed affect conversion?

The most quoted market reference is a 7% relative drop in conversion for every extra second of load time, a figure popularised by Akamai research. There are more conservative readings around 3% per second, and far more aggressive ones above 12% per second that come from observational curves such as Portent. This calculator lets you pick which one to use, because the gap between them changes the answer several times over, and pretending a single true number exists is the most common flaw in speed business cases.

What is LCP and why does the calculator use it?

LCP is Largest Contentful Paint, the Core Web Vitals metric that marks when the largest visible element of the page finishes rendering. It is the best available proxy for the moment a visitor feels the page has loaded, and it is the one Google publishes per URL in its real user experience report. That makes it more useful than total load time or a synthetic lab number: what changes behaviour is perceived time, not the instant the last script settled.

Is this conversion gain guaranteed?

No, and no speed impact calculator can promise otherwise. Public elasticities come from observational studies, where a fast site also tends to be a better run site with a better product, a better checkout and better traffic. Part of the measured effect belongs to those other causes. What the estimate gives you is an order of magnitude for prioritisation, which is exactly why this tool also shows how many visitors you would need to prove the same lift in a controlled test.

Why does the model stop counting below 0.8 second?

Because the public evidence runs out there. Almost every study compares buckets from 1 to 5 seconds or more, and extrapolating the same elasticity down to 300 milliseconds produces fantasy numbers. The 0.8 second floor is a deliberate brake: improving from 1.0s to 0.3s credits only 0.2s of gain in the model, and the tool warns you when part of the improvement fell under that floor. Real gains below one second do exist, they are just too small to estimate with market elasticities.

How do I prove a speed gain in an A/B test?

Split traffic between the current and the optimised version of the same page and measure conversion in both groups, exactly like any other test. The detail that kills most attempts is sample size: with the defaults on this page, the estimated 12.2% lift needs about 49,759 visitors per variant to be detected at 95% confidence and 80% power, roughly 26 days. If your own math lands in months, the estimated gain is too small for your traffic and the number is there to prioritise work, not to claim a result.

Should I optimise speed or the page itself?

Compare both on the same ruler, which is what this calculator makes possible. Speed usually returns single digit percentage gains and has a ceiling: once LCP is inside the good Core Web Vitals band, every extra tenth costs a lot and returns little. Offer, proof and clarity changes tend to have a higher ceiling but fail more often. The practical reading: pull the page out of the poor band first, because severe slowness poisons every test you run afterwards, and only then fight for percentage points in the content.

Keep going

If the next step is proving the gain, start with the sample size calculator and the test duration calculator. If the open question is where the funnel leaks before any technical work, use the funnel calculator. And for the full prioritisation context, the conversion rate optimization guide and the piece on CRO for low traffic sites show where speed belongs in the queue of things that move a rate.