Every CRO deck has the same slide: page speed correlates with conversion rate, here's a chart, ship faster. That relationship is real, but the way it gets used in practice — as a blanket mandate to chase every last millisecond off load time — misreads what the data actually shows. Speed and conversion rate have a relationship with diminishing returns and a floor beneath which further speed gains stop mattering, and most teams pouring engineering hours into shaving another 200 milliseconds off an already-fast page are optimizing well past the point of any measurable return.

The teams getting this right treat speed as a threshold to clear, not a number to minimize indefinitely. The teams getting it wrong treat every millisecond as equally valuable, which misallocates real engineering time away from conversion levers that would move the number more.

Where Speed Actually Costs You Conversions

The steepest part of the speed-to-conversion curve is at the slow end, not the fast end. Going from a 6-second load time to 3 seconds recovers real, measurable conversion rate in the majority of tests — this is the range where speed is genuinely costing you users who bail before the page finishes rendering. Below roughly 2-3 seconds, the marginal conversion gain from further speed improvements drops off sharply in most conversion contexts, because you've already retained the users who were speed-sensitive enough to leave.

This isn't a universal law — high-intent, low-consideration transactional pages (checkout flows, form submissions on paid traffic) are more speed-sensitive at the margin than a content-heavy consideration page a user is willing to sit with. But the general shape holds across most verticals we've tested: the first two seconds of improvement matter far more than the next two.

The Metric That Matters More Than Raw Load Time

Total load time is a poor proxy for what actually affects a user's decision to stay or leave. Largest Contentful Paint — how long it takes the largest visible element to render — and Interaction to Next Paint — how responsive the page feels once a user starts interacting with it — correlate more directly with conversion behavior than a raw page-fully-loaded timestamp, because they measure what the user actually experiences rather than a technical completion event happening after the user has already formed an impression.

A page that hits a strong LCP score at 1.8 seconds but keeps loading background scripts for another three seconds after that will convert closer to a fast page than a slow one, because the user's perception of speed is set by what they see and can act on, not by when the network tab finishes.

The Tradeoff Nobody Measures

Here's the part most teams skip: speed optimizations often trade against the exact elements that drive conversion. Reducing image quality to hit a faster LCP can hurt trust and product perception on an e-commerce page. Stripping social proof widgets, review counts, or trust badges to cut render-blocking scripts removes conversion drivers to chase a speed metric. Lazy-loading everything below the fold can delay the appearance of a compelling second CTA that would have caught a scrolling user.

A faster page that converts worse is not a win, no matter what the Lighthouse score says.

The fix isn't to ignore speed — it's to test speed changes against conversion rate directly, not against a speed score in isolation. A/B test the leaner, faster version against the current page on actual conversion rate, not just Core Web Vitals scores, before rolling out a speed-motivated redesign site-wide.

How to Actually Prioritize This

1. **Benchmark current LCP and INP** against the 2-3 second range where most of the conversion recovery lives. If you're already inside that range, further speed work has a low expected return relative to other CRO levers.
2. **If you're outside that range, fix the biggest technical offenders first** — unoptimized hero images, render-blocking third-party scripts (chat widgets, non-essential tracking pixels, tag manager bloat), and unnecessarily large JavaScript bundles. These typically account for the majority of slow-page problems and are the highest-leverage fixes.
3. **Never cut a conversion element to hit a speed number** without testing the tradeoff directly. Trust badges, reviews, and clear CTAs frequently earn back more conversion than the speed penalty of loading them costs.
4. **Re-test conversion rate, not just speed score, after every change.** A Lighthouse score improving is not the goal. Conversion rate improving is the goal, and they are not the same metric even though they're correlated.

Page speed matters, and a genuinely slow page is bleeding conversions in a way that's cheap to fix and easy to justify. But past the point where your page loads in a reasonable window, the highest-leverage CRO work has moved on to headlines, offers, and trust signals — and no amount of shaving milliseconds off an already-fast page will make up for a weak value proposition above the fold.