A good page load time is a Largest Contentful Paint of 2.5 seconds or less for at least 75% of page loads, measured separately for mobile and desktop visitors. That is the threshold Google publishes on web.dev, and Google says its ranking systems use Core Web Vitals. In every study below, faster pages did better than slower ones, but the evidence is thinner and older than most articles on this topic suggest.

“Load time” is also not one number. Time to first byte, first paint and Largest Contentful Paint are different measurements, and the studies below use different ones (Portent’s does not say which). Treat figures from different studies as rough evidence, not as interchangeable thresholds.

What Google counts as a good load time

Google rates each metric as good, needs improvement or poor, and judges a page by the 75th percentile of real visits. A page passes Core Web Vitals when LCP, INP and CLS are all good.

MetricGoodPoorWhat it measures
LCP2.5 s or lessover 4.0 sCore Web Vital. Render time of the largest image, text block or video visible on screen
INP200 ms or lessover 500 msCore Web Vital. Latency of clicks, taps and key presses across a visit; the longest interaction counts
CLS0.1 or lessover 0.25Core Web Vital. How much visible content shifts unexpectedly
TTFB0.8 s or lessover 1.8 sNot a Core Web Vital. Time until the first byte of the HTML arrives; it is the first part of LCP

INP replaced First Input Delay as a Core Web Vital on March 12, 2024.

How real websites perform today

The best recent snapshot is the performance chapter of HTTP Archive’s Web Almanac 2025, built on Chrome UX Report data from July 2025 and published on January 15, 2026. It reports the share of websites rated good:

Share of websites rated goodMobileDesktop
All three Core Web Vitals48%56%
LCP62%74%
INP77%97%
CLS81%72%
TTFB44%55%

Year-over-year changes were small. The all-three-good share rose from 44% to 48% on mobile and from 55% to 56% on desktop. Mobile INP rose from 74% to 77%, and TTFB from 42% to 44% on mobile and from 54% to 55% on desktop.

Loading, not responsiveness, is where mobile sites fall short. On mobile, 25% of websites have an LCP that needs improvement and 13% have a poor one (desktop: 18% and 7%), so 38% of mobile sites do not have a good LCP. TTFB is the first slice of LCP, so a slow server response leaves less of the 2.5-second budget for everything else. INP is good on most sites since it replaced First Input Delay, although the switch lowered pass rates when it happened: the Web Almanac 2024 put the share of mobile sites with good Core Web Vitals at 43% with INP, against 48% had First Input Delay still been the measure.

What this data leaves out. The Chrome UX Report only includes publicly discoverable pages above an undisclosed traffic threshold, and only opted-in Chrome users on desktop and Android (not Chrome on iOS). Small sites and iOS visitors are missing from these figures, which is one reason to collect your own field data.

What the research says about load time and behavior

These are the studies behind most of the numbers in circulation, with the year, the sample and the kind of evidence. “Observational” means the study compared sites or visits that were already fast or slow, so other differences between them may explain part of the result.

  • Google Analytics benchmark data, March 2016 (published in February 2017). 53% of mobile site visits left a page that took longer than three seconds to load. Sample: 3,700 mobile sites that had opted in to share benchmark data. Observational.
  • Google/SOASTA, 2017. A neural network with 90% prediction accuracy estimated that, compared with a 1-second load, the probability that a mobile visitor bounces is 32% higher at 3 seconds, 90% higher at 5, 106% higher at 6 and 123% higher at 10. Model estimate.
  • Google Search, 2009. Adding 100 to 400 ms of server delay to search results cut searches per user by 0.2% to 0.6%. Users given a 400 ms delay for six weeks still searched 0.21% less in the five weeks after it was removed. Experiment.
  • Akamai, April 2017. One month of data from top online retailers (about 10 billion visits): a 100 ms delay can hurt conversion rates by 7%, and a two-second delay raised bounce rates by 103%. Observational.
  • Portent, April 2022. 30 days, 20 sites (14 B2B lead generation, 6 e-commerce), just over 100 million page views. B2B conversion was almost 40% at 1 second, 34% at 2 and 29% at 3. E-commerce conversion was 3.05% at 1 second. A 1-second page converted 3x better than a 5-second page for B2B and 2.5x better for e-commerce. Observational.
  • Deloitte for Google, March 2020. 37 European and US brand sites, over 30 million mobile sessions, about a month in late 2019 (web.dev summary). A 0.1-second improvement in four speed metrics on every page of the journey went with 8.4% higher retail conversion (average order value up 9.2%) and 10.1% higher travel conversion (average order value up 1.9%). Observational.
  • Chrome team, May 2020. Analysis of millions of page impressions: when a site met the Core Web Vitals thresholds of that time, users were 24% less likely to abandon a page load before any content was painted (22% for news sites, 24% for shopping sites). Observational.

