A slow website kills sales – how much are you losing every day?

Three seconds. That's how much time an average mobile user gives you before closing the tab and going to your competitor. If you run an online store or generate leads through a website, every tenth of a second translates into money. This article was created at vollelabs – we build fast websites and stores, so we know the topic from the inside out.

What the data says: seconds turn into losses

Let's start with numbers, as they make decisions easiest.

According to a 2017 Google/SOASTA study (still the most cited source in the industry), when the load time of a mobile page goes from 1 to 3 seconds, the probability of a bounce increases by 32%. At 5 seconds, the jump reaches 90%.

The study "Milliseconds Make Millions" (Google / Deloitte / 55, 2019–2020) showed that improving load time by a mere 0.1 seconds increased e-commerce conversions by 8.4% and the average order value by 9.2%.

The Portent report from 2022 found that a B2B site loading in 1 second has a conversion rate 3× higher than a site loading in 5 seconds.

Let's put this into an example. A store with a monthly turnover of $100,000 and an average load time of 4.5 s improves it to 2 s. Even if we assume only half the effect described by Deloitte (because every store's conditions are different), we're talking about thousands of dollars in extra monthly revenue – without touching the ad budget.

Vodafone: a simple A/B test, 8% more sales

Theory is one thing. Let's see what happens in practice.

Vodafone Italy ran an A/B test where the only difference between variants was Web Vitals optimization. Improving LCP (Largest Contentful Paint) by 31% translated into an 8% increase in sales, 15% more leads, and an 11% increase in the "cart-to-visit" rate.

What did they do? They moved widget rendering from client side to server side, reduced render-blocking JavaScript, and optimized images – including shrinking the hero image and using media queries to prevent loading off-screen graphics.

None of these changes required rebuilding the site. These were fixes applied to the existing codebase.

Core Web Vitals – three metrics evaluated by Google (and customers)

If you're not tracking Core Web Vitals yet, it's time to start. It's a set of three metrics Google uses to evaluate a site's loading speed, interactivity, and visual stability: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

• LCP – how much time passes until the largest element visible on the screen (e.g., a product photo) is rendered. A good score is under 2.5 seconds.
• INP – how quickly the page responds to clicks and taps. Goal: below 200 ms.
• CLS – whether elements "jump around" during loading. Goal: below 0.1.

According to the HTTP Archive Web Almanac 2024, only 43% of mobile pages cleanly pass all three metrics. That means over half the internet still doesn't meet the standards. If your site meets them – you have an advantage. If not – you're giving it away to competitors.

How to check it yourself: an audit in 15 minutes

You don't have to call an agency right away. The following steps will take a quarter of an hour and show you where you stand.

Step 1: PageSpeed Insights

Go to pagespeed.web.dev, paste your website URL, and click "Analyze". The tool will evaluate your site's performance on mobile and desktop using lab data (Lighthouse) and data from real Chrome users (CrUX).

Focus on the "Field Data" section – that's the picture of what your actual visitors see. A "Lab" score is useful for debugging but doesn't reflect real traffic conditions.

Step 2: Check the Core Web Vitals report in Search Console

If you have Google Search Console connected, open the "Core Web Vitals" tab. You'll see your URLs divided into three categories: Good, Needs improvement, Poor. Start with the ones marked in red.

Step 3: GTmetrix – a request-by-request waterfall

Go to gtmetrix.com and test the same page. GTmetrix will show you a "Waterfall" chart – a chronological list of all resources loaded by the browser. Look for:

• render-blocking JS and CSS files (marked in orange/red),
• images above 200 KB (you rarely need more on a mobile screen),
• requests to external domains (trackers, chats, fonts) – each adds delay.

What you can fix yourself vs. what requires a developer

A brief explanation of two terms from the table:

Lazy loading – a technique where images and elements off-screen aren't loaded immediately, but only when the user scrolls down to them. This saves the browser from fetching data at the start, lowering LCP.

CDN (Content Delivery Network) – a geographically distributed network of servers that serve static files (images, CSS, JS) from a location closest to the user. A client in London gets files from Europe, not from the US.

Typical "silent speed thieves"

Finally – three things we see most often during vollelabs audits, which regularly slow down sites by 1–3 seconds:

1. Uncompressed hero images weighing 2–5 MB. Switching to WebP with proper compression shrinks the size by 60–80% without visible quality loss. Tool: Google's Squoosh – works in the browser, no installation required.
2. Ten marketing scripts loaded synchronously in <head>. Facebook Pixel, Google Tag Manager, chat, heatmap, pop-up, survey... Each fights for browser resources before the page can even render. Solution: load them asynchronously, or – better yet – via Google Tag Manager with a "Window Loaded" trigger.
3. Fonts loaded from an external server without font-display: swap. The effect: the user sees a blank screen for 1–2 seconds because the browser is waiting for the font file. Adding one CSS line (font-display: swap;) makes the text display instantly in a fallback font, swapping to the proper one once it's loaded.