Speed Is Money: Measuring eCommerce Performance Where It Actually Counts

“Our store is fast” is one of the most confidently wrong sentences in eCommerce.

It is usually measured on the homepage, on the team’s iPhone, and on office Wi-Fi — none of which reflects where customers actually buy or how they connect.

Real speed lives on the path to purchase, on a mid-range phone, and it maps almost directly to revenue.

Here is where to measure, what to fix, and why speed has to be built in rather than bolted on.

Why Speed Maps to Revenue: Conversion and SEO at Once

Speed is not a technical nicety sitting next to conversion rate optimisation. It is an input to it.

Deloitte’s study of 37 major retail sites, conducted with Google and Fifty-Five, found that a one-second delay in load time costs the average retailer 7% of conversions.

The effect also works in reverse — and compounds.

A 0.1-second improvement in mobile load time increased retail conversion rates by 8.4% and average order value by 9.2%, according to the same Milliseconds Make Millions research, which analysed 30 million mobile sessions across retail, travel, and luxury brands.

Separate research from Portent puts a number directly on the gap between fast and slow stores.

eCommerce sites that load in under two seconds convert at roughly 3.05%, compared with 1.94% for sites loading in the three-to-four-second range. Sites loading in one second convert about 2.5 times more visitors than sites loading in five seconds.

The SEO side is not separate. It is the same lever.

Core Web Vitals became an official Google ranking factor in June 2021. While they function more as a tie-breaker between pages with similar relevance than as a guaranteed ranking boost, a slow page still competes with one hand tied.

Worse rankings feed fewer sessions into a conversion rate that is already being suppressed by the same slowness.

Speed is one of the few variables that improves both sides of the funnel at once:

• more people arrive;

• more of the people who arrive buy.

 

Almost every “our site is fast” claim breaks down because of two specific mistakes.

Mistake 1: Measuring Only the Homepage

The homepage is usually the page teams optimise hardest because it is the page stakeholders look at most often.

It is also the page furthest from a transaction.

A shopper does not pay on the homepage. They pay after:

1. browsing or filtering a category;

2. comparing products;

3. opening a product page;

4. adding an item to the cart;

5. entering payment information.

Each of those screens has its own scripts, integrations, third-party tags, and opportunities to stall.

Mistake 2: Testing on the Wrong Device

Testing on a current-generation iPhone over office Wi-Fi tells you almost nothing about the median customer’s experience.

Google’s reference point for a “median” mobile device is roughly comparable to a Samsung Galaxy S7 from 2016 — a device with a few gigahertz of CPU power and 4 GB of RAM, nowhere near modern flagship territory.

Performance engineer Harry Roberts makes the same point bluntly: testing only on your best device and treating that result as the baseline excludes 50% of users by definition. A median device is faster than only half of the install base.

A page that feels instant on a flagship phone over fibre can be genuinely unusable on a mid-range Android over a throttled mobile connection.

For a meaningful share of an online store’s traffic, that mid-range Android is the actual customer experience.

 

If the homepage is not where the purchase happens, measure where it does.

The path that matters is:

Category → Search → Filters → Product → Cart → Checkout

Each step carries its own performance weight.

The Google and Deloitte funnel data supports this directly. Their report found that a 0.1-second speed improvement produced:

• a 3.2% increase in progression from product listing pages to product detail pages;

• a 9.1% increase in progression from product pages to “add to basket.”

The deeper a customer moves into the funnel, the more expensive each delay becomes.

Checkout Deserves the Most Scrutiny

Checkout is usually the most script-heavy page on an eCommerce site.

It may include:

• payment SDKs;

• fraud detection tools;

• address autocomplete;

• analytics;

• retargeting pixels;

• upsell widgets;

• delivery integrations;

• customer support scripts.

All of this is stacked onto the one page where the shopper has already committed to buying and is one bad delay away from abandoning a full cart.

Search and filtering are close behind.

They are often powered by separate services, load results asynchronously, and are exactly the kind of interactions that INP is designed to catch. A laggy filter click does not feel like “loading” to a shopper. It feels broken.

Measuring only the homepage means optimising the page that costs you the least when it is slow while ignoring the pages that cost you the most.

Core Web Vitals are Google’s attempt to measure a simple question:

