The most repeated statistic in web performance comes from a blog post that does not contain it. A 2006 post by a former engineer describes internal tests finding that small delays produced substantial and costly drops in revenue. No percentage. No sample. No duration.

The specific figure everyone quotes first appears later that year as a bullet on a university lecture slide, with no method attached. It has been repeated for two decades since.

Real experiments do exist, they were run by search engines, and they found effects an order of magnitude smaller. This page traces each claim and gives the thresholds that are actually published.

The claim with no number in it

Worth reading the original, because the gap between it and its reputation is instructive.

What the 2006 post says, verbatim. That in A/B tests, they 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.

What it does not contain. A percentage. A sample size. A test duration. A revenue figure. Any quantification whatsoever.

Where the number appears. On a slide from a December 2006 university guest lecture by the same author, as a bullet reading roughly “+100ms → -1% sales”. No note of method, no sample, no citation of any internal study.

What that makes it. A recollection, converted into a precise statistic on a teaching slide, then cited as a finding for eighteen years.

Whether it is false. Nobody can say. The underlying tests may well have found exactly that. The company has never published them, so the claim is unverifiable rather than disproven.

How to use it. Stop citing it as a statistic. If you want to make the argument, cite the experiments below, which are weaker in magnitude and vastly stronger in evidence.

The retailer claim, which is real and observational

The second most cited figure is better sourced and still not what people think.

Where it comes from. A February 2012 presentation to a web performance meetup by three named members of a large retailer’s team.

What it reports, verbatim. That for every 1 second of improvement they experienced up to a 2% increase in conversions, and for every 100 ms of improvement they grew incremental revenue by up to 1%.

The two words people drop. Up to. Both figures are ceilings, not averages.

The method. Real user monitoring, meaning observation of natural traffic. Not a controlled experiment with injected delay.

The line that shows why that matters. The same presentation reports that converted shoppers received pages that loaded twice as fast as non-converted shoppers.

Why that sentence is not evidence of causation. People who convert differ from people who do not in many ways that also affect page speed: device, connection, whether they are logged in, whether assets were cached from an earlier visit, and which pages they reached. Faster pages for converters is exactly what you would see even if speed caused nothing.

Provenance of the two most cited website speed and revenue claimsComparison tracing the two most frequently cited claims linking website speed to revenue back to their original sources. The first claim, that one hundred milliseconds of additional latency costs one percent of sales at a large online retailer, traces to a blog post published in November two thousand and six by a former engineer at that company, which states verbatim that in A/B tests they tried delaying the page in increments of one hundred milliseconds and found that even very small delays would result in substantial and costly drops in revenue. That post contains no percentage, no sample size, no test duration and no revenue figure of any kind. The specific one percent figure first appears in December of the same year as a bullet point on a slide from a university guest lecture given by the same author, carrying no note of method, no sample and no citation to any internal study, which makes it a recollection converted into a precise statistic on a teaching slide and subsequently cited as a research finding for eighteen years. The claim is unverifiable rather than disproven, since the underlying tests may well have produced that result but were never published. The second claim, that each second of speed improvement yields a two percent conversion increase, traces to a February two thousand and twelve presentation to a web performance meetup by three named members of a large retailer’s team, and reports verbatim that for every one second of improvement they experienced up to a two percent increase in conversions and for every one hundred milliseconds of improvement they grew incremental revenue by up to one percent. Both figures are ceilings rather than averages, as indicated by the words up to, and the method was real user monitoring, meaning observation of naturally occurring traffic variation rather than controlled experimentation with injected delay.Two claims, traced to source”100ms costs 1% of sales”The 2006 source says, in full:“even very small delays would result in substantial and costly drops in revenue”No percentage. No sample. No duration. No revenue figure.The “1%” first appears on a December 2006 lecture slide, as a bullet, with no method.”1 second is worth 2% of conversions”A February 2012 meetup talk, three named presenters. Verbatim:“For every 1 second of improvement they experienced up to a 2% increase in conversions""Up to” is a ceiling. And the method is real user monitoring, not an experiment.Same talk: converted shoppers received pages loading twice as fast as non-converters.Which is exactly what you would see if speed caused nothing: converters differ in device, connection and caching.
One has no number in its source. The other has names and a date, and measures correlation on natural traffic. Source : Original blog post 2006, meetup report 2012 (2012)

