There’s a conversation almost every site owner has had with a developer and walked away unsatisfied. “Your site is slow.” “Okay, but how much does that cost me?” And then comes the answer that convinces no one: “it improves the experience.” Experience is abstract. Revenue is concrete. As long as slowness doesn’t become a number in dollars, it always stays at the bottom of the priority list — behind the new banner and this month’s promotion.
This post is here to close that gap. Site speed does have a measured link to revenue — and you can estimate what your slowness costs per month with a simple model. We’ll also separate what actually moves the needle (the metrics the user feels) from the theater of a pretty PageSpeed score. Because optimizing for the wrong number is spending energy without seeing money.
Speed and conversion: what the data shows
Core Web Vitals are the three metrics Google uses to measure the real experience of using a page: loading speed, interaction responsiveness and visual stability. They exist because the loading experience has a direct, measurable effect on the people who buy.
The most cited — and legitimate — data point comes from the Milliseconds Make Millions study, conducted by Deloitte at Google’s request. It covered 37 retail, travel and luxury brands, and more than 30 million mobile sessions analyzed. The result is uncomfortable for how small the trigger is:
| Sector | Gain from just 0.1s faster (mobile) |
|---|---|
| Retail | +8.4% conversion, +9.2% average order value |
| Travel | +10.1% conversion, +1.9% average order value |
| Luxury | +40.1% in progression to “add to cart” |
Read that again: a tenth of a second. Not one second, not five. Your site’s slowness doesn’t have to be glaring to cost money — it drains conversion silently, one millisecond at a time.
What your slowness costs per month
You don’t need Deloitte’s study to estimate your case. You need three numbers you already have in analytics and a napkin calculation:
- Visitors/month on the page that matters (e.g., 40,000).
- Current conversion rate (e.g., 2% → 800 conversions).
- Average value per conversion (e.g., $150 → $120,000/month).
Now assume, conservatively, that fixing the slowness recovers 5% of conversion — well below the retail study’s 8.4%. That means 40 more conversions per month, or $6,000 monthly. $72,000 a year left on the table. And that’s the timid scenario.
The goal of the model isn’t lab precision — it’s to move performance out of the “abstract” column and into the “this pays for the two-week optimization project” column. When the conversation becomes a number, prioritization changes on its own. It’s the same logic we apply to tying product and revenue together in web performance and conversion: a technical decision justified by money, not by taste.
The three metrics the user feels
Since March 2024, Google consolidated Core Web Vitals into three metrics — and swapped one of them. The old FID is out; INP came in, measuring interaction responsiveness far more completely (official announcement on web.dev). The current trio, with Google’s thresholds:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | When the main content appears | ≤ 2.5s | > 4.0s |
| INP (Interaction to Next Paint) | How fast the page responds to a click/tap | ≤ 200ms | > 500ms |
| CLS (Cumulative Layout Shift) | Stability — does the layout “jump”? | ≤ 0.1 | > 0.25 |
Notice each one covers a different moment of real frustration: LCP is the wait to see, INP is the wait to act, CLS is that jolt of clicking in the wrong place because the button moved. Optimizing performance means attacking these three annoyances — not chasing a single number.
LCP: the wait to see
A high LCP almost always has known culprits: a giant uncompressed image, a slow server on the first byte, or a font/CSS that blocks rendering. It’s the most visible metric and, in general, the best return to attack first in e-commerce and on landing pages.
INP: the wait to act
INP is the new metric and the one most tied to heavy JavaScript. When you click “add to cart” and nothing happens for half a second, that’s poor INP — the main thread is busy processing script instead of responding to you. Sites with lots of libraries and little care suffer here.
CLS: the layout that jumps
CLS is the cheapest to fix and the most neglected. The number one cause is an image or ad with no reserved dimension: the content loads, pushes the rest down, and the user taps the wrong place. Reserving space for media solves most of it.
Why the PageSpeed score misleads
Here’s the trap that makes teams optimize the wrong thing: the PageSpeed Insights score is a lab test. It simulates a device and a network in a controlled environment. It’s useful for diagnosis, but it’s not your users’ experience.
The data that truly matters is field data — CrUX (Chrome UX Report), which measures real users, with real phones, on real networks, at the 75th percentile. And it’s perfectly possible to have:
- A 95 in the lab and fail the field Core Web Vitals, because your users access from a mid-range phone on 4G, not from the test’s datacenter.
- A 70 and comfortably pass in the field, because the user base has better devices and connections than the simulation.
The real yardstick is applied to the 75th percentile of real users: the experience has to be good for the concrete majority who visit your site, not for the average nor for the lab. Chasing 100 on PageSpeed while the field stays red is optimizing the dashboard, not the business.
What actually moves the needle in a real stack
After measuring the field and finding the failing metric, the return comes from a handful of causes that repeat in nearly every project:
- Images. The web’s heaviest weight. Compress them, use modern formats, size them to the displayed dimension and set width/height so they don’t cause CLS.
- Too much JavaScript. Every “just for convenience” library costs INP. Less script, or script loaded on demand, responds faster to the user.
- Blocking fonts. A poorly configured custom font stalls rendering and worsens LCP. Load it with a strategy and set a fallback.
- A slow server on the first byte. Cache, a CDN and a backend that responds fast cut the baseline of every metric.
- Reserve space for media and ads. Fixes CLS almost for free.
The discipline point: prioritize the page that generates revenue. Home, product page and checkout first. Optimizing an institutional page nobody converts on while the checkout drags is spending effort far from the money. That scoping logic is the same one we argue for in MVP from zero to production — solve what moves the needle before polishing the rest.
A warning about shortcuts: performance built in a rush, stacking a cache plugin and a “magic optimizer” without understanding the cause, tends to charge the bill later. It’s the same risk of shipping code carelessly that we describe in vibe coding: don’t ship a weekend project — it works in testing and collapses under real traffic. And every extra layer you add to “speed things up” is one more thing that can break in production; the risks of shipping apps to production apply to the performance stack too. The solid gain comes from attacking the cause — image, script, server — not from masking the symptom.
And where does SEO fit in all this?
Yes, Core Web Vitals is a Google ranking signal. But it’s honest to say: it’s not the strongest signal. Relevant content and authority weigh more. If your site is slow and has weak content, performance won’t save the ranking.
The biggest return from speed isn’t in SEO — it’s in conversion. Less abandonment during the wait, more pages per session, a checkout that completes instead of stalling. The search gain is a pleasant bonus, not the reason. Teams that invert this order optimize for the robot and forget the human who pays the bill. It’s worth cross-reading this with the ongoing site maintenance we discuss in ongoing WordPress maintenance: performance isn’t a one-off project, it’s recurring hygiene.
A four-step attack plan
To get out of theory without getting lost:
- Measure the field. Open Search Console and CrUX. Find which of the three metrics is in the red for real users — don’t trust the lab score alone.
- Calculate the cost. Run the napkin model with your numbers. Turn slowness into dollars/month to justify the priority.
- Attack the cause, on the right page. Start with the page that generates revenue and the dominant cause (almost always image or JavaScript).
- Re-measure and monitor. Performance regresses over time — every plugin, marketing script and new image erodes the gain. Treat it as continuous follow-up.
If you want to turn this into results — from the field diagnosis to the fix on the page that earns — it’s exactly the kind of work we do in web development. The yardstick is never the pretty score: it’s conversion going up and slowness that stops costing.
Frequently asked questions
Does site speed really affect sales?
Yes, and there’s field data to prove it. The “Milliseconds Make Millions” study, by Deloitte with Google, measured 37 brands and more than 30 million sessions: an improvement of just 0.1 seconds on mobile raised conversion in retail by 8.4% and in travel by 10.1%. Speed isn’t technical vanity — it’s revenue.
What are Core Web Vitals?
They’re three Google metrics that measure the real usage experience: LCP (loading speed of the main content), INP (response to user interaction) and CLS (visual stability of the layout). Since March 2024, INP replaced the old FID. They’re measured with real users, not in a lab.
What’s the difference between the PageSpeed score and field data?
The PageSpeed Insights score comes from a lab test, in a simulated environment. Field data (CrUX) comes from real users on your site, with real devices and networks. It’s possible to score 90 in the lab and fail the field Core Web Vitals. The real experience is what counts for conversion and for search.
What is a good LCP, INP and CLS?
According to Google: a good LCP is up to 2.5 seconds; a good INP is up to 200 milliseconds; and a good CLS is up to 0.1. Above that there are “needs improvement” and “poor” bands. The yardstick is applied to the 75th percentile of your real users — that is, the experience has to be good for the majority, not just on average.
Does improving performance help with Google?
It helps, but with realistic weight. Core Web Vitals are a ranking signal, and not the strongest one — content and relevance weigh more. In practice, the biggest return from performance comes from conversion: less abandonment, more pages per session and a checkout that completes. The SEO gain is a bonus, not the main reason.
Where do I start to improve my site’s speed?
Start by measuring the real field data (CrUX/Search Console) to know which metric is failing. Then attack the most common causes: heavy images with no defined dimension, excess JavaScript and fonts that block rendering. Prioritize the page that generates revenue — home, product or checkout — before optimizing the whole site.