Performance work competes for engineering time against features with revenue numbers attached, and it usually loses. When it does get pitched, the pitch tends to lean on the weakest part of the case — "speed is a ranking factor" — and prop it up with borrowed statistics from vendor studies. A CFO who asks two follow-up questions will find the seams.
The honest case is stronger than the inflated one, but it requires separating two effects that most pitches blur together.
Two effects, two very different sizes
Speed can affect revenue through search rankings, and it can affect revenue through the behavior of visitors you already have. These are independent mechanisms with independent evidence, and they deserve independent estimates.
The ranking effect is documented but modest. The conversion effect is where the money usually is — but it has to be estimated from your own data, because the industry numbers that circulate are unusable for a forecast.
What the ranking effect is actually worth
The documentation is clear about existence and equally clear about magnitude. Google announced site speed as a ranking factor for desktop in 2010, extended it to mobile with the Speed Update in 2018, and folded Core Web Vitals into ranking with the page experience rollout beginning in 2021. Alongside all of this, Google has consistently said that page experience signals carry less weight than content relevance, and its representatives have described the effect in tiebreaker-like terms — separating pages with otherwise similar content quality.
The practical implication: if you rank behind pages with clearly better content, performance work will not leapfrog them, and promising that it will is how SEO teams lose credibility. If you sit in a tightly contested cluster of comparable pages — position three to eight on commercial queries, say — a signal that breaks ties is plausibly worth something. Frame it exactly that way: real, documented, small, and conditional.
Then decline to put a precise revenue number on it. A ranking-effect forecast requires predicting position changes, which nobody can do honestly. State it as qualitative upside on top of the quantified conversion case.
Why industry studies can't be your forecast
The conversion side of the pitch is usually decorated with figures of the form "an X-millisecond improvement produced a Y% conversion lift at some large company." Studies reporting results like this exist and are directionally consistent — faster experiences convert better, and the relationship shows up across many published retailer and vendor analyses. But three problems make them useless as your forecast:
- Selection bias. Companies publish speed case studies when the results are good. The failures are not blogged.
- Non-transferability. The effect size depends on where the site started, what was fixed, and how close users are to a purchase decision. None of that transfers from a case study to your site.
- Diminishing returns. Going from a nine-second load to three seconds is a different intervention from going from three to two. Borrowed numbers rarely say where on the curve they were measured.
Cite the direction from published work. Build the magnitude from your own analytics.
Building an estimate from your own data
You almost certainly already collect what you need: real-user performance data (Core Web Vitals from the field, or your RUM tool) joined with conversion outcomes per session.
Step one: bucket sessions by experienced speed. Take a metric like LCP, bucket sessions (fast, moderate, slow), and compute conversion rate per bucket. You will very likely see slower buckets converting worse.
Step two: fight the confounding before your CFO does. This is the step that separates a defensible estimate from a laughed-at one. Slow sessions differ from fast ones in ways that independently predict conversion: older devices, worse networks, different geographies and income levels, different pages visited. The raw gap between buckets overstates the causal effect of speed — some of it is the device and the person, not the milliseconds. Control for what you can: compare within device class, within geography, within landing-page template. The gap that survives those controls is your defensible input.
Step three: model a partial migration, not a miracle. Your intervention moves some share of sessions from slower buckets to faster ones. Estimate that share from lab testing of the planned fixes, apply the controlled conversion-rate difference, and multiply through to revenue. Present it as a range — a conservative case assuming half the modeled migration and effect, and a central case — never a point estimate.
Step four: state the assumptions on the slide. Which controls you applied, what share of the raw correlation you kept, what migration you assumed. An estimate that discloses its own weaknesses invites adjustment; one that hides them invites dismissal.
The costs a CFO will actually ask about
The revenue side is only half the case. Expect, and pre-empt, questions on: the engineering time displaced and what it would have built instead; whether the gains persist or regress as new features ship (they regress without guardrails — budget for performance budgets and CI checks, not a one-time fix); and how the result will be verified after launch. Committing to a post-launch readout against the same buckets you used for the estimate is the single most credibility-building thing you can offer.
What to do
- Split the pitch in two: a quantified conversion case from your own data, plus a qualitative, documented ranking case — never a merged number.
- Run the bucket analysis this week. Field CWV data joined to conversions, controlled at minimum for device class and geography.
- Keep industry case studies for direction only. The moment a borrowed percentage enters your revenue math, the case is fragile.
- Present a range with visible assumptions, including how much of the raw correlation you discounted for confounding.
- Include the maintenance cost — performance budgets and regression checks in CI — so the estimate covers keeping the gains, not just getting them.
- Commit to a post-launch measurement against the same methodology, and report it whether or not it flatters the forecast.