How Much Online Store Performance Really Matters

A tenth of a second. That’s what moved retail conversion by 8.4% in the study Deloitte ran with Google and agency 55, measuring 30 million real sessions across 37 brands in Europe and the United States. In the same experiment, average order value rose 9.2% and the step from product page to cart rose 9.1%. Nobody redesigned anything during that period. Speed was simply measured hour by hour for thirty days.

That number is uncomfortable because it contradicts how most stores budget for performance, treating it as technical maintenance to handle when there’s time. Performance is a commercial lever with a price that’s already been measured. And almost everyone measures it wrong, watching a lab score Google doesn’t use for ranking while the number that actually counts, the one from their real visitors, goes somewhere else entirely.

1. What happens to a customer when your store is slow?

They leave before seeing the product, and the odds climb fast. Google’s research with SOASTA, from 2017, calculated that when load time goes from 1 to 3 seconds, the probability of a bounce rises 32%. From 1 to 5 seconds it rises 90%. From 1 to 6 seconds, 106%. From 1 to 10 seconds, 123%. The most expensive jump sits in those first two seconds, which is exactly where nobody looks.

Portent measured the other side of the same coin across more than 100 million page views. In ecommerce, sites loading in one second converted at 3.05%; at two seconds, 1.68%; at three, 1.12%; at four, 0.67%. A one second site converts 2.5 times better than a five second one.

What sits behind those numbers isn’t impatience. Someone waiting is paying with attention, and that wait reads as a signal about the quality of the business.

A slow store feels like a careless store, and the suspicion arrives right before they type a card number. The worst part is that the sale never shows up in any report, because the customer never got as far as attempting it.

2. What exactly does Google measure?

Google measures three things and calls them Core Web Vitals, at the 75th percentile of your visits. That percentile matters. Your grade comes from the visitor having a worse time than three quarters of your traffic, so a site that works well on fiber and badly on 4G fails, even when the average looks decent.

LCP, or Largest Contentful Paint, measures when the largest element in the first screen finishes painting. Good is 2.5 seconds or less. INP, or Interaction to Next Paint, measures how long the page takes to visually respond when someone taps something: good is 200 milliseconds or less. CLS, or Cumulative Layout Shift, measures how much content moves around while loading, and good is 0.1 or less.

If you still have FID written down, cross it out. It stopped being a Core Web Vital on March 12, 2024, when INP formally replaced it. The difference matters. FID only measured the first interaction and only its initial delay, while INP watches nearly every interaction in the visit and counts through to the screen actually changing.

3. Why isn’t your PageSpeed score the grade that counts?

Because Google doesn’t rank with that number. There are two kinds of data on the same screen and they get confused constantly. At the top sits field data, collected from real Chrome users through the Chrome UX Report over a rolling 28 day window. Below it sits the Lighthouse analysis, run on an emulated network and device. Chrome’s own documentation states that the Chrome UX Report is what informs the page experience ranking factor.

The PageSpeed Insights documentation carries a blunt warning: “having good lab data does not necessarily mean real-user experiences will also be good”. This happens often in stores with customers on patchy networks or mid-range phones, where the lab reports 92 and real people are waiting four seconds.

So what’s Lighthouse for? Diagnosis, and it’s excellent at it. It’s the tool that tells you which image is oversized and which script is blocking the main thread. Treat it as an X-ray. And with that clear, when someone sells you “we raised your score to 100”, you know what to ask about the field data.

4. Is performance still a ranking factor?

Google still says so in writing, on a page it updated in December 2025. The Search Central documentation carries the line: “Core Web Vitals are used by our ranking systems.” The same page clarifies that there’s no single page experience signal, and that its core ranking systems look at a variety of signals. What Google adds next is where the boundary sits: good results in Search Console reports or third party tools don’t guarantee your pages will rank at the top, and chasing a perfect score purely for SEO may not be the best use of your time. In plain terms, performance is one real factor among several, and a lightning fast store with thin content still won’t rank.

For a store, there’s a commercial angle that usually outweighs the ranking one. A slow store pays more for every purchased visit, because part of the click is lost before the page appears and paid traffic bills you either way.

5. What breaks LCP in a store, and how do you fix it?

It’s an image on 85.3% of desktop pages and 76% of mobile ones, according to the HTTP Archive Web Almanac 2025. In an online store that means the homepage banner or the main product photo, which is exactly the piece designers treat as untouchable.

LCP breaks down into four parts that web.dev defines with no gaps between them: time to first byte, the delay before the resource starts loading, how long it takes to download, and the delay before it paints. The guideline splits roughly 40% to first byte, under 10% to load delay, around 40% to download, and under 10% to render. These aren’t strict rules, and web.dev itself notes that if your LCP is already under 2.5 seconds the proportions don’t really matter. They tell you where to look.