What these studies can and cannot tell you. In every study above, the faster group did better on the outcome measured. They do not agree on how much, and the percentages are not comparable: Google’s model is relative to a 1-second baseline, Akamai’s 7% is for 100 ms, and Deloitte’s figures are for a 0.1-second improvement across four metrics. Only one study in this list, Google’s 2009 test, assigned delays to users. None shows a cliff at a particular second: Portent’s B2B conversion falls gradually from almost 40% to 29% between 1 and 3 seconds, and Google’s model rises quickly to 5 seconds and slowly after that (32%, 90%, 106%, 123%), not exponentially.

Case studies from individual sites

Companies that measured their own changes give the most direct evidence for a single site. They are published by the companies or by Google’s web.dev team, which means they are successes. Treat them as examples of what is possible, not as typical results.

  • Rakuten 24: a one-month A/B test on a landing page, with 50% of traffic on a version optimized for Core Web Vitals and 50% on the original, and no other functional or visual differences. Revenue per visitor rose 53.37%, conversion rate 33.13% and average order value 15.20%, and exit rate fell 35.12% (case study last updated August 2022).
  • Vodafone Italy: an A/B test with about 100,000 clicks and 34,000 visits per day on each side (March 2021). A 31% LCP improvement came with 8% more sales, a 15% better lead-to-visit rate and an 11% better cart-to-visit rate.
  • QuintoAndar: mobile INP in real-user data fell from 1,006 ms to 216 ms over most of 2024, and conversions (prospects scheduling a property visit) rose 36% year over year. web.dev says the increase was strongly but not solely linked to better engagement. It was a year-over-year comparison, not an A/B test (January 2025).
  • Renault: a regression across more than 10 million visits in 33 countries (December 2020 to March 2021) estimated that a 1-second LCP improvement “can lead to” a 14 percentage point lower bounce rate and 13% higher conversion. It is a statistical relationship, not a test Renault ran.

Old numbers you will still see quoted

  • “53% of users leave after 3 seconds.” Google Analytics data from March 2016, covering mobile visits to 3,700 sites that had opted in to share benchmark data. It is not a 2026 measurement, not about desktop and not about “users” in general. Google’s February 2017 article carries the figure; the version Google hosts today (updated February 2018) does not.
  • “Amazon loses 1% of sales for every 100 ms.” The earliest account we found is Greg Linden’s November 2006 blog post, which says Amazon’s A/B tests that delayed pages in 100-millisecond increments found “substantial and costly drops in revenue”. It gives no percentage, sample or method, and we found none behind the 1% version. Annual dollar figures made by multiplying 1% by Amazon’s sales are arithmetic, not measurements.
  • “7% fewer conversions per second.” Akamai’s 2017 figure is for a 100-millisecond delay among online retailers, not a full second and not every industry.
  • “Attention spans are 8 seconds.” See the next section.

The psychology of waiting

