Slow online store: what site speed really does to your conversion rate (and how to measure checkout)

A slow online store loses sales, but usually not because "the homepage takes 3 seconds". The expensive slowness hides where a typical speed test never looks: product pages, the cart and the checkout steps, which skip the cache and hit your server on every click. At IThandy I monitor PrestaShop, WooCommerce and Magento stores from the shopper's side, and this guide sums up what is worth knowing before you spend money on "speed optimization".

What the data says about site speed and conversion rate

Site speed has a proven effect on ecommerce conversion rates, but there are few solid, recent studies and each one measures something different. Rather than repeating one "magic" number, know these sources and what they actually measured.

• Deloitte with Google, "Milliseconds Make Millions" (web.dev case study): a 0.1 s improvement in mobile site speed increased conversions by 8.4% for retail sites and 10.1% for travel sites, and retail shoppers spent 9.2% more. The catch: the effect appeared when the improvement covered several metrics across the whole user journey, not a single page.
• Portent, 2022 (portent.com): ecommerce pages that loaded in 1 second converted 2.5 times better than pages that loaded in 5 seconds. In the same study, 86% of the B2C ecommerce pages measured loaded in 5 seconds or less, up from 81% in 2019.
• Gemius 2025, Poland (summary by Przelewy24): among obstacles to shopping on a phone, 33% named inconvenient forms, 27% a slow internet connection and 25% a site not adapted to mobile. Note that the 27% is about the shopper's connection, not the store's speed. It is still an argument for light pages: a heavy store on a weak signal feels even slower.

Context for mobile: in the 2025 US holiday season, 56.4% of online transactions were made on smartphones (Adobe). Test on mobile, not only on your office desktop.

What I do not quote: the famous "100 ms of latency cost Amazon 1% of sales" comes from 2006, and the Shopzilla example from 2008. Different browsers, different networks, different stores. Do not base a budget decision on them.

Three kinds of slow: server, browser, checkout

"My store is slow" can mean three different problems, and each has a different fix. Find out which one you have before changing anything.

1. Slow server (TTFB). The browser waits a long time for the first byte of HTML. Typical causes: PHP, the database, undersized hosting, too many plugins or modules, OPcache not working. As a rough guide, web.dev considers a TTFB of 0.8 s or less good (web.dev on TTFB). Uncached pages suffer most: cart, checkout, search and customer account.

2. Slow in the browser (Core Web Vitals). HTML arrives quickly, but the page takes long to render or responds late to taps. Google's "good" thresholds are LCP up to 2.5 s, INP up to 200 ms and CLS up to 0.1, measured at the 75th percentile of page loads (web.dev on Web Vitals). INP replaced FID as a Core Web Vital on 12 March 2024. Usual suspects: oversized images, heavy JavaScript, marketing tags, web fonts, sliders.

3. Slow checkout steps. The checkout page opens fast, but changing the shipping method, payment method or applying a coupon spins for seconds. Each step is a separate AJAX call to a shipping or payment extension, sometimes to an external API (a pickup point map, a payment iframe). No homepage speed test will ever show it.

Why caching makes the homepage fast and leaves checkout slow

Page caching makes a store look fast in speed tests while shoppers in the cart still wait several seconds. Cache layers (LiteSpeed Cache on WooCommerce, JPresta Page Cache on PrestaShop, Varnish and Full Page Cache on Magento, Cloudflare) serve ready-made HTML to anonymous visitors. Cart, checkout, search and logged-in pages bypass the cache by design, because they are different for every person.

The result: PageSpeed Insights gives your homepage a great score, and the first "Add to cart" click goes to PHP, which takes 3 seconds to answer. Worse, the cache can keep serving a working homepage after PHP has stopped responding entirely. That is why I always measure two things: the page "as a shopper sees it" (cached) and the server with the cache bypassed. More in when page cache hides a store outage.

Where stores lose time: PrestaShop, WooCommerce, Magento

Each platform has its typical bottlenecks, and they are worth checking before you buy a bigger server.

WooCommerce

• Bloated autoloaded options in the database, often left behind by uninstalled plugins.
• Too many plugins loading scripts on every page, including checkout.
• wc-ajax and Store API requests are not cached, so they tell the truth about your server.
• LiteSpeed Cache and similar plugins: cart, checkout and My Account must be excluded from cache, or checkout breaks and shoppers can see stale carts.
• A backlog in Action Scheduler (thousands of pending actions) slows down both the admin and the store.

PrestaShop