The experiments nobody cites

Controlled tests exist. They are older, far more rigorous, and report much smaller effects, which is presumably why they lost the citation war.

The design. Server delay injected artificially, one group experiencing it, a second group serving as control. That is a genuine randomized comparison, not an observation of natural variation.

The published abstract, verbatim. That experiments demonstrate increasing web search latency 100 to 400 ms reduces the daily number of searches per user by 0.2% to 0.6%.

The table, in full. 50 ms of pre-header delay over four weeks: not significant. 100 ms: -0.20%. 200 ms post-header over six weeks: -0.29%. 400 ms: -0.59%. 200 ms post-ads over four weeks: -0.30%.

A companion result from a competing search engine. A two-second slowdown changed queries per user by -1.8% and revenue per user by -4.3%, presented at the same 2009 conference.

What these establish. That latency has a real, measurable, causal effect on behaviour, in the direction everyone assumes.

And the magnitude. 100 ms costs about a fifth of a percent of searches, not one percent of revenue. The famous figure is roughly five times the measured effect of the only comparable controlled test, on a different metric.

One limitation to state. The published study reports relative percentages without absolute user counts, and it measures searches rather than purchases. Search behaviour and checkout behaviour are not the same thing.

The consultancy study, and the word everyone misreads

The most cited recent study is real, large, and about one tenth of a second.

The sample. 37 brands across retail, travel, luxury and lead generation, in Europe and the US, with 30 million user sessions over four weeks.

The headline, verbatim. That a mere 0.1s change in load time can influence every step of the user journey, ultimately increasing conversion rates, with conversions growing 8% for retail sites and 10% for travel on average.

The misreading. People quote this as one second. It is one tenth of one second, which makes the reported effect far more impressive, not less. Quoting it as a second understates it.

The method, verbatim. That fluctuations in speed all occurred naturally and were not artificially created on any of the sites, analysed with a logarithmic regression model, with speed measured by an automated auditing tool and joined to each brand’s own analytics.

So it is observational. Natural speed variation, not assigned. Sites are faster and slower at different moments for reasons that may also affect conversion.

Who commissioned it. The final page states it: commissioned by the search company. The methodology section notes that the search company, the consultancy and an agency collectively approached over 70 brands to participate.

Its own stated limitations. That the results are based on a sample of 37 websites over four weeks and may not fully reflect the internet as a whole, and that it presents only mobile web data.

Measured effects of latency on user behaviour, separated by whether the delay was assigned or observedTable of measured effects of website latency on user behaviour, separated according to whether the delay was experimentally assigned or merely observed. In the assigned category, a two thousand and nine study injected server delay artificially with one group of users experiencing the delay and a second group serving as control, constituting a genuine randomized comparison. Its published results are that fifty milliseconds of pre-header delay over four weeks produced no significant effect; one hundred milliseconds produced a reduction of zero point two zero percent in daily searches per user; two hundred milliseconds of post-header delay over six weeks produced zero point two nine percent; four hundred milliseconds produced zero point five nine percent; and two hundred milliseconds of post-advertisement delay over four weeks produced zero point three zero percent. Its abstract states that increasing web search latency by one hundred to four hundred milliseconds reduces the daily number of searches per user by zero point two to zero point six percent. A companion result from a competing search engine presented at the same two thousand and nine conference found that a two second slowdown changed queries per user by minus one point eight percent and revenue per user by minus four point three percent. In the observed category, a consultancy study analysed thirty-seven brands across retail, travel, luxury and lead generation in Europe and the United States, covering thirty million user sessions over four weeks, and reports that a change of one tenth of one second in load time can influence every step of the user journey with conversions growing eight percent for retail and ten percent for travel on average; its method states that fluctuations in speed all occurred naturally and were not artificially created on any of the sites, analysed using a logarithmic regression model with speed measured by an automated auditing tool joined to each brand’s own analytics data.Assigned delay, against observed delayDelay injected, control group present: this is causal50 ms, pre-header, 4 weeksnot significant100 ms, pre-header, 4 weeks−0.20% searches per user per day200 ms, post-header, 6 weeks−0.29%400 ms, post-header, 6 weeks−0.59%2 seconds, competing engine−1.8% queries, −4.3% revenue per userSpeed varied naturally, nothing assigned: this is correlation0.1 second, 37 brands, 30M sessions+8% retail conversions, +10% travel”Fluctuations in speed all occurred naturally and were not artificially created on any of the sites.”The one controlled test says 100ms costs about a fifth of a percent of searchesThe folklore says one percent of revenue. Five times larger, on a metric nobody measured.
The controlled experiment found a fifth of a percent for 100ms. The folklore claims five times that, on a different metric. Source : Google 2009 delay experiment; Deloitte 2020 study (2020)

