What Every Slow Second Actually Costs You in Revenue

Performance work has a funding problem. It rarely makes the roadmap because it is hard to point at and say "this earned us money." A new feature has a champion and a demo. A half-second of load time saved has neither, so it loses every prioritization meeting to something flashier, and the site stays slow because slow never has an advocate in the room.

That framing is wrong, and the data has gotten clear enough to fix it. Page speed is not a technical nicety. It is a direct input to bounce, conversion, and revenue, and the relationship is measurable enough that you can put a dollar figure on a second of delay. Once speed has a number attached, it stops being the thing that loses to features and starts being the feature with the best return.

What the slow second actually does to your funnel

Start with the human behavior, because everything downstream follows from it. People have decided how long they will wait, and the answer is short. Around 47 percent of users expect a page to load in two seconds or less. Past that, they start leaving, and the leaving accelerates fast.

The bounce curve is steep. As load time climbs from one second to three, the probability that a visitor bounces rises by about 32 percent. Push it to five seconds and bounce probability roughly doubles. A 2025 web performance index analyzing over 500 million visits across more than 1,300 ecommerce sites found that 63 percent of visitors bounce from pages that take over four seconds to load. Almost two thirds of the traffic you paid to acquire walks out before the page finishes, and they walk out before they have seen a single thing you wanted to sell them.

Bounce is the visible loss. The quieter loss is in the visitors who stay but convert less. Every 100 milliseconds of load time costs roughly one percent in conversions. A one-second delay reduces conversions by about seven percent. These are not edge numbers from a single outlier study, they are the consistent shape across years of measurement: speed and conversion move together, and the slope is steep enough to matter to your P&L.

Put it in money, because that is the language of the roadmap

Abstractions lose budget fights. Dollars win them. So translate.

Take a business earning 100,000 dollars a month. A single second of additional load time, at the seven-percent conversion hit, costs about 84,000 dollars a year. Not a rounding error. A salary. For a larger ecommerce operation doing 10 million a year, a 500-millisecond improvement in load time translates to roughly 500,000 dollars in recovered revenue. Half a second, half a million.

The exercise is simple and you should run it on your own numbers before the next planning cycle. Take your monthly revenue, your current load time, and the conversion-per-100ms relationship, and compute what your current speed is costing you against a faster target. The number that comes out is usually large enough to reorder the roadmap on its own, because it reframes the performance ticket from "engineering wants to clean something up" to "this recovers six figures a year." That is the version of the pitch that survives the meeting.

Core Web Vitals are the metrics that map to behavior

To improve speed you have to measure the right thing, and Google's Core Web Vitals are the closest standard metrics to what users actually feel. There are three, and each maps to a distinct frustration:

• Largest Contentful Paint (LCP) measures when the main content paints. This is "is the page here yet," the metric the bounce curve is most sensitive to, and it is usually fixed by making your LCP image load first every single time.
• Interaction to Next Paint (INP) measures how quickly the page responds to a tap or click. This is "did it react when I touched it," and it is where a page can hit good load times yet still feel broken under a thumb. Cutting your INP below 200ms is what closes that gap.
• Cumulative Layout Shift (CLS) measures how much the layout jumps as things load. This is the button that moves the instant you reach for it, the source of mis-taps and abandoned forms, which is why driving cumulative layout shift to zero on dynamic pages directly recovers conversions.

The reason these matter commercially is the link to behavior. Websites that pass all three see, on average, around 24 percent lower bounce rates than those that fail. And the wins compound through the funnel: when RedBus improved its INP, it saw a 7 percent increase in sales, purely from making interactions feel responsive.

Here is the uncomfortable part. Only about 42 percent of mobile sites pass all three Core Web Vitals. Desktop is better at around 63 percent, but mobile is where the money is, since mobile now accounts for roughly 62 percent of ecommerce traffic. So the majority of sites are failing the metrics on the device where the majority of buying happens. That gap is not a problem, it is an opportunity, because your competitors are mostly failing it too.

Where the speed actually comes from

The platform you build on stacks the deck before you write a line of optimization code. Next.js sites pass Core Web Vitals at around 58 percent versus WordPress at around 38 percent, and the difference is architectural: code splitting so users download only what the page needs, server components that ship zero JavaScript for the static parts, image optimization so a hero image is not a multi-megabyte download, and server-side rendering so the content arrives ready rather than assembled in the browser after the fact.

This is why we default the websites and web applications we build to a framework that gives you those advantages by construction rather than fighting a slow platform with plugins later. The biggest performance gains are usually structural, and structure is decided early.

Beyond the platform, the durable wins are the ordinary ones done consistently. Serve images in modern formats at the size they render with an image pipeline that serves the perfect byte count. Break up long tasks so the main thread stays responsive to taps. Cache aggressively at the edge so a returning visitor and a distant one both get a fast first byte. Eliminate layout shift by reserving space for anything that loads in. None of it is exotic. The reason most sites are slow is not that the fixes are hard, it is that nobody put a revenue number on doing them, so they never got prioritized.

Measure in the field, not just the lab

One trap will mislead you if you let it. A synthetic test on a fast machine over office wifi tells you the page can be fast. It does not tell you whether it is fast for the person on a three-year-old phone on a patchy mobile connection, which is the person whose money you are trying to earn. This is exactly why your Lighthouse score lies and field data tells the truth. Track Core Web Vitals from real users in the field, segmented by device and connection, because the field numbers are the ones that correlate with the bounce and conversion data above. Optimizing the lab number while the field number stays bad is how teams "fix performance" and watch conversions not move. And remember the cheapest gains are perceptual: even where the raw timing is fixed, making slow feel fast with optimistic UI and smart skeletons buys back the trust a stalled screen spends.

The case writes itself

Performance loses the roadmap fight when it shows up as a vague cleanup request. It wins when it shows up as a revenue calculation. The relationships are well measured: a second of delay costs roughly seven percent of conversions, passing Core Web Vitals cuts bounce by about a quarter, and most of your competitors are failing the mobile metrics where most buying happens.

Run the math on your own traffic and revenue, and you will almost certainly find that the speed you are leaving on the table is worth more than the next feature in the backlog. The slow second is not free. It has a price, you are paying it every day, and now you can put it on a slide.