• Advanced Parameters -> Performance: Smarty template compilation set to "Never recompile template files" in production (clear the cache manually after deployments).
• CCC (Combine, Compress and Cache for CSS and JS): enable it, but test the theme, as weaker themes can break.
• OPcache enabled for the PHP-FPM pool that actually serves the shop, not only for PHP CLI. A classic hosting trap.
• Too many modules hooked into the same places, especially on product and cart pages.
• JPresta Page Cache for guests, while cart and checkout still run uncached.
• The search index rebuilt and current, otherwise search is slow or empty.

Magento 2

• Full Page Cache and Varnish for guests, but cart and checkout are pure PHP.
• Indexers set to "Update by Schedule" with a working cron, otherwise prices and stock refresh late and queries get heavier.
• Shipping and payment extensions that call external APIs during checkout.

Platform details: WooCommerce checkout monitoring and PrestaShop checkout monitoring.

Median and 95th percentile beat the average

Average response time hides the truth, because a single hung request skews the whole day. If 99 requests take 0.4 s and one takes 30 s, the average is almost 0.7 s, although the store was fast 99% of the time. The opposite happens too: the average looks fine while one in twenty shoppers waits 5 seconds.

Track two numbers instead:

• median - how the store performs on a normal day,
• 95th percentile (p95) - how it performs in the worst 5% of moments. Shoppers remember those moments, and that is when they abandon the cart.

In IThandy Monitor I store the timings of every request: DNS, connect, TLS, TTFB, total time and response size. The dashboard shows median and p95 separately for homepage, category, product and checkout. Checkout always bypasses the cache, so it is the best measure of the server itself.

Staying fast at peak traffic

A store that is fast on a Tuesday morning can crawl on Black Friday evening, because peak traffic exposes hosting limits. Shared hosting caps PHP processes, memory and disk I/O. When traffic rises, requests queue up, TTFB climbs, and eventually you see 503 or 508 errors.

Uncached pages slow down first, which means exactly the cart and checkout. Before the season, look at your checkout p95 over recent weeks; during the peak, rely on alerts when it crosses your threshold. The full preparation list is in the Black Friday website monitoring checklist.

Checklist: what to measure and what to fix first

Start with uncached pages, because that is where shoppers lose patience and where your server shows its real speed.

Measure

• Homepage TTFB with cache and with cache bypassed (origin).
• TTFB of product, cart and checkout pages, median and p95.
• Timing of checkout steps: changing shipping, payment, applying a coupon.
• Core Web Vitals (LCP, INP, CLS) for homepage and product page on mobile, using real-user data (Chrome UX Report) where available.
• A normal day compared with a promotion day (newsletter, campaign).

Reference thresholds

• LCP up to 2.5 s, INP up to 200 ms, CLS up to 0.1 (75th percentile).
• TTFB of 0.8 s or less as a reference point; for cart and checkout, your own baseline from a good week and an alert on a clear rise in p95.

Fix first

• WooCommerce: autoloaded options, plugins loading scripts on checkout, cache exclusions, Action Scheduler queue.
• PrestaShop: OPcache on FPM, Smarty "Never recompile", modules hooked into the cart, CCC after testing the theme.
• Magento: indexers and cron, Varnish exclusions, checkout extensions calling external APIs.
• Everywhere: WebP or AVIF images sized for the screen, fewer marketing tags, pickup point maps loaded only after the shopper chooses that shipping method.

How IThandy Monitor measures store speed

IThandy Monitor measures response time the way your shoppers experience it, separately for cached and uncached pages, and alerts you when the store slows down or stops working. In practice:

• Start (12 EUR net per month): homepage availability and response time every minute, plus a server check with the cache bypassed.
• Shop (35 EUR): adds the product page and add-to-cart every 5 minutes, with a different product each time.
• Shop Pro (85 EUR): adds an hourly checkout test with timings of shipping and payment steps, without placing an order.

Annual billing is 10 times the monthly price. Alerts arrive by email. See plans from 12 EUR a month.

An honest limitation: an HTTP measurement tells you how long it takes to deliver the HTML, not how long the browser needs to render the page. That is why I add Core Web Vitals data from PageSpeed Insights. If you want to see the median and p95 of your own cart before you start optimizing, try it on your store for 14 days.

Related: WooCommerce checkout not working.

Sources

1. Deloitte and Google, "Milliseconds Make Millions" - web.dev case study
2. Portent, "Site Speed is (Still) Impacting Your Conversion Rate" (2022)
3. web.dev, Web Vitals - LCP, INP, CLS thresholds
4. web.dev, Time to First Byte (TTFB)
5. Przelewy24, summary of the Gemius "E-commerce in Poland 2025" report
6. Adobe, 2025 Holiday Shopping Recap (PDF)