What Google now says about speed and ranking

The framing changed in 2023, and the change is more interesting than the usual summary of it.

What existed before. A published “page experience system” in the list of ranking systems, described as assessing criteria including how quickly pages load, mobile friendliness, absence of intrusive interstitials and secure serving. The same page noted that the 2018 speed update and the mobile-friendly system had been absorbed into it.

What happened. Between February and April 2023, the page experience system disappeared from the published list of ranking systems.

What Google said about it, verbatim. That it was not a separate ranking system, and that it did not combine all these signals into one single page experience signal.

What that does and does not mean. It does not mean speed stopped counting. It means the marketing wrapper around several individual signals was withdrawn, and Google clarified retrospectively that the wrapper never described a real mechanism.

The current position on weight, verbatim from 2020 and never withdrawn. That Google will prioritize pages with the best information overall, even if some aspects of page experience are subpar, that a good page experience does not override having great relevant content, but that in cases where there are multiple pages with similar content, page experience becomes much more important.

And the sentence that ends most agency arguments. That good stats in the Core Web Vitals report or in third-party tools do not guarantee good rankings.

The honest summary. Speed is a differentiator among comparable pages, not a substitute for being the right answer. Google has said exactly that, consistently, for six years.

The withdrawal of the page experience system from the published ranking systems listAccount of the withdrawal of the page experience system from the search platform’s published list of ranking systems and what the platform said about that withdrawal. Before the change, the ranking systems guide described a page experience system which assessed a variety of criteria such as how quickly pages load, mobile friendliness, whether pages lack intrusive interstitials and whether pages are served securely, stating that in situations where there are many possible matches with relatively equal relevance the system helps give preference to content with a better page experience; the same page recorded that the earlier speed update announced in two thousand and eighteen and the mobile-friendly system had both been absorbed into the page experience system. Between February and April two thousand and twenty-three the page experience system disappeared from the published list of ranking systems entirely, appearing neither among the active systems nor among the retired ones. A blog post published in April two thousand and twenty-three clarified the position, stating that it was not a separate ranking system and that it did not combine all these signals into one single page experience signal. The correct interpretation is not that speed ceased to count but that the marketing wrapper around several individual signals was withdrawn while the platform clarified retrospectively that the wrapper had never described an actual mechanism. The platform’s position on relative weight, stated in two thousand and twenty and never withdrawn, is that it will prioritize pages with the best information overall even where some aspects of page experience are subpar, that a good page experience does not override having great relevant content, but that where multiple pages have similar content page experience becomes much more important for visibility.What changed in 2023Before: a listed ranking system”a page experience system that assesses avariety of criteria, such as how quickly pagesload, mobile-friendliness…”The 2018 speed update had been absorbed into it.After: gone from the listDisappeared between February and April 2023.Not among active systems. Not amongretired ones either.The signals themselves stayed.Google’s own clarification, April 2023”It was not a separate ranking system, and it did not combine all these signals into one single signal.”And the weight statement, from 2020, never withdrawn”we will prioritize pages with the best information overall, even if some aspects of page experienceare subpar… However, in cases where there are multiple pages that have similar content, pageexperience becomes much more important for visibility in Search.”
The wrapper went. The signals stayed. Google's clarification was that the wrapper never described a real mechanism. Source : Google ranking systems guide, before and after; Search Central blog April 2023 (2023)

