Skip to content
Sellarix

The Real Cost of a Slow Store: Core Web Vitals and Conversion

Last year I watched a founder lose a sale in real time. We were on a call, screen-sharing her store on her actual phone, on actual hotel wifi. She...

The Sellarix team · 26 Mar 2026 · 7 min read

Last year I watched a founder lose a sale in real time. We were on a call, screen-sharing her store on her actual phone, on actual hotel wifi. She tapped a product, the hero image hung for a beat, the page jumped as a banner loaded in late, her thumb landed on the wrong thing, and she sighed and said "see, it does this." That sigh is the whole problem. She wasn't even a customer. She was the owner, and she'd already given up. I run growth experiments on ecommerce stores for a living, and I've stopped treating speed as a developer hygiene thing. It's a revenue line. The frustrating part is that most operators can't see it, because the people who bounce off a slow store never show up in your analytics as a complaint. They just don't convert, and you blame the price or the product or the season. So let me make the cost concrete, explain the three metrics Google actually grades you on without the jargon, and then walk through the real ways to fix it, because some of the popular fixes are mostly theater.

What slow actually costs you

The number I keep coming back to is from the Deloitte and Google study Milliseconds Make Millions. They instrumented 37 retail, travel, luxury and lead-gen sites, watching mobile load times across roughly 30 million-plus user sessions over a month. Then they looked at what happened when a site got just 0.1 seconds faster. Not one second. One tenth of one second. For retail, conversions went up 8.4% and average order value went up 9.2%. Travel conversions climbed 10.1%. Luxury saw 8.6% more page views per session. (web.dev case study; full report PDF)

Chart: percentage business uplift from a 0.1-second faster mobile load, by vertical, from the Deloitte and Google Milliseconds Make Millions study
Chart by author. Source: Deloitte Digital, fifty-five and Google, Milliseconds Make Millions, 2020. The same research found a human reason behind the numbers. Beyond about one second of waiting, people lose focus on the task they were doing. And when shoppers hit a site that's slower than they expected, 45% said they're less likely to buy and 35% said they're less likely to come back. (report PDF) That second number is the killer, because it means a slow first visit poisons the customer you paid an ad to acquire. Google's own benchmark work points the same way: as mobile page load goes from 1s to 3s, the probability of a bounce rises sharply, and it keeps climbing from there. (Think with Google, mobile speed benchmarks) I treat these as directional, not a promise for your exact store, but the direction has been consistent for years.

LCP, INP and CLS, in plain language

Google grades the loading experience with three Core Web Vitals. Here's what each one actually means to a shopper. LCP, Largest Contentful Paint. How long until the biggest thing on screen, usually your hero image or product photo, has actually painted. This is the "is it loading or is it broken" feeling. Good is under 2.5 seconds. INP, Interaction to Next Paint. When someone taps add-to-cart or opens a menu, how long until the page visibly responds. This replaced the old First Input Delay metric on March 12, 2024, and it's stricter because it looks at interactions across the whole visit, not just the first tap. Good is under 200 milliseconds. (web.dev, INP becomes a Core Web Vital) CLS, Cumulative Layout Shift. How much the page jumps around while it loads. This is the late banner that shoves the buy button under your thumb. It's measured as a unitless score, and good is under 0.1. (web.dev, Core Web Vitals thresholds) Google considers a page "good" when the 75th percentile of your real visitors meets all three thresholds. (web.dev) That 75th-percentile bit matters: your fast laptop on office fiber is not the test. The test is your customer on a mid-range phone three years old. Where do you read your real numbers? The Chrome User Experience Report is the field data Google actually uses, surfaced inside PageSpeed Insights and Search Console. Lighthouse and the in-browser DevTools give you lab numbers for debugging. Use field data to decide if you have a problem, lab data to chase the cause.

How to actually fix it

This is where money gets spent badly. Every option below can help, but they fix different things, and the order you do them in matters. Here's how I weigh them.

Approach What it fixes best Cost / effort The catch
Theme & code fixes LCP and CLS: lazy-load below-the-fold, preload the hero, set image dimensions, defer scripts Low to medium, mostly time Needs someone who can edit the theme; easy to break things without staging
Cutting apps & third-party scripts INP and LCP: every chat, review, popup and tracker adds JS Low cost, some political pain You have to say no to features; measure before/after with field data
CDN & image tooling LCP and global consistency: cache near the user, serve WebP/AVIF, right-size images Low, often built into your platform Doesn't fix bloated JS or layout shift; not a silver bullet
Headless rebuild Everything, with full control over rendering High: months, real budget, a dev team Massive overkill for most stores; you can usually hit "good" without it

My honest take: most stores are slow because of too many apps and unoptimized images, not because they need a headless rebuild. I've seen stores shave a second off LCP just by removing three apps the owner forgot were installed and compressing a 2MB hero down to 200KB. Start there. It's free. The app pruning is the one people resist most, because each app felt useful when they added it. But every third-party script is code you don't control running on your customer's phone, and third-party JavaScript is one of the most common INP killers. The web.dev guidance on optimizing INP is blunt about long tasks blocking the main thread, and most long tasks on a typical store come from apps. CDN and image tooling are the easy structural win. Modern formats like AVIF and WebP can cut image weight dramatically, and serving from an edge cache means your shopper in Manila isn't pulling bytes from a server in Virginia. If your platform does this for you, lucky you. If you're stitching it together with apps, that's worth consolidating onto a platform that handles speed natively rather than bolting on yet another script. Full disclosure, I work in this space and Sellarix is an all-in-one platform built partly to avoid the app-sprawl problem, so weigh that accordingly. Headless is real and powerful, but I only recommend it when you've genuinely outgrown your platform and have engineers to maintain it. Going headless to fix speed is like buying a race car to avoid traffic. Sometimes right, usually not.

A shopper completing an online purchase on a laptop with a bank card in hand
Photo: Bogdan Hoyaux / European Commission, licensed CC BY 4.0. Source: Wikimedia Commons.

So what would I do Monday morning

Run your top three landing pages through PageSpeed Insights on the mobile tab and read the field data, not the lab score. If LCP is the red one, look at your hero image and your server response. If INP is bad, open the app list and start cutting. If CLS is the problem, you've got something loading in late and shoving content around, usually an ad slot, a font, or a cookie banner without reserved space. Then re-measure in the field a few weeks later, because CrUX is a 28-day rolling window and won't move overnight. Speed work is unglamorous and it compounds quietly. Nobody tweets that your store felt fast. They just buy. Here's the question I'd leave you with: if a tenth of a second was worth 8% more conversions in that study, how many tenths is your store currently giving away, and have you ever actually looked?

Sources

Replace six tools with one

Join the waitlist to be first on the platform, or book a demo.

Join the waitlistBook a demo