The fixes that pay best are unglamorous. Serve the main image in a modern format at the size it actually occupies on screen, instead of a 3000 pixel photo shrunk by CSS. Strip lazy loading from that image. It sounds like an optimization, and in that one spot it’s a brake. Declare it high priority so the browser requests it before third party scripts. And if text is the largest thing in the first screen, preload the heading font.

6. What sits behind a bad INP?

Your JavaScript is holding the main thread while the customer is trying to tap something. INP measures three stretches: the delay before the interaction’s code starts running, how long that code takes, and the time until the browser paints the result. A single long task running is enough to blow up the first stretch, even when your own code is efficient.

Mobile falls apart right here. In the Web Almanac 2025 data, 97% of desktop sites have good INP against 77% on mobile. A mid-range phone takes several times longer than a laptop to interpret the same JavaScript, and in a store that code usually comes from the cart drawer, the predictive search, the collection filters, and the support chat.

The symptom store owners recognize is concrete. You tap “add to cart” and nothing happens for a long beat, so you tap again, and you end up with two units in the cart or an error message.

The same thing shows up in the size filter that takes a moment to register, or the menu that opens late. In none of those cases does the customer think “this store’s JavaScript is heavy”. They think the store is broken.

7. And CLS, the one that makes the page jump?

CLS measures how much visible content moves while loading, and it’s the easiest one to reproduce at home. Open your store on your phone, go to tap a product, and watch whether a banner drops in at the last moment and sends your thumb somewhere else. That’s CLS, and Google groups it into session windows: bursts of shifts separated by less than a second, capped at five seconds per window.

The causes web.dev documents repeat identically across stores. Images and videos without declared dimensions, which reserve zero space until they arrive. Ads, widgets, and third party elements that resize themselves. Fonts that load larger or smaller than the fallback and reflow the text.

On top of that comes everything injected above the content, which in a store is quite a lot. The free shipping bar, the cookie notice, the discount banner, the low stock warning. The fix is almost always reserving the space in advance: width and height declared on every image, and a fixed height container for the promotional banner. Adjust the fallback font too, so it takes up the same room as the real one.

8. What is each installed app costing you?

Every app you install usually brings scripts that load on all pages, even when its feature lives on only one. The review widget loads in the cart. The chat loads on the thank you page. The marketing pixel bundle loads always. And because the effect is cumulative and quiet, the store degrades without any single day looking like the culprit.

The figures circulating about this don’t survive scrutiny. You’ll see plenty of “each app adds 200 to 500 milliseconds”, but that number only appears on blogs run by companies selling optimization, with no methodology and no source behind it. What’s actually measured is the context. The Web Almanac 2025 documents that 90% or more of pages load at least one third party, and that among the top thousand sites the median sits around 129 third party requests on desktop and 106 on mobile.

An honest inventory takes an afternoon. List every installed app, write next to it what revenue or savings it produces, and measure the store before and after uninstalling the ones with no answer.

One detail costs real sales: disabling an app doesn’t always remove its code from the theme, because many leave embedded fragments that keep loading. Those have to come out by hand, and it’s part of the work we do when we audit a Shopify store.

9. What does the platform guarantee, and what is on you?

The platform gives you a floor. The ceiling is yours. Shopify, for instance, requires a theme to hit a minimum average Lighthouse performance score of 60 to enter its Theme Store, measured across the home, product, and collection pages, with a 16 KB cap on the minified JavaScript bundle. That’s a requirement for the clean theme, before you stack your apps, your content, and your scripts on top.

One distinction confuses a lot of people. The speed report in your Shopify admin doesn’t use Lighthouse at all. It’s calculated from real user data over the last 7 days, on the same three page types, reporting Core Web Vitals at the 75th percentile. The Theme Store requirement and your speed report measure different things, so comparing them tells you nothing.

What stays on your side is nearly everything that degrades over time. Images someone uploaded straight from a phone without optimizing, the twelve megabyte background video, the analytics scripts nobody has reviewed in a year, the sections that piled up on the homepage. A fast theme under a badly maintained store produces a slow site, and it’s the most common thing we see.

10. How much is actually there to gain? The cases with numbers

The cleanest evidence comes from A/B tests where speed was the only thing that changed. Vodafone Italy served half its visitors a version with better LCP, identical in design and features to the other, at roughly 100,000 clicks a day per variant. The fast version, with LCP 31% better, sold 8% more and improved its cart to visit ratio by 11%. Only one thing changed, so that 8% is caused by the speed.

