Services

Page

Services

Page

eCommerce

eCommerce Site Speed and Conversion: What Slow Pages Actually Cost You

Diana Zander Research Muse

12 min09 Nov 2026

Want to discuss
your project?

Where speed leaks revenue in an online store, how to put a number on it, and five layers to check, in the order they pay back.

Key takeaways

Why it matters: shoppers leave slow pages, and every second of delay costs you sessions that would have converted.
What to do first: measure real-user speed on your top five pages before you change anything.
Slow stores usually trace back to five layers: hosting, images, scripts, theme and checkout.
Images and third-party scripts are the cheapest wins and often account for most of the gain.
Put a revenue number on speed. It turns a technical backlog item into a business decision.

Most teams treat page speed as an engineering hygiene task. It sits in the backlog under a new feature, gets a sprint after a bad review of the site, and loses the next planning meeting to something with a revenue label on it.

Speed carries a revenue label too. It shows up in bounce rate, in the share of visitors who reach the cart, and in how many of them finish checkout on a phone with an average connection. This guide shows where the money leaks, how to estimate it with your own numbers, and what to check, layer by layer.

What slow pages cost

A widely cited study by Deloitte and 55, commissioned by Google, looked at 37 brand sites over 30 days and about 30 million sessions. It found that a 0.1 second improvement in mobile site speed metrics lifted retail conversion by 8.4% and retail spend by 9.2%. The study dates from 2019 and covers mobile retail, so read the percentages as a sign of direction and a rough order of magnitude for your own store.

Google's own data on bounce shows the same shape: the probability that a visitor leaves goes up 32% as load time moves from one second to three.

You can turn this into your own estimate in four steps:

Take your monthly sessions on the pages you want to improve.
Multiply by your conversion rate and average order value to get monthly revenue from those sessions.
Pick a cautious relative lift, such as 1% to 3%, well below the study figure.
Multiply revenue by that lift. The result is what speed work is worth per month, before you spend a euro.

Measure first: what "fast" means

Google groups page experience into three Core Web Vitals. Each has a "good" threshold, measured at the 75th percentile of real visits.

Two kinds of data matter:

Field data comes from real visitors. It tells you what customers feel, and it is what Google uses.
Lab data comes from a test run on one machine. It helps you find the cause, and it will not match field data exactly.

Start with field data. If your platform offers a performance dashboard for the storefront, read it before you buy any tool. Then use lab tests on your five most valuable pages: the home page, a category page, a product page, the cart and the checkout.

Layer 1 of 5: Hosting and server. Does the page start fast?

Everything else waits for the first byte. A slow server response drags every metric after it.

Time to first byte. Check how long the server takes to respond on uncached pages, and set a target for it.
Caching. Category and product pages that rarely change should be cached at the edge, close to the shopper.
A content delivery network. Static files, images and scripts should come from servers near your customers.
Database and search. Slow product queries and filters often show up as slow category pages under load.
Peak load. Test before the sale. A page that is fast at 10 visitors can fail at 1,000.

Layer 2 of 5: Images and media. Is the heaviest part of the page light?

On most stores, images are the largest files on the page and the most common cause of a slow main content paint.

Format and size. Serve modern formats and the right dimensions for the screen. A phone does not need a 3,000 pixel wide photo.
The hero image. The first large image defines the loading metric. Load it early and do not lazy-load it.
Lazy loading below the fold. Images further down should load as the shopper scrolls to them.
Reserved space. Give every image and banner a fixed size, so the page does not jump while it loads.
Video. Autoplay video in the first screen is expensive. Load a poster image first and the video on demand.

Layer 3 of 5: Scripts and third-party apps. What are you loading that you do not use?

Each app and tag adds code from someone else's server, and each can slow the whole page.

Inventory. List every script on your top five pages. For each, name the owner and the business reason.
Unused apps. Remove apps nobody uses. Uninstalled apps sometimes leave code behind, so check the theme too.
Load timing. Tags that do not need to run first, such as chat widgets and analytics add-ons, can load after the page is ready.
Tag managers. A tag manager can hide dozens of scripts. Review it as a layer of its own.
Measure before and after. Test a page with and without an app. If the app costs half a second, decide with a measured number.

Layer 4 of 5: Theme and rendering. Does the page show up without waiting?

The theme decides how much code the browser must read before it can draw anything.

Render-blocking files. Large style and script files in the page head delay the first paint. Split or defer them.
Fonts. Limit the number of font files and show text while fonts load, so the page does not stay blank.
Unused code. Themes ship features you never turned on. Remove what you do not use.
Layout shifts. Pop-ups, cookie banners and late banners that push content down hurt the stability metric and annoy shoppers.
Interaction delay. Heavy scripts can make buttons feel dead for a moment. Test tapping on a mid-range phone.

Layer 5 of 5: Checkout and mobile. Does the money page keep up?

