Milliseconds are too small to notice and too expensive to ignore. Amazon proved that in an internal test in 2006.
Revenue dropped even at 100 milliseconds, a lag no visitor would consciously register.
Walmart got similar results six years later. A one-second improvement in load time raised conversions by 2%, the retailer reported at an industry conference.
Nordstrom saw the cost move the other way, with online sales falling 11% when the site slowed by half a second.
An added "dressing room" feature had brought enough load weight to trigger the drop.
Even the BBC, which has no cart to abandon and no sale to lose, sees the same pattern. Its own engineers estimate the outlet loses 10% of its users per extra second of load time.
None of these companies had a discovery problem. Visitors already found the page and started loading it. That covers lost sales after someone arrives.
But what happens to the pages that are too slow to ever get found in a search result?
The Three Metrics Google Measures
Fifty-three percent of all mobile visits are abandoned if a page takes longer than three seconds to load, based on Google's own analysis of over 10,000 mobile domains.
That finding is nearly a decade old, and the standard has only gotten harder to meet since. Fewer than half of mobile pages today pass all three of Google's Core Web Vitals metrics.
In fact, only 51.4% of mobile pages pass all three Core Web Vitals today, according to HTTP Archive's tracking of Google's own Chrome UX Report data.
Losing a sale on one slow visit is the first cost. Google's Page Experience update created a second cost. It ties search rankings directly to a set of metrics called Core Web Vitals.
Passing one of those metrics says nothing about the other two. A page can nail one and still fail the overall assessment.
- Largest Contentful Paint tracks when the main content actually appears.
- Interaction to Next Paint tracks the lag between a tap and the page responding to it.
- Cumulative Layout Shift catches the moment a late-loading ad pushes a checkout button out from under someone's thumb right as they go to tap it.
Vodafone Italy isolated the effect in a controlled test, per Google's web.dev.
Two versions of the same landing page ran side by side, visually and functionally identical, except one had a 31% better LCP score.
The faster version generated 8% more sales, a 15% better lead-to-visit rate, and an 11% better cart-to-visit rate. Nothing else about the page changed.
Fewer than half of mobile pages pass all three metrics, despite years of advance warning that the standard was coming.
The latest core updates have hit that failure rate hard. Within a week, websites that failed reporteddeclines in organic traffic of 20% to 35%.
Design In DC's mobile SEO audit framework exists because of this exact gap. We built it around signals a review stopping at responsive layout would miss, the ones Google uses to rank the page.
Ranking for every relevant keyword does not safeguard a page that performs poorly on the device most of its traffic comes from.
Why Google Only Tests the Mobile Version
A site optimized for desktop and left mostly unoptimized for mobile does not get graded on its best version. It gets graded on its weakest one.
Google's ranking system runs on mobile-first indexing. That means the search engine crawls and scores the mobile version of a page, even for a visitor searching from a laptop.
Desktop was the primary build target for most of the web's history. Mobile got whatever attention was left over. Mobile-first indexing flips that.
A desktop page loading in 1.5 seconds says nothing about how the same page holds up on a mid-tier phone with a weak signal.
That is exactly the condition Google's Core Web Vitals data comes from.
A business can build a fast desktop site and still fail the assessment that decides its search ranking.
The Advice Every Client Gets Before Launch
Treat speed like a launch requirement, not a post-launch fix.
At Design In DC, we build it into the brief the same way we would accessibility or security, with three commitments on every project:
- Run every URL through PageSpeed Insights for mobile and set a load-time target before design work starts.
- Test on real devices under throttled 3G using Chrome DevTools, or Lighthouse. A fiber connection tells you nothing about a mid-range phone on a weak signal.
- Treat a failed Core Web Vitals score as a launch blocker, not a post-launch fix.
Most clients don't push back once they see the numbers.
View this post on Instagram
Nordstrom lost 11% of sales to a half-second slowdown, and that was a company with the budget and engineering team to catch it fast.
Speed as a Launch Requirement
A site never designed around Core Web Vitals usually needs rebuilt templates, not a few adjusted settings, because the standard keeps moving.
Google replaced First Input Delay with the stricter Interaction to Next Paint metric in 2024, tightening the bar for responsiveness that sites were already struggling to clear.
A site built to yesterday's threshold is not automatically built to tomorrow's.
The extra week it takes to get load time right before launch costs far less than the rebuild it takes to fix both a conversion problem and a ranking problem after the site is already live.
