How Fast Should Your Website Load? The Numbers That Matter
Speed is a business metric
Every second your site takes to render costs you money, and the effect compounds. This isn't a marketing claim; it's the consistent finding from a decade of public studies and almost everyone's internal A/B tests.
A few that are worth knowing the dates of. Akamai's 2017 retail study found a 7 percent drop in conversion for every 100 milliseconds of additional delay, and a 53 percent mobile abandonment rate above three seconds. Google's 2016 DoubleClick analysis put the average mobile site at over five seconds to first interactive on 3G; the real-world picture has improved, but the conversion shape it described hasn't. More recently, Portent's 2019 ecommerce study showed conversion rates roughly tripling between five-second pages and one-second pages, with the steepest part of the curve in the first two seconds.
The numbers shift across studies, the categories shift, the year shifts. The shape doesn't. Faster pages convert more, and the curve is steepest at the start.
The benchmarks
Google's Core Web Vitals thresholds are the de-facto industry standard, measured at the 75th percentile of real users in the Chrome User Experience Report.
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
| INP | ≤ 200ms | 200ms – 500ms | > 500ms |
| TTFB | ≤ 800ms | 800ms – 1.8s | > 1.8s |
A note on what these don't capture. Time to First Byte (TTFB) is a server-side metric and a useful proxy for backend health, but a fast TTFB doesn't guarantee a fast page; a slow TTFB usually does guarantee a slow page. Largest Contentful Paint (LCP) measures the moment the largest visible element finishes painting, which is what the user perceives as "the page loaded". Cumulative Layout Shift (CLS) measures visual stability across the lifetime of the page. Interaction to Next Paint (INP) replaced FID in March 2024 and measures the responsiveness of real interactions.
Where most sites lose the time
If you've never opened your own site in DevTools' Performance panel, do it now. Almost every slow page falls into a small number of patterns.
Hero images that aren't optimised. A 2 MB JPEG hero adds two to three seconds on a typical 4G connection. The fix is well-trodden: serve AVIF or WebP, size for the actual viewport with srcset and sizes, and either preload the hero or mark it fetchpriority="high". The same hero, served correctly, is usually under 100 KB.
Web fonts that block rendering. Loading four font weights, each as a separate file, with font-display: block, will add hundreds of milliseconds before any text shows up. Use font-display: swap, self-host the fonts, subset them to the characters you actually use, and consider how many weights you genuinely need. Most sites need two.
JavaScript bundles that ship before they earn their place. A single-page app that ships 500 KB of JavaScript before the user can do anything is paying a tax for an architectural choice the user doesn't benefit from. Code-split. Defer everything that isn't on the critical path. Reach for client-side JavaScript only where it changes what's possible, not as a default.
No CDN, or a CDN serving from the wrong tier. If you're already on Vercel, Cloudflare, or any modern host, the CDN is built in. If you're hosting from a single origin region, every distant user pays the latency tax on every asset. The fix is putting a CDN in front, not buying a faster origin.
Third-party scripts loaded synchronously. Analytics, chat widgets, ad tags, cookie banners, A/B testing scripts. Each one adds a vendor on the critical path. Each one can run later. Audit what's there, remove what isn't pulling its weight, and load the rest with async, defer, or priority="low".
Our targets
Every site we build aims tighter than the green band:
- ›LCP under 1.5 seconds at the 75th percentile
- ›CLS under 0.05
- ›INP under 100 milliseconds
- ›Total page weight under 500 KB
We hit those numbers by being honest about what each page needs to do. Static where static will do, server-rendered when content is dynamic, client-rendered only when interactivity earns it. Images served as AVIF with proper dimensions. Fonts subsetted and self-hosted. Critical CSS inlined. Edge deployment in front of everything. Nothing decorative on the critical path.
That last point matters more than the rest. Most slow pages are slow because they're doing things that don't help the user, and removing those things is faster, cheaper, and more durable than adding more infrastructure.
The ROI
A small worked example. A lead-gen site getting 10,000 monthly visitors at a 2 percent conversion rate generates 200 leads a month. Improving load time from 4 seconds to 1.5 seconds typically yields a conversion rate increase of 1 to 2 percentage points, in line with the curves Akamai and Portent reported. That's 100 to 200 additional leads a month, from a one-time investment in performance, sustained for the lifetime of the site.
The honest version: the lift varies by category, by audience, by intent. The high end of those numbers comes from sites where speed was a serious bottleneck; the low end comes from sites where the fix moved the page from "fine" to "fast". Either way, the work pays itself back inside the first few weeks of any month with non-trivial traffic.
The summary
The benchmarks are public, the metrics are well-defined, and the techniques to hit them have been settled engineering for years. The reasons most sites are slow are not technical mysteries; they're choices nobody pushed back on. Pick the targets above, audit your real money pages against them, fix the four or five things that show up in DevTools, and hold the line on each release. That's the entire programme.