Checkout is where a slow page costs the most per visitor, and mobile is where most of the traffic arrives.

Test on a real phone. Use a mid-range device on a normal mobile connection.
Checkout scripts. Payment, address lookup and fraud tools load code. Keep what you need and delay what you can.
Form response. Fields, totals and shipping options should update without a visible wait.
Payment redirects. Each redirect adds a delay. Count them.
Error states. A slow error page loses the shopper twice. Test failure paths as well.

The quiet risk: speed that decays after launch

A store is fast on the day an agency hands it over. Six months later, three new apps, a heavier home page and a pop-up have undone the work. Nobody changed speed on purpose, and nobody noticed.

The fix is a performance budget: a short written limit for each key page, such as total image weight, script count and the three vitals. Check it on every release and fail the release when the page goes over. Review the third-party list once a quarter.

Seven mistakes we see most often

Optimizing the lab score. A green test result does not prove that real visitors on phones feel a fast page.
Lazy-loading everything. Including the hero image makes the loading metric worse.
Installing apps without measuring. Each one looks small. Together they are not.
Testing only the home page. Product, cart and checkout carry the revenue.
Ignoring mobile. Most visits arrive on phones, on connections slower than the one in your office.
Fixing speed once. Without a budget and a review, pages slow down again.
No revenue number. Without one, speed loses every prioritization meeting.

Questions to ask your developer or agency

What are our field numbers for the three vitals on the top five pages?
Which third-party scripts load on the product page, and who owns each one?
What is the weight of the home page and of a typical product page?
Which fixes do you expect to move the numbers most, and how will you measure it?
Is there a performance budget, and does a release fail when it is broken?
How does checkout perform on a mid-range phone?
Who reviews speed after launch, and how often?

Terms in plain words

LCP (Largest Contentful Paint): how long it takes for the biggest visible element, often the hero image, to appear.
INP (Interaction to Next Paint): how quickly the page reacts after a tap or click.
CLS (Cumulative Layout Shift): how much the page jumps around while loading.
TTFB (Time to First Byte): how long the server takes to start answering.
Field data and lab data: measurements from real visitors, and from one test run.
Performance budget: a written limit that a page must stay within.

In Lazy Ants

We approach speed as a sequence of checks, with a revenue estimate at the start:

We measure field data on your top pages and estimate what speed is worth in revenue.
We find the heaviest files, scripts and server delays, and rank fixes by effort and effect.
We review the third-party inventory with your team and remove what has no owner.
We set a performance budget and wire it into your release process.
We re-measure after launch, so the result shows up in your own numbers.

If you want an outside read on where your store loses speed and money, our eCommerce architecture review covers performance, integrations and platform limits. For related questions, see what replatforming costs and what gets lost in a platform switch.

What to fix first

This week: read your field data, list the third-party scripts on your top five pages and remove the ones nobody owns.
This sprint: compress and resize the heaviest images, fix the hero image and reserve space for banners.
This month: clean up theme code, review the tag manager and test checkout on a real phone.
This quarter: set a performance budget, add it to your release checks and schedule a quarterly review.

FAQ

How much does a slow site cost?

It depends on your traffic, conversion rate and order value. A Google-commissioned study of 37 brands found that a 0.1 second mobile gain lifted retail conversion by 8.4%. Estimate your own figure with a cautious lift.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

What is a good page load time?

Use the three vitals as targets: loading under 2.5 seconds, interaction under 200 milliseconds and layout shift under 0.1, measured on real visits at the 75th percentile.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Which page should I fix first?

The page that carries the most revenue per visit and has the worst field numbers. For most stores that is a product page or the checkout.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Do third-party apps really slow a store?

They can. Each app adds code from another server. Measure a page with and without the app, and keep only what pays for itself.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Does speed affect search rankings?

Page experience is one of many signals, and speed also affects how many visitors stay. Treat it as a conversion factor first.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Do I need a new platform to be fast?

Often not. Images, scripts and theme code explain most slow stores, and all of them can be fixed on the current platform. A platform change is a separate decision.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

How long do speed gains last?

Only as long as someone guards them. A performance budget and a quarterly review keep pages from sliding back.

Sources: Deloitte and 55 for Google, "Milliseconds Make Millions" (2020), on mobile speed and retail conversion; Think with Google on page load time and bounce probability; Google's web.dev on Core Web Vitals thresholds; agency and practitioner guides on ecommerce speed. Figures date from the studies and may have changed, so check current data before you plan.

Conclusions

Where should you start?

Need expert advice on your project?

Schedule a call with our team to discuss your needs and get expert guidance.

eCommerce

eCommerce Data Migration: What Actually Gets Lost in a Platform Switch

eCommerce data migration risk: the customer records, SEO metadata and order history that quietly break during a platform switch, and how to protect them.