Why your website's speed decides your sales — and how we fix it

Website speed is not a technical nicety — it is money. When Deloitte and Google analyzed over 30 million sessions across 37 major brands, they found something surprisingly concrete: an improvement of just one tenth of a second in mobile speed lifted retail conversion rates by 8.4%, and on luxury sites the step from product page to cart rose by over 40%.

In other words: if your site is slow, you are losing customers every day — you simply never see them leave. In this article we show you what the data says, how Google measures you, what actually slows a site down and, above all, what we concretely do to make it fast — on WordPress, on custom-built PHP sites and at the server level.

What the numbers say

The link between speed and sales is one of the most studied on the web. A few solid, recent reference points:

• 0.1 seconds matters. The "Milliseconds Make Millions" study (Deloitte & Google) shows that a 100-millisecond improvement lifted retail conversions by 8.4% and average order value by 9.2%.
• Under 2 seconds is the sweet spot. A Portent analysis of over 100 million page views found that conversion rates peak at 1–2 seconds (~3%) and drop to around 0.7% at 4 seconds.
• Speed, put to the test. In a real A/B test, the Rakuten 24 store achieved +53% revenue per visitor and a +33% conversion rate with a speed-optimized page.

And the reverse holds too — the slower the site, the more people leave. A Google/SOASTA model shows how the probability of a mobile visitor abandoning the page grows as loading takes longer:

The famous statistics — "Amazon lost 1% of sales for every 100 ms" or "53% abandon a mobile site slower than 3 seconds" — are real, but old (2006–2016). We mention them for context — their conclusion, however, is confirmed today too, by the data above.

Core Web Vitals: the 3 numbers Google measures you by

Google has turned "speed" into three concrete measurements, called Core Web Vitals. They are measured on real visitors (at the 75th percentile — that is, the experience of most of your users) and they also count towards your position in search results:

• LCP (Largest Contentful Paint) — how quickly the main content of the page appears. Target: under 2.5 seconds.
• INP (Interaction to Next Paint) — how quickly the page reacts when you click or tap. Target: under 200 ms. (In March 2024 it replaced the old FID metric.)
• CLS (Cumulative Layout Shift) — how stable the layout stays, without elements "jumping" under your finger. Target: under 0.1.

How the web actually measures up

The reality is that most sites fail the test. According to the HTTP Archive Web Almanac (real-visitor data, 2025), only 48% of mobile sites pass all three Core Web Vitals. The average page has grown to ~2.2 MB and 70+ requests to the server.

And the platform you are on matters a lot. Here is how many sites pass the test on mobile, by platform:

What actually slows a site down

A heavy page is, for the most part, images and JavaScript code. Here is what an average page is made of:

But weight is only half the story. What most often "kills" speed:

• A slow server (TTFB). The time to the server's first response is the biggest piece of a poor LCP — on slow sites, the server alone "eats up" over 2 seconds. Only 42% of mobile sites have a good TTFB.
• Unoptimized images — loaded at huge resolutions, in old formats, without lazy loading.
• Too much JavaScript. Scripts (especially third-party ones: analytics, chat, consent) block the main thread and make the page slow to respond to clicks — the main cause of a poor INP.
• No caching. Without a cache, every visitor makes the server rebuild the page from scratch.

A useful myth to bust: "compress the image and you're done". Google's data shows that, on slow sites, the browser loses by far the most time waiting for the download to start (because of the server and blocking scripts), not downloading the image itself. That is why the real fix is usually at the server and cache level, rather than in a single photo.

What we do for WordPress

WordPress can be fast — it depends on how it is built and maintained. The levers we pull:

• Page cache + object cache (Redis). Pages are served in milliseconds, and for the dynamic areas (cart, account) Redis cuts response times by 40–75% and database queries by 50–80%.
• Optimized images. We convert to modern formats (WebP/AVIF), size them correctly and enable lazy loading — that is where half the page weight lives.
• A plugin clean-up. Fewer extensions mean less JavaScript and fewer scripts blocking the page.
• Good hosting + up-to-date PHP. Fast hosting and a recent PHP version lower the TTFB — the foundation everything else stands on.
• CDN, compression and smart loading. Content served from nearby, compressed (Brotli), with the critical CSS loaded first and non-essential JavaScript deferred.

This is also where regular maintenance comes in: a site left without updates and database clean-ups slows down without you noticing.

What we do for custom PHP sites

When we build the application ourselves, we have full control over the code — so we can consistently aim for 1–2 seconds:

• OPcache + PHP tuning. Enabling the code cache (OPcache) lets the server handle 2–5 times more requests, eliminating recompilation on every request.
• Optimized queries and indexes. We eliminate repeated and slow queries, add indexes and put a cache on the heavy results.
• Page and fragment caching. A cached page is served in under 10 ms, versus 500 ms+ when it is generated from scratch.
• Code delivered clean. Brotli/gzip compression, HTTP/2 and HTTP/3, files combined and minified, JavaScript deferred and loaded only where it is needed.
• We measure, we don't guess. We profile the application, find the real bottlenecks and fix exactly those — no optimizing at random.

That is what custom software is really about: a site that does not carry the dead weight of dozens of modules you do not need.

What we do at the server level

The foundation matters most. At the infrastructure and hosting level:

• Hosting that fits. It is the biggest lever for TTFB: on high-performance hosting, ~85% of sites have a good response time, versus only ~29% on cheap, overcrowded hosting. Our target: under 800 ms, ideally far lower.
• Server-level caching. Full-page cache (Varnish / Nginx micro-cache) for anonymous visitors, plus Redis for dynamic data.
• Fast storage (NVMe). For sites with large databases, NVMe drives handle several times more operations per second than classic SSDs.
• Modern protocols and compression. HTTP/2 and HTTP/3, Brotli, plus PHP-FPM tuned for the real traffic.
• Continuous monitoring. We track speed and availability around the clock, so we catch a slowdown before your customers feel it.

Key takeaways

• Speed is revenue, not cosmetics. A tenth of a second can mean +8% conversions; a slow page loses customers silently.
• Google measures it concretely — LCP, INP, CLS — and more than half of mobile sites still fail the test. That is a real advantage for whoever passes it.
• The biggest levers are caching and hosting, not small tricks. A slow server and excess JavaScript make the difference.
• Whatever the platform — WordPress, custom PHP or the server itself — speed can be measured and fixed. That is what we do.

Sources

• Deloitte & Google — Milliseconds Make Millions (2020)
• Portent — Site Speed & Conversion Rate (2022) and web.dev — Rakuten 24 (2023)
• web.dev (Google) — Core Web Vitals (2024)
• HTTP Archive Web Almanac — Performance (2025) and Page Weight / CMS (2024)
• web.dev — Common misconceptions about LCP optimization and Kinsta — PHP Benchmarks (2025)