The 7% figure comes from a 2008 survey of 160 executives. Here is what has actually been measured, and where your site sits against sixteen million others.
Nobody has measured what a slow website costs your company, and the number everyone quotes came from a questionnaire. The claim is that one extra second of load time cuts conversions by 7%. Its source is a November 2008 analyst report, and that report describes its own method without embarrassment: “Aberdeen examined the use, the experiences, and the intentions of more than 160 enterprises… Responding executives completed an online survey.” No site was timed. No delay was introduced. No conversion was counted. The report was also, by its own appendix, sponsored: “Solution providers recognized as sponsors were solicited after the fact.”
There is real evidence on this question. It is narrower than the folklore, and its numbers are smaller. Both facts are useful if you are deciding what to spend on a rebuild, and they are the frame we use when scoping a B2B site against the job it has to do rather than against a speed promise.
Where a company your size actually sits
The largest public measurement of web performance covers 16,213,084 websites, using field data collected from real Chrome users in June 2025. In that dataset, 48% of mobile sites and 56% of desktop sites pass all three Core Web Vitals. Four years earlier those figures were 32% and 41%.
The interesting number is not the average. It is the shape of the distribution by popularity, which is not a straight line. On mobile:
51% of the thousand most popular sites pass
42% of the next ten thousand
37% of the next hundred thousand
42% of the next million
The worst-performing band on the entire web is the middle. The report’s own explanation: “Mid-popularity sites may combine higher complexity such as additional features and third-party scripts with less sustained focus on performance, leading to drop in results.”
That band is where a serious mid-sized company lives. You have accumulated the tag manager, the chat widget, the analytics, the consent tool and the personalization script that a small site never installed, without the dedicated performance engineer that a top-thousand site employs. The very smallest sites beat you because they never had the chance to get complicated.
One more split worth knowing: home pages perform worse than the pages behind them. 47% of desktop home pages pass, against 61% of secondary pages. The page you spend the most on is the page carrying the most weight.
Mobile responsiveness is at 77% and layout stability at 81%. Loading is at 62%, with “nearly double the rate of ‘poor’ experiences (13% versus 7%)” compared to desktop. A site failing the Core Web Vitals is, almost always, failing on how long it takes to paint the main thing.
And the main thing is usually a picture: an image is the largest element on 85.3% of desktop pages and 76% of mobile pages. Which means the LCP work is image work, not framework work, on three quarters of the web.
One audit result puts the whole thing in perspective. The Lighthouse check for render-blocking resources is passed by 13% of desktop pages and 15% of mobile pages. Eighty-five percent of the web still blocks its own first paint.
Two measurements from the same source, the same year, pointing opposite ways.
In the field, interactivity improved. In the lab, it got dramatically worse: median mobile Total Blocking Time “increased to 1,916 milliseconds in 2025, up 58% from 1,209 milliseconds in 2024.” Desktop rose from 67 to 92 milliseconds. The report names the tension directly: “This presents an apparent contradiction: while field-based INP scores improved, lab-based TBT worsened significantly.”
Its explanation is the single most useful sentence in the whole dataset: “Real-world devices have become more powerful, masking increased code complexity that lab tests reveal using consistent emulated devices.”
The web is not getting lighter. Phones are getting faster faster than pages are getting heavier. Your field metrics improve while your code gets worse, and you find out which one was real when a customer opens the site on a four-year-old Android.
The weight numbers support that reading. The median mobile home page went from 845 KB in July 2015 to 2,362 KB in July 2025, a 202.8% increase over the decade, and grew 8.4% in the last year alone.
The four sources everyone cites, and what each one is
A one-second delay costs 7% of conversions. Source: an analyst report, November 2008, 26 pages. Its own appendix states the method: an online survey completed by executives at more than 160 enterprises, with vendors “solicited after the fact” as sponsors. The famous 7% is a bar in a chart titled “The Average Impact of a One Second Delay in Response Times on Key Business Metrics”, derived from asking executives what benefits they believed they had derived from performance management initiatives. The report also says business performance “begins to suffer at 5.1 seconds of delay”, and it is about enterprise web applications, some of them internal tools for employees, not retail sites.
A 0.1 second improvement raises retail transactions by 8.4%. Source: a 2020 consulting report, and its disclaimer is more informative than its headline:
“The purpose of this report is to communicate the findings of a study which examined the correlation between mobile site speed and mobile site user behaviours. Site speed fluctuations were natural and not artificially controlled or induced by any party.”
It was “commissioned by Google”, the data were collected by a third party “recruited directly by Google”, and the auditors “did not audit nor validate this data”. The window was four weeks, from 28 October to 24 November 2019, across 37 brand sites. And then this, in the appendix:
“In some instances, the increase in speed was observed to have minimal or zero effect on funnel progression and/or the KPIs for the vertical. These observations were not included in the report.”
The cases where speed did nothing were removed before publication. That is written down, in the report, by its authors. Two further limitations they state themselves: the results “may not fully reflect the Internet as a whole”, and desktop was excluded because the team “found a lot of contradicting parameters”. Speed was measured with a simulated lab tool, so the speed being correlated was never the speed those users experienced.
100 milliseconds costs Amazon 1% of sales. Source: a blog post from 9 November 2006, recounting a conference talk. The sentence is: “In A/B tests, we tried delaying the page in increments of 100 milliseconds and found that even very small delays would result in substantial and costly drops in revenue.” These were real A/B tests, so the claim is causal in principle. There is no publication, no figure, no sample size, no protocol. The author left the company in 2002, so the tests date from the era before smartphones.
100 milliseconds is worth 7% of conversions. Source: a 2017 press release from a CDN vendor, analyzing its own retail customers’ traffic with no control group. The full report is no longer accessible.
There is one randomized, controlled, peer-reviewed experiment on this question, and it was run on a search engine.
“We recently ran a slowdown experiment where we slowed 10% of users by 100msec (milliseconds) and another 10% by 250msec for two weeks. The results showed that performance absolutely matters a lot today: every 100msec improves revenue by 0.6%.”
The same authors published the arithmetic a year later, explicitly to correct the inflated figures in circulation: “a 250msec delay at the server impacts revenue at about 1.5% and clickthrough-rate by 0.25%. While this is a massive impact, 500msec would impact revenue about 3% not 20%.”
Three qualifications from the same authors that rarely travel with the number.
Not all latency counts. They report a null result plainly: delaying elements in the right-hand pane by 250 milliseconds produced no measurable effect, “despite the experiment size of almost 20 million users.” Slowing down what the user is not looking at is invisible. “The site is faster” is not a variable; the delay before the thing being read appears is.
The result does not transfer. One of their published rules of thumb is titled “Your Mileage WILL Vary”, and on latency specifically they warn that a slowdown result “quantifies the impact on the metric of interest at the point today” and will change if the site or the audience changes.
At least one company measured nothing. A 200-millisecond delay at an online marketplace produced no detectable effect. The authors mention it, offer insufficient statistical power as the likely explanation, and then concede: “It is possible that for Etsy users, performance is not critical.”
The closest thing to a demonstration on an ordinary company’s sales is a published split test on a telecoms landing page: half the traffic to an optimized version, half to the baseline, “no functional or visual differences between the two versions”, around 34,000 visits a day per arm. The optimized version had a 31% better field LCP and 8% more sales. One advertiser, one country, one paid-acquisition landing page, published by an interested party, with no confidence intervals. It is an honest A/B test. It is not a study.
Stop budgeting against a benchmark that does not exist. No published number tells you what a second costs your company. If a proposal opens with 7%, it opens with a 2008 questionnaire.
Fix the loading, not the framework. On mobile, 77% of the web passes interactivity and 62% passes loading. An image is the largest element on three quarters of pages. That is where the work is, and it is unglamorous work: dimensions, formats, sizes, preload hints, and getting the render-blocking resources out of the way, an audit that 85% of pages still fail.
Assume your field metrics flatter you. Lab blocking time rose 58% in a year while field interactivity improved. The gap is your customers’ hardware absorbing your code. It will not absorb the next increment.
Treat the middle-of-the-pack finding as a warning, not a comfort. Your band of the web performs worst because it has accumulated complexity without accumulating maintenance. Every tag, widget and script you added since the last redesign is in that number.
Measure the effect yourself if it matters enough to argue about. The only defensible number for your site comes from your site: change one thing, split the traffic, and count. That is what every credible result in this article did, and it is why there are only three of them.
Frequently asked questions
Is it true that one second of delay costs 7% of conversions?
There is no measurement behind that figure. It comes from a November 2008 analyst report whose own methodology section says executives at more than 160 enterprises completed an online survey, sponsored by vendors. No site was timed and no delay was introduced.
What has actually been measured?
One randomized experiment published in a peer-reviewed venue, on a search engine: slowing users by 100 and 250 milliseconds produced about 0.6% of revenue per 100 milliseconds. The authors explicitly caution that the result is not transferable, and that half a second costs about 3%, not 20%.
Where does a mid-sized company sit against everyone else?
In the worst part of the distribution. On mobile, 51% of the top thousand sites pass all three metrics, but only 37% of the sites ranked between ten thousand and a hundred thousand. Complexity has arrived; sustained performance work has not.
Which metric should I actually chase?
Loading. On mobile, 77% of sites pass interactivity and 81% pass layout stability, but only 62% pass largest contentful paint. A site that fails the Core Web Vitals almost always fails on loading.
Is the web getting slower or faster?
Field scores improved and lab scores got worse in the same year. Median mobile total blocking time rose 58% in twelve months. The most plausible reading is that phones got faster more quickly than pages got heavier.