Research on waiting is older than the web and was mostly done on queues and desktop software, not on web pages. Three findings are worth knowing, with their limits.

  • Response-time limits. Nielsen Norman Group, from Jakob Nielsen’s 1993 book and citing Miller (1968) and Card et al. (1991): about 0.1 second feels instantaneous, about 1 second keeps the user’s flow of thought uninterrupted even though the delay is noticed, and about 10 seconds is the limit for keeping attention on the task. These describe interactive systems in general, not page loads specifically.
  • Waits feel longer when they are empty, uncertain or unexplained. David Maister’s 1985 essay The Psychology of Waiting Lines lists observations from service queues: occupied time feels shorter than unoccupied time, waits before service starts feel longer than waits during it, and uncertain or unexplained waits feel longer than known or explained ones. He offered them as hypotheses to test, not as experimental results. For a page, the practical reading is to show something early and to show progress on long operations. Nielsen Norman Group advises a looped indicator for waits of 2 to 10 seconds and a percent-done indicator for waits of 10 seconds or more. That is design guidance, with no conversion figure attached.
  • Small delays change behavior. In Google’s 2009 experiments (above), delays of a few hundred milliseconds reduced searches, and users who had a 400 ms delay still searched less, on average, during the five weeks after it was removed. The study measured behavior, not why people changed it.

The 8-second attention span is a myth. The figure appears in a 2015 Microsoft Canada report, which credited another source, Statistic Brain. The BBC’s More or Less programme (March 2017) could not trace it to any research. The attention researchers it spoke to said attention depends on the task, and the BBC concluded there is no evidence that human attention spans are shrinking. Design for the task and the context, not for a number of seconds.

What to do about it

  1. Start with field data. PageSpeed Insights reports real-user data from the Chrome UX Report (28-day window, 75th percentile, mobile and desktop) next to a Lighthouse lab run. It falls back to origin-level data, or shows none, when a page lacks enough traffic. If your site has no field data, collect your own.
  2. Fix the server response and the LCP element first. web.dev’s LCP guide suggests, as a guideline and not a rule, that a good LCP is roughly 40% TTFB, under 10% resource load delay, roughly 40% resource load time and under 10% render delay. It says never to lazy-load the LCP image and to set fetchpriority="high" on the image likely to be the LCP element. In the Web Almanac 2025, 17% of mobile pages with an LCP image did.
  3. Treat INP and CLS as regression checks. Most sites pass them on mobile (77% and 81%), so dig in when your own data shows a problem.
  4. Find your own threshold. The studies above come from other sites, and conversion rates differ more than tenfold between B2B lead generation (almost 40% at 1 second in Portent’s data) and e-commerce (3.05%). Segment your own conversions or bounces by LCP, separately on mobile and desktop, to see where your visitors drop off.
  5. Watch every release. Compare p75 LCP before and after each deploy, so a regression is caught the day it ships rather than in next month’s report.
  6. Keep ranking in proportion. Google says Core Web Vitals are used by its ranking systems, but good scores do not guarantee a top position, and Search will still show the most relevant content when the page experience is poor.

Tracking this with Site Qwality

Two Site Qwality features cover the numbers above, with limits worth knowing.

  • Page speed monitoring runs scheduled Lighthouse audits through the Google PageSpeed Insights API against the URL you choose, such as your checkout, and stores LCP, FCP, CLS, TTFB, Total Blocking Time, Speed Index and four Lighthouse category scores for trend charts. It audits the desktop profile only, does not record INP, and fails the monitor below a fixed Lighthouse performance score of 0.5.
  • Real user monitoring collects LCP, INP, CLS, FCP and TTFB from your visitors’ browsers, shows p75 by page and breaks results down by device, browser and country. That is where your mobile and desktop numbers come from. The Core Web Vitals page has the details.

Measure your own load times

Site Qwality has a free tier for every product, with no credit card.

Start free

Sources

Every link below was opened on October 17, 2026.