The thresholds that are actually published

Short, precise, and worth having in one place.

Largest contentful paint. Good at 2.5 seconds or less. Poor above 4.0 seconds.

Interaction to next paint. Good at 200 milliseconds or less. Poor above 500 milliseconds. It replaced first input delay on 12 March 2024.

Cumulative layout shift. Good at 0.1 or less. Poor above 0.25.

How all three are assessed. At the 75th percentile of page loads, segmented across mobile and desktop. The same numeric targets apply to both; the segmentation means the percentile is computed separately, not that the bar differs.

Time to first byte, which is not a Core Web Vital. The guidance is that most sites should strive for 0.8 seconds or less, with poor above 1.8 seconds, and states explicitly that because it is not a Core Web Vital it is not absolutely necessary to meet the good threshold, which is why those thresholds are described as a rough guide.

Page weight and request count. No official threshold exists for either. Auditing tools offer configurable budgets, which are a developer convention rather than a published standard.

Published performance thresholds and their assessment methodTable of the published website performance thresholds together with the method by which each is assessed. Largest contentful paint is rated good at two point five seconds or less and poor above four point zero seconds. Interaction to next paint is rated good at two hundred milliseconds or less and poor above five hundred milliseconds, and replaced first input delay as a core web vital on the twelfth of March two thousand and twenty-four. Cumulative layout shift is rated good at zero point one or less and poor above zero point two five. All three are assessed at the seventy-fifth percentile of page loads, segmented across mobile and desktop devices, with the same numeric targets applying to both device categories; the segmentation means that the percentile is computed separately for each population rather than that different thresholds apply. Time to first byte is not a core web vital, and its guidance states that most sites should strive for zero point eight seconds or less with poor values above one point eight seconds, while explicitly noting that because it is not a core web vitals metric it is not absolutely necessary for sites to meet the good threshold provided that doing so does not impede their ability to score well on the metrics that matter, which is the reason those thresholds are described as a rough guide. No official threshold exists for total page weight or for the number of network requests; automated auditing tools offer configurable performance budgets, but these constitute a developer convention rather than any published standard from the search platform.The thresholds, in one placeMetricGoodPoorCore Web Vital?Largest contentful paint2.5 s or lessabove 4.0 sYesInteraction to next paint200 ms or lessabove 500 msYes, since 12 Mar 2024Cumulative layout shift0.1 or lessabove 0.25YesTime to first byte0.8 s or lessabove 1.8 sNoPage weight, request countNo threshold publishedn/aAssessed at the 75th percentileSame targets for mobile and desktop, computed separately.And TTFB is optional, by its own docs”not absolutely necessary”; the thresholds are “a rough guide”.And: “good stats… don’t guarantee good rankings”. That is Google’s own sentence.
Three Core Web Vitals at the 75th percentile. Time to first byte is a rough guide, by its own documentation. Source : Google Search Central and web.dev (2026)

What to actually do about speed

Five things, in the order that returns the most for the least.

Fix the 75th percentile, not your laptop. Your machine on office broadband is not the measurement. Pull field data and look at the quarter of visits that are worst.

Find your largest contentful paint element and make it arrive first. On most B2B sites it is a hero image or a headline blocked by a webfont. That single element usually accounts for most of the gap.

Cut what blocks rendering. Third-party tags, chat widgets, consent scripts and analytics all load before your content on many sites. This is where marketing usually caused the problem and can usually fix it.

