The Numbers That Matter
The relationship between page speed and conversion rate is not theoretical — it's one of the most well-documented phenomena in digital commerce. The data comes from sources that have run the experiments at scale.
Google's own research found that as page load time goes from 1 second to 3 seconds, the probability of a mobile visitor bouncing increases by 32%. From 1 second to 5 seconds, that bounce probability jumps by 90%. From 1 second to 10 seconds, it reaches 123%. You are losing over half your mobile traffic just by being slow.
Walmart found that every 1-second improvement in page load time resulted in a 2% increase in conversions. For a business doing $10M in annual online revenue, that's $200,000 recovered per second of improvement — not from additional marketing spend, but from simply not losing the visitors you already paid to acquire.
Deloitte's 2020 study across retail sites found that a 0.1-second improvement in site speed lifted conversion rates by 8% for retail sites and 10% for travel sites. Milliseconds, not seconds. The threshold for perceptible performance is far below what most companies optimise to.
Amazon reportedly estimated that a 100ms delay in page load would cost them 1% in sales — at their scale, approximately $3.5 billion annually. The number is old; the principle is timeless and applies proportionally to any business generating revenue online.
| Load Time | Bounce Rate Increase | Conversion Impact | SEO Signal |
|---|---|---|---|
| Under 1s | Baseline | Baseline | Strong positive |
| 1–2s | +11% | -4% to -6% | Good |
| 2–3s | +32% | -8% to -15% | Neutral |
| 3–5s | +90% | -20% to -35% | Negative factor |
| 5s+ | +106% | -40% or worse | Strong negative |
Why Most Websites Are Slow
Speed problems are rarely mysterious once you know what to look for. The same four causes account for the vast majority of slow sites.
Render-Blocking JavaScript
Every script tag in the <head> of your page that doesn't have an async or defer attribute tells the browser to stop everything, download the script, execute it, and only then continue rendering the page. This is called render-blocking. A page with 10 synchronous scripts loaded in sequence is effectively making visitors wait for 10 sequential network round-trips before they see anything.
Tag managers, analytics, chat widgets, A/B testing tools, and marketing scripts are the most common offenders. Each team adds their tool. Nobody audits the cumulative impact. Within 18 months of a website launch, it's common to find 15-20 third-party scripts loading on every page — many of them blocking render.
Unoptimised Images
Images are typically the largest assets on any web page. A hero image exported from Photoshop as a JPEG at maximum quality and displayed at 1440px wide can easily be 4-6MB. The same image, properly resized, compressed, and served in WebP format, can deliver the same visual quality at 150-300KB. That's a 15-20x size reduction that directly translates to faster load times, especially on mobile connections.
Most CMS platforms do not handle this automatically. If your team uploads images and hits publish, you're almost certainly serving oversized assets.
No Caching Strategy
HTTP caching allows a browser to store assets locally so they don't need to be re-downloaded on subsequent visits. Without proper cache headers, every visit to your site — including return visits from existing customers — downloads every asset from scratch. A properly configured cache means returning visitors load your site almost instantly. It costs nothing to implement and is one of the most impactful quick wins available.
Cheap or Shared Hosting
Your server's time to first byte (TTFB) is the foundational number under all other performance metrics. If your server takes 800ms to respond before the browser has received a single byte of HTML, you're starting every page load with a handicap that no amount of front-end optimisation fully compensates for. Shared hosting environments — where your site shares resources with hundreds of others — are the most common cause of poor TTFB. Moving to a modern edge-deployed CDN or a dedicated hosting tier is frequently the single highest-leverage change a slow site can make.
Core Web Vitals Explained Simply
Google uses a set of metrics called Core Web Vitals as part of its ranking algorithm. These aren't academic measurements — they're proxies for real user experience, and they directly affect where you appear in search results.
- Largest Contentful Paint (LCP): How long until the main content on the page is visible. Target: under 2.5 seconds. This is usually your hero image or main heading. Poor LCP is almost always caused by slow server response or an unoptimised above-the-fold image.
- Interaction to Next Paint (INP): How quickly the page responds when a user interacts — clicks a button, opens a menu, types in a field. Target: under 200ms. Poor INP is caused by heavy JavaScript execution blocking the browser's main thread.
- Cumulative Layout Shift (CLS): How much the page visually jumps around as it loads. Target: under 0.1. Poor CLS is caused by images without defined dimensions, late-loading fonts, and dynamically injected banners that push content around.
A site that passes all three Core Web Vitals thresholds receives a ranking boost. A site that fails all three is measurably disadvantaged against competitors who pass them — assuming broadly similar content quality. Speed is now directly part of the SEO equation.
In our audits of B2B software and service company websites, fewer than 15% pass all three Core Web Vitals on mobile. If your competitors are in that 85% who don't — and most of them are — this is one of the clearest paths to a ranking advantage without creating new content.
The 5 Fixes With the Highest ROI
Not all speed optimisations are equal. These five deliver the largest measurable impact relative to implementation effort:
- Serve images in next-gen formats (WebP/AVIF) at correct dimensions. Convert all images from JPEG/PNG to WebP. Add responsive image markup so mobile devices get smaller files. Implement lazy loading for below-the-fold images. Estimated impact: 30-60% reduction in total page weight.
- Defer or async all non-critical JavaScript. Audit every script tag. Everything that doesn't need to execute before the page renders should be deferred. Third-party scripts — analytics, chat, tag managers — should load after the page is interactive. Estimated impact: 0.5-1.5s improvement in LCP and INP.
- Implement browser and server-side caching. Set aggressive cache headers for static assets (images, CSS, JS): at least 1 year for versioned assets. Configure server-side caching for dynamic pages where appropriate. Estimated impact: near-instant load times for returning visitors.
- Move to edge-deployed hosting or a CDN. CDNs serve your assets from servers geographically close to each visitor, dramatically reducing latency. Modern edge platforms like Cloudflare, Vercel, or AWS CloudFront can cut TTFB from 600ms+ to under 100ms. Estimated impact: 0.3-0.8s improvement across all metrics.
- Preload critical resources. Use
<link rel="preload">to tell the browser about the most important resources — typically your LCP image and your primary web font — so it starts downloading them earlier in the load sequence. Estimated impact: 0.2-0.5s improvement in LCP.
How to Measure Your Current Speed
Before fixing anything, measure. The tools that give you the most useful data:
- Google PageSpeed Insights (pagespeed.web.dev): Runs a real Lighthouse audit against your page and shows your Core Web Vitals scores for both mobile and desktop. Also shows field data from real Chrome users via CrUX. Start here.
- WebPageTest.org: More detailed than PageSpeed Insights. Run a test from a real browser on a real connection, including a waterfall chart that shows you exactly which resources are delaying render. Use this to find the specific bottlenecks.
- Google Search Console (Core Web Vitals report): Shows aggregate field data for your entire site segmented by poor/needs improvement/good URLs. Use this to identify which pages are most affected and prioritise your fix list accordingly.
- Chrome DevTools Performance tab: For developers who need to diagnose specific interaction slowness or layout shift causes, the Performance panel records a detailed trace of exactly what the browser was doing during load or interaction.
Measure on mobile, not just desktop. Google uses mobile performance for rankings, and mobile connections are where the performance delta between a fast and slow site is largest. A site that loads in 1.8s on a desktop fibre connection may take 6+ seconds on a mid-range Android device on a 4G connection — which is where much of your traffic actually comes from.
What to Expect After Fixing It
The timeline for seeing results from speed improvements breaks into two distinct parts. The user experience improvements are immediate — the moment the fixes are deployed, visitors on that page load it faster. This directly impacts bounce rate and conversion rate from that day forward.
The SEO improvements take longer. Google re-crawls pages on a variable schedule, and the CrUX field data used for Core Web Vitals ranking signals is a rolling 28-day window. You typically start seeing ranking movement 4-8 weeks after a significant speed improvement, as the new, faster data accumulates and displaces the old slow data.
For a B2B service site receiving 5,000 organic visitors per month with a 2% conversion rate: if a speed fix reduces bounce rate by 20% and improves conversion rate by 2 percentage points (from 2% to 4%), the pipeline impact is significant — not from more traffic, but from converting the traffic you already have. Investing in speed optimisation is one of the few marketing improvements that simultaneously improves user experience, SEO rankings, conversion rates, and your quality score in paid campaigns.