The short answer
- The decision: Whether to fund a site-speed project now, or spend the same engineering weeks on other conversion work. Treat Core Web Vitals as a revenue line with an expected return, not a technical checklist to green.
- What a speed project is worth: Google and Deloitte measured that a 0.1-second mobile speed improvement lifted retail conversion rate by 8.4% and average order value by 9.2%. Rakuten 24 turned a full Core Web Vitals pass into a 33.13% conversion-rate increase and 53.37% more revenue per visitor. The money is real — but it concentrates in one specific place.
- When it's premature: If your mobile field data already passes all three thresholds, another speed sprint returns close to nothing. The conversion elasticity is steep while you are failing and nearly flat once you pass. Polishing 2.0s LCP to 1.5s is engineering vanity.
- Bottom line: Fund the speed project when your mobile field data (CrUX, not lab) fails at least one metric and the fix is scoped in weeks, not a re-platform. If you already pass, that budget earns more in checkout and product-page work.
Every performance guide treats Core Web Vitals the same way: here are three metrics, here are the thresholds, here is a checklist to turn them green. That framing is why speed projects get funded on the wrong stores and skipped on the right ones. Green is not the goal. Recovered revenue is the goal, and the two are not the same number.
This article reframes the decision. A speed project is a capital allocation — engineering weeks you could spend elsewhere. So the question is not "are we fast enough?" It is "what is the expected revenue return of this project at our traffic level, and does it beat the next-best use of the same hours?" That question has a defensible answer. Below is a model to size it, the specific offenders that move each metric, and a threshold for when speed work becomes premature polish.
How much does site speed actually move revenue?
The headline numbers are real and they come from named field studies, not vendor decks.
Google and Deloitte's Milliseconds Make Millions report analyzed mobile data from 37 retail, travel, and luxury brands. A 0.1-second improvement in mobile site speed lifted retail conversion rate by 8.4% and average order value by 9.2%. The steepest single jump was deep in the funnel — a 9.1% lift moving from product detail to add-to-basket — which tells you speed hurts most where intent is highest.
The case studies are more dramatic. Rakuten 24 ran an A/B test optimizing all three vitals and recorded a 33.13% conversion-rate increase, 53.37% more revenue per visitor, and a 15.20% higher average order value. redBus focused narrowly on interaction responsiveness, improved its INP by 72%, and saw a 7% overall increase in sales.
Now the part every checklist skips: you cannot extrapolate the Deloitte coefficient linearly. The 8.4%-per-100ms figure is a marginal elasticity measured near the threshold band. Multiplying it out — "we'll cut 1,000ms, so that's an 84% lift" — is fantasy math that will get your project killed the quarter after it ships and misses. The relationship flattens hard. Conversion is highly sensitive to speed while you are slow, and progressively indifferent once you are fast. Hold that shape in mind; it is the entire funding decision, and we return to it below.
The market context makes the case sharper. As of the July 2025 Chrome UX Report dataset, only about 48% of mobile origins passed all three Core Web Vitals. Roughly half of mobile commerce is still failing. If your store is in that half, you are leaking conversion to competitors who are not — and the fix is inside your codebase, not your ad budget.
What is INP, and why does it matter more in 2026?
In March 2024, Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital. This matters more than a metric swap. FID only measured the delay before the first interaction — a low bar most sites cleared by accident. INP measures responsiveness across every interaction in a session: every tap on add-to-cart, every variant selector, every filter toggle, every keystroke in search.
For commerce, that is the difference between a metric that flattered you and one that measures the moments where money changes hands. A slow first paint loses browsers. A sluggish add-to-cart loses buyers — people who had already decided. INP puts a number on the interactions that sit closest to revenue.
The gap concentrates on mobile, and inside third-party JavaScript. Mobile INP pass rates are actually the strongest of the three metrics — around 77% of origins record good INP — which means most stores that fail are failing on load speed (LCP), not responsiveness. But when INP does fail, the cause is almost always the same: heavy third-party scripts and long main-thread tasks. Every review app, chat widget, analytics tag, and personalization pixel competes for the same single thread that also has to respond to the shopper's tap. This is where INP overlaps with the compounding cost of eCommerce tech debt — each "just one more app" install is a small, permanent tax on responsiveness.
Two structural realities shape where to look. First, mobile is where most commerce traffic lives and where hardware is weakest, so the same script blocks the thread longer on a mid-range Android than on your MacBook — which is why lab tests on a developer machine lie. If you are still weighing how much of your experience should even live on the mobile web, that is a separate decision worth making deliberately. Second, the offenders differ by metric, and knowing which lever moves which number is what keeps a speed project scoped.
| Metric | Threshold (good) | Revenue lever | Common offender |
|---|---|---|---|
| LCP | <2.5s | Fewer bounces before the page is usable — first impression speed | Unoptimized hero images, render-blocking CSS/JS, slow server response (TTFB) |
| INP | <200ms | Trust in interaction — add-to-cart, filters, and variant taps feel instant | Heavy third-party scripts, long main-thread tasks, unoptimized event handlers |
| CLS | <0.1 | Fewer mis-taps — buttons do not jump as the page settles | Images and embeds without set dimensions, late-injected banners and ads, web fonts |
CLS deserves a specific note because operators under-weight it. A layout shift is not just ugly — on mobile it causes mis-taps, and a mis-tap on a size selector or a payment button is a lost or abandoned order. It also feeds back into INP: a shift triggered by a click delays the next paint, so a store with unstable layout often fails responsiveness too. The offenders are boring and cheap to fix — set explicit width and height on images and embeds, reserve space for anything injected after load. Boring and cheap is exactly the profile you want in a funded project.
Why the revenue is in the failing band, not the good band
Here is the non-obvious mechanism that decides whether your project pays back.
Conversion response to speed is not linear. It is closer to a curve that is steep in the failing band and flat in the good band. Moving mobile LCP from 4.0s to 2.5s — out of failing and into passing — sits on the steep part of that curve, which is why case studies that cross the threshold report double-digit conversion lifts. Moving LCP from 2.0s to 1.5s sits on the flat part. Both are "1,500ms" and "500ms" of work respectively, but only one of them touches revenue.
This is why the same speed sprint is a great investment on one store and a waste on another. It is not about how many milliseconds you save. It is about which part of the curve you save them on. A store failing at the 75th percentile has enormous upside because it is losing shoppers whose devices and connections put them past the point where the page feels broken. A store already passing has spent that upside; the marginal shopper already has a usable experience, and shaving another 400ms changes almost nothing they can feel.
Speed is a threshold good, not a linear good
How to size the return: a funding model for a speed project
Treat the speed project like any other investment: estimate the return, compare it to alternatives, decide. Here is a model you can run in a spreadsheet in twenty minutes.
Step 1 — Isolate the at-risk revenue. This is the annual revenue flowing through the surface that fails Core Web Vitals. For nearly every store that is mobile. Pull mobile's share of revenue (not sessions — revenue), because that is what is actually exposed.
At-risk revenue = Annual GMV × mobile share of revenue
Step 2 — Choose a bounded conversion-lift estimate. Do not extrapolate the Deloitte coefficient. Instead, anchor to what field case studies actually delivered when a store crossed the threshold, and pick a planning number inside that evidence range:
- Floor (single-metric fix, e.g. INP only): ~5–7% — the redBus range.
- Mid (two metrics into the passing band): ~10–15% — consistent with Deloitte's near-threshold elasticity applied conservatively.
- Ceiling (full pass, structurally re-worked page): up to ~33% — the Rakuten 24 result, achievable but usually requires a redesign, not a tune-up.
Plan on the floor or mid. If you build the business case on the ceiling, you are selling, not sizing.
Step 3 — Compute the expected annual lift.
Expected annual revenue lift = At-risk revenue × conversion-lift estimate
Step 4 — Net it against cost. Subtract the fully loaded engineering cost (developer weeks at real burdened rate, plus any monitoring tooling). What remains is your first-year net.
Worked example. A store doing $2.4M GMV, with 55% of revenue on mobile, failing LCP and CLS at the 75th percentile:
- At-risk revenue = $2.4M × 0.55 = $1.32M
- Conversion-lift estimate (two metrics, mid-case) = 10%
- Expected annual lift = $1.32M × 0.10 = $132,000
- Conservative check (floor, 5%) = $66,000
- Project cost = ~4 engineering weeks ≈ $30,000–$50,000
Even at the 5% floor, payback lands inside the first year, and every year after is compounding. Fund it. Now run the same store with all three metrics already passing on mobile: the honest lift estimate is 0–2%, expected annual return is $0–$26K against the same $30–50K cost, and the payback case collapses. Don't fund it — the money belongs elsewhere.
Key Takeaway
When is a speed project worth funding — and when is it premature?
The model produces a number, but three qualifiers decide the call. Fund the project when all three hold; if any fails, the money works harder elsewhere.
1. You fail at least one metric in the field, not the lab. Use Chrome UX Report data — real users at the 75th percentile — not a Lighthouse score on your laptop. Lab tools run on fast hardware and clean networks; they routinely show green while your actual mobile shoppers experience red. If you pass in the field, you have already captured the crossing, and this is the single most common reason a speed project returns nothing. Passing in lab but failing in field means fund it; failing in lab but passing in field means leave it alone.
2. The expected lift beats your next-best conversion project. Speed competes with other conversion work for the same hours, and some of that work has a higher ceiling. Baymard's research puts the achievable conversion gain from better checkout design at around 35% — often a bigger prize than a speed pass. Before funding speed, price the alternatives honestly: where product-page conversion work actually pays versus where it is theater, the recoverable share of checkout and cart abandonment, and the ROI of fixing on-site search and navigation. Fund whichever has the highest expected return per engineering week — sometimes that is speed, often it is not.
3. The fix is a tune-up, not a re-platform. Image optimization, deferring third-party scripts, reserving layout space, and fixing render-blocking resources are days-to-weeks of work with a clean payback. If the only way to pass is to rebuild the front end or leave your platform, that is a much larger decision with its own economics, and the speed argument alone will not carry it.
| Scenario | Mobile field status (CrUX, p75) | Expected conversion lift | Funding call |
|---|---|---|---|
| Failing LCP and CLS | 2 of 3 failing | ~10–15% (mid-case) | Fund — you are on the steep part of the curve |
| INP-only failure | 1 of 3 failing | ~5–7% (redBus range) | Fund if the fix is scoped in days, not a rebuild |
| All three passing | 0 of 3 failing | ~0–2% | Do not fund — premature polish; spend on checkout or PDP |
| Failing in lab, passing in field | 0 of 3 failing | ~0% | Do not fund — optimizing a number no user feels |
The two ways this project quietly wastes money
One measurement discipline underneath all of this: judge the project by revenue and by field-data pass rate, not by the conversion rate alone in the weeks after launch. Conversion rate moves for a dozen reasons — traffic mix, promotions, seasonality — and attributing every wiggle to your speed work is how good projects get wrongly declared failures. Instrument it the way you would any other change, and be honest about what the number is telling you, which is a discipline in itself — see why conversion rate is so often read as a vanity metric.
FAQ
Is a Lighthouse score of 90+ enough to skip a speed project?
No. Lighthouse is a lab tool running on fast hardware and a clean network. It can show green while your real mobile shoppers — on mid-range Android phones and mobile data — experience failing Core Web Vitals. The funding decision should be driven by field data from the Chrome UX Report at the 75th percentile, which reflects actual users. A high lab score with failing field data is a signal to fund; a low lab score with passing field data usually is not.
Which Core Web Vital should we fix first for the best revenue return?
Fix whichever one you are failing at the 75th percentile in field data, starting with LCP if you fail multiple. Load speed (LCP) is the most common failure point for commerce and sits closest to the bounce-before-usable problem. INP comes next because it governs the add-to-cart and filter interactions where buyers with intent are lost. CLS is usually the cheapest to fix and worth doing alongside the others because layout stability also feeds INP.
How do we estimate the revenue return before committing engineering time?
Multiply your at-risk revenue (annual GMV × mobile's share of revenue) by a conversion-lift estimate anchored to real case studies — roughly 5–7% for a single-metric fix, 10–15% for crossing two metrics into the passing band. Do not linearly extrapolate the "8.4% per 100ms" figure; it is a near-threshold elasticity that flattens, and using it as a straight-line multiplier will overstate the return badly.
We already pass all three vitals on mobile. Should we keep investing in speed?
Generally no. Conversion response to speed is steep while you are failing and nearly flat once you pass. Additional speed below the thresholds is real engineering work with close to zero conversion return. Redirect that budget to conversion work with a higher remaining ceiling — checkout, product-page, and on-site search improvements typically return more per engineering week once your vitals are green.
Do third-party apps really hurt performance enough to matter?
Yes, and they are the leading cause of poor INP on commerce sites. Every review widget, chat tool, analytics tag, and personalization script competes for the same main thread that must respond to a shopper's tap. Each install is a small, permanent responsiveness tax that compounds. Audit third-party scripts before assuming your own code is the problem — deferring or removing unused ones is often the highest-return, lowest-effort part of a speed project.