Treat layout shift as a correctness bug. It has no upside, it is usually caused by images without dimensions or late-injected banners, and it is the cheapest of the three to fix permanently.

Stop after the thresholds. Beyond the good thresholds, further speed work has no documented ranking benefit and the conversion evidence is observational. Spend the next hour on the offer instead.

And the sentence to bring to any argument about this. Good scores do not guarantee good rankings, and Google says so. Speed is a hygiene factor with a defined bar, not a growth strategy.

Five website speed actions ordered by return with a defined stopping pointDiagram presenting five website speed actions ordered by the return they generate relative to the effort required, together with an explicit stopping point. The first action is to address the seventy-fifth percentile rather than the developer’s own machine, since a modern computer on office broadband does not represent the measurement, and field data should be pulled to examine the quarter of visits that perform worst. The second action is to identify the largest contentful paint element and ensure it arrives first, since on most business-to-business websites that element is either a hero image or a headline blocked by a web font, and that single element usually accounts for the majority of the gap against the threshold. The third action is to remove what blocks rendering, since third-party tags, chat widgets, consent scripts and analytics frequently load before the page content, which is typically where the marketing function created the problem and can therefore also resolve it. The fourth action is to treat cumulative layout shift as a correctness defect rather than a performance optimisation, since it carries no upside whatsoever, is usually caused by images lacking declared dimensions or by banners injected after initial render, and is the least expensive of the three core metrics to fix permanently. The fifth instruction is to stop once the good thresholds are met, because beyond those thresholds no documented ranking benefit exists and the available conversion evidence is observational rather than experimental, so the next hour is better spent on the offer itself. The supporting argument for any internal discussion is the platform’s own statement that good scores in its reports do not guarantee good rankings, which establishes speed as a hygiene factor with a defined bar rather than as a growth strategy.Five actions, and where to stop1. Measure the 75th percentileYour laptop on office wifi is not the metric.2. Find your LCP elementUsually a hero image, or a font-blocked headline.3. Cut what blocks renderingTags, chat, consent, analytics. Marketing’s own doing.4. Treat layout shift as a bugNo upside, cheap to fix, usually missing dimensions.5. Then stopPast the good thresholds: no documented ranking benefit, and the conversion evidence is observational.The sentence to bring to the argument”good stats… don’t guarantee that your pages will rank at the top of Google Search results.”Speed is a hygiene factor with a defined bar. It is not a growth strategy.
Beyond the good thresholds there is no documented ranking benefit and the conversion evidence is observational. Source : Method, applied to the published thresholds (2026)

Where to go next

You want the search requirements themselves. Technical SEO: three requirements.

You are choosing a host. B2B website hosting and performance.

You are moving the site. Website migration without losing rankings.

You want to know what AI summaries are doing to clicks. AI Overviews and organic traffic.

You are rebuilding. Signs it is time for a B2B website redesign.

You want the conversion side of the page. Anatomy of a high-converting B2B landing page.

In short

  • The 100ms claim has no source. The 2006 post it comes from contains no percentage at all; the number first appears on a lecture slide with no method.
  • The 2% per second claim is real but observational, from a 2012 meetup talk, and both its figures are stated as “up to”.
  • The only controlled experiments are from 2009: 100 ms of injected delay cost 0.20% of daily searches per user, 400 ms cost 0.59%.
  • A competing engine found -4.3% revenue per user for a two-second slowdown, in the same year.
  • The big consultancy study is about 0.1 seconds, not 1 second, on 37 brands and 30 million sessions, with speed varying naturally.
  • It was commissioned by the search company, disclosed on its final page, and states it may not fully reflect the internet as a whole.
  • The page experience system was removed from the ranking systems list in 2023, with Google stating it was never a separate ranking system.
  • Good Core Web Vitals do not guarantee rankings. That is Google’s own wording, in current documentation.

Fix the 75th percentile to the published thresholds, then stop. Book a diagnostic, or see how we approach B2B websites.