Does this page feel fast and stable to a real person?

They are built around three metrics.

Largest Contentful Paint

LCP measures how quickly the main visible content appears.

Cumulative Layout Shift

CLS measures how much the page unexpectedly jumps or shifts while loading.

Interaction to Next Paint

INP measures how quickly the page responds after a user taps, clicks, or types.

INP is the newest of the three and the metric eCommerce teams often underestimate most.

It officially replaced First Input Delay as a Core Web Vital on March 12, 2024.

Unlike First Input Delay, INP does not measure only the first interaction. It observes interaction latency across the entire visit and reports a representative result based on nearly all interactions.

Google’s threshold for a “good” INP is 200 milliseconds or less, measured at the 75th percentile of real visits.

That makes INP a near-direct proxy for the moments that matter most in a purchase flow:

• selecting a size;

• applying a filter;

• clicking “add to cart”;

• opening the cart;

• submitting a payment form.

A slow LCP makes a page feel slow to load.

A slow INP makes a page feel broken to use.

Broken is what makes people abandon carts.

Google has treated Core Web Vitals as a ranking signal since June 2021. Industry analysis generally agrees that they operate more as a tie-breaker between similarly relevant pages than as a factor that can independently override content relevance.

The practical takeaway is not to chase a perfect Lighthouse score for imaginary SEO points.

The real takeaway is that the same improvements that strengthen Core Web Vitals also make it easier for a customer to complete a purchase:

• lighter scripts;

• faster server responses;

• fewer layout shifts;

• faster interactions;

• fewer third-party dependencies.

The ranking benefit and the conversion benefit come from the same underlying work.

The teams that keep their stores fast do not run one large optimization sprint every year.

They say no constantly, in small increments.

Every marketing tag, every “just add this one plugin,” and every third-party widget is individually harmless and collectively fatal.

Third-party scripts commonly account for a significant share of JavaScript execution time on eCommerce pages. Site-speed benchmarking has also found a measurable relationship between the number of third-party services installed on a store and its mobile performance score.

Stores using five or fewer third-party services perform dramatically better than stores using twenty or more.

None of those additions feels like the single thing that broke checkout.

That is the trap.

Performance is not a page you visit once before launch and then forget. It is a standing decision applied every time someone in marketing, product, or engineering wants to add another script to a page already carrying twenty.

“Foundation, not finish” means treating the performance budget as a constraint the team designs within — not as a cleanup task scheduled after a feature ships.

In practice, that means:

• setting a hard limit on scripts allowed in checkout;

• adding a review gate before a new tag goes live sitewide;

• testing performance after every release;

• treating regressions as bugs;

• removing tools that no longer create measurable value.

 

A Case in Discipline: Designing for Peak Load

The clearest test of “foundation, not finish” is not an average Tuesday.

It is the day the entire audience arrives at once.

The National Bank of Ukraine’s online store for collector and commemorative coins, ⁠coins.bank.gov.ua, runs weekly sales that reach roughly 20,000 orders per hour under normal conditions.

That is already a heavier load than most retail stores will ever experience.

The real test comes during high-demand coin releases, when the store has had to withstand spikes of approximately:

• 6,000 orders per minute;

• 500,000 requests per minute.

That is flash-sale traffic compressed into a burst most sites were never designed to survive.

This level of load cannot be handled by scaling up after the problem appears. By the time a monitoring dashboard shows the spike, the damage has already happened.

Peak performance must be designed in from the beginning.

That includes:

Aggressive Caching

The origin server should not have to recalculate the same product, category, and stock data for every one of hundreds of thousands of requests.

Queuing and Waiting-Room Mechanics

A sudden burst of demand should become an orderly queue rather than an uncontrolled crash.

A Minimal Checkout Path

Checkout should contain only what is necessary to complete the transaction.

Every unnecessary script, widget, or synchronous request becomes a potential failure point multiplied by hundreds of thousands of concurrent shoppers.

This discipline is not glamorous. Most of it involves refusing to add unnecessary weight to the pages carrying the most load.

But that is the difference between a sale that sells out cleanly and one that goes offline in the first sixty seconds.

Measure It Before You Take Our Word for It

Measure your checkout on a mid-range Android this week.

If it is slow, we can run a full path-to-purchase speed audit.