Rakuten 24, the Japanese store, ran the same kind of test for a month while optimizing its Core Web Vitals. Revenue per visitor rose 53.37%, conversion 33.13%, and average order value 15.20%, while exit rate fell 35.12%. It’s the strongest pure ecommerce case published on web.dev.

Agrofy, the Argentine agribusiness marketplace, improved LCP by 70% and CLS by 72%, and abandonment during load dropped from 3.8% to 0.9%. That last number is the most telling of the set: three quarters of the people who used to leave before the page finished appearing stayed, without anyone touching the catalog or the prices.

Now, an honest warning about these figures. These are large stores that started from a serious problem, and a 53% lift in revenue per visitor assumes a fairly broken site to begin with. If your store already loads in two seconds, your margin looks more like Vodafone’s 8% than Rakuten’s 53%. That’s still money you aren’t collecting, but go in with the expectation calibrated.

11. How do you measure performance without fooling yourself?

Start with field data and leave the lab for later. Field data comes from your real visitors on their phones and their networks, and that rolling 28 day window has a practical consequence. A fix shipped today takes weeks to show fully, so judging it after three days tells you nothing.

Always measure by page type and by device. The homepage, the product page, and the collection page have different problems, and averaging the three hides exactly the one costing you money. Same with mobile: mixing it with desktop covers up the gap, and that gap exists across the whole web. In the Web Almanac 2025, 56% of desktop sites pass Core Web Vitals against 48% of mobile ones.

That failing half is your real benchmark. Being in the green already puts you in the better part of the web, so the reasonable goal is crossing the thresholds and staying there. A 100 changes no customer’s life. And measure one thing at a time, because if you switch themes and install two apps on the same day, the number moves without telling you why.

Where to start

For a store that’s already running, two fixes pay off from the first week: looking at mobile field data before any score, and fixing the main image on the homepage and the product page. Neither one requires redesigning anything.

The app inventory comes next, and it’s the uncomfortable one, because it forces you to defend each app with a number. It’s also where we usually find the biggest margin.

Then comes the deeper work, which pays more but demands consistency: reserving space for everything that loads late to kill CLS, and trimming the JavaScript that delays the cart and the search. And measuring again every time the store changes, which almost never happens and explains why a store optimized a year ago is slow again today.

If you want to know what your store’s speed is costing you right now, we’ll measure your field data and tell you where the leak is before touching anything. Get in touch and we’ll look at it together.

Frequently asked questions

How much does site speed actually affect online store sales?

It's been measured. The Deloitte study with Google and agency 55, covering 30 million sessions across 37 brands, found that a 0.1 second improvement raised retail conversion by 8.4% and average order value by 9.2%. In travel, conversion rose 10.1%. Tenths of a second with a direct effect on revenue.

What are Core Web Vitals and what counts as a good score?

They're the three metrics Google uses to measure page experience. LCP measures how long the main content takes to appear and should stay under 2.5 seconds. INP measures how fast the page responds when someone taps it and should stay under 200 milliseconds. CLS measures how much the layout shifts while loading and should stay under 0.1.

Does my Lighthouse or PageSpeed Insights score affect Google rankings?

Not directly. Google uses real user data collected through the Chrome UX Report, rather than the lab score shown in Lighthouse. The PageSpeed Insights documentation says it plainly: having good lab data doesn't necessarily mean real user experiences will also be good. Treat the score as a diagnostic tool.

Is performance still a ranking factor in 2026?

Yes. Google Search Central still states in writing that Core Web Vitals are used by its ranking systems. It also clarifies that chasing a perfect score purely for SEO may not be the best use of your time, since there's more to page experience than those three metrics. It's one real factor among several.

Why does my store perform well on desktop and badly on mobile?

Because the conditions are different. According to the HTTP Archive Web Almanac 2025, 56% of desktop sites pass Core Web Vitals versus only 48% on mobile, and the INP gap is enormous: 97% of desktop sites score well against 77% on mobile. Phones have less processing power and worse networks.

What is LCP and how do I improve it?

LCP measures when the largest element in the initial viewport finishes painting. On 76% of mobile pages that element is an image, according to the HTTP Archive, so the fix is almost always there: modern format, correct size for each screen, high fetch priority, and no lazy loading on the main image.

Do the apps I install slow my store down?

Each app usually adds scripts that load on every page, even when its feature lives on just one. There's no official figure for how many milliseconds each one costs, and you should distrust anyone who gives you one. What you can do is measure your store before and after installing, and properly remove what you stopped using.

How often should I check my store's performance?

A monthly review of your field data report is enough for a stable store, plus an extra measurement every time you install an app, change themes, or add a marketing script. Field data is calculated over a rolling 28 day window, so a change takes weeks to show up in full.