The True Cost of a Slow Website: What the Data Actually Shows

The old version of this post opened with "every second your website takes to load costs you money" and then produced a dollar figure: a business doing 10,000 dollars a month online could recover 1,200 to 2,700 dollars a month from a one-second speed improvement.

We made that up. Not the sentiment, the arithmetic. It was built by stacking three conversion statistics from different studies, different industries, and different decades, applying them multiplicatively to a hypothetical business, and printing the result as if it were a forecast. Nobody should do that, including us, and if a vendor hands you a number like it, ask which study, which year, and which sample.

Here is what the evidence actually supports, with sources, and here is what it does not.

What is genuinely documented

Google and Deloitte, "Milliseconds Make Millions" (2020). Deloitte instrumented mobile site data from 37 brands across retail, travel, luxury, and lead generation in Europe and the US over four weeks, and isolated speed against funnel outcomes. For a 0.1 second improvement in mobile site speed they observed:

• Retail conversions up 8.4 percent, average order value up 9.2 percent
• Travel conversions up 10.1 percent, average order value up 1.9 percent
• Luxury page views per session up 8.6 percent
• Lead generation bounce rate improved 8.3 percent

Read the caveats with the numbers. This is observational, not a randomized experiment. Speed was correlated with outcomes across large brands with real traffic volume. It is the best-sourced speed-to-revenue evidence in public, and it still does not license you to promise an individual small business a specific dollar recovery.

Google and SOASTA (2017). A machine-learning model built on real mobile e-commerce data found that the probability of a bounce increases by 32 percent as load time goes from 1 to 3 seconds, by 90 percent from 1 to 5 seconds, and by 123 percent from 1 to 10 seconds.

Note what that sentence says. It is a relative increase in the probability of a bounce, from a predictive model. It is not "you lose 90 percent of your visitors at five seconds," and the old version of this post came uncomfortably close to implying that.

Our own 292-site study. 191 of 292 sites returned a valid mobile verdict. The median mobile LCP was 10.5 seconds, and 165 of 191 were over 4 seconds. That is a lab measurement on a purposive B2B sample, so it does not give you the odds that your own site is slow. It does tell you that a ten-second mobile page is unremarkable in the wild, which is the part most business owners do not believe until they see their own trace.

What we deleted, and why

The following claims appeared in the previous version of this post and are now gone.

We are keeping the correction visible rather than silently editing, because the whole point of this post is that unsourced numbers are how the speed conversation got dishonest in the first place.

Speed and rankings, stated carefully

Google has confirmed that page experience, including Core Web Vitals, is used as a signal in ranking. Google has also said, repeatedly and in public, that it is a small signal and that relevance matters far more. A fast page about nothing does not outrank a slow page that answers the question.

The three current Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, measured on field data at the 75th percentile of real page loads. Lighthouse gives you a lab number on a single simulated load. First Contentful Paint is not a Core Web Vital. If a tool tells you that you "failed Core Web Vitals" based on one Lighthouse run, it is telling you something, but it is not telling you that.

So the ranking argument for speed is real and modest. The user argument for speed is the strong one. A ten-second blank screen on a phone loses people, and you do not need a ranking algorithm to explain why.

Diagnose before you spend

The most expensive mistake in this whole area is buying a fix for a problem you have not located. LCP is a composite of four delays, and every real fix belongs to exactly one of them:

1. Server response time. Hosting, redirects, cold starts, server-rendering work.
2. Resource load delay. The gap before the browser even discovers the LCP resource. A discovery problem, not a bytes problem.
3. Resource load duration. How long the file takes to download. This is the only phase image compression touches.
4. Render delay. Blocked rendering, hydration, and JavaScript animations that keep the element from painting after it has already arrived.

Chrome DevTools gives you this breakdown. Record a load with mobile throttling, click the LCP marker, read the phases. Google itself warns against assuming the answer is image compression, and we have seen sites where the hero was already small and the entire ten seconds lived in server time and a fade-in animation. Compressing that hero would have accomplished nothing.

Full walkthrough: how to fix LCP on mobile.

What we have not measured

We have never run a controlled before-and-after on a client site measuring revenue against a speed change. No holdout group, no randomization, no attribution model. Neither has any agency that has quoted you a dollar figure. If we ever do run one, we will publish it, including if it comes back flat.

What we do measure is the technical number, and we will tell you honestly when the technical number is bad and honestly when we do not know what it is worth to you.

Where to start

Run your own page through our free audit, or straight through Chrome DevTools, and get your LCP and your phase breakdown. Then check Google Search Console for the field Core Web Vitals of your real visitors, which is the only data that reflects the people actually trying to use your site.

If the numbers are bad and you want help, book a call. We will show you the trace before we quote you anything.