Growth Notes

Performance and Conversion

Tags: web-dev commerce concept

Performance and Conversion

Date: 2026-08-16

Everyone quotes someone else’s number. Almost every published figure is correlational and none of them transfer — the useful move is estimating it on your own data, and knowing that even then you’ve measured an association rather than a cause.

What it is

The performance–conversion relationship is the change in conversion rate attributable to a change in page speed. It’s the number that funds performance work, and it’s the one most often borrowed rather than measured.

Why borrowed figures don’t transfer

“Every 100ms costs 1% of revenue” and its many variants get repeated as though they were constants. They aren’t:

  • They come from other businesses with different margins, categories, competitors and traffic mixes. A one-second delay matters differently for an impulse purchase than for a considered one
  • Most are correlational. Faster sessions convert better, but faster sessions are also on better devices, better connections, and in urban areas with more disposable income. The confound is the user, not the page — see Confounding Variables
  • They’re published by companies selling performance products, which is not disqualifying but is worth weighting
  • The relationship is non-linear. Going from 8s to 6s and from 2.4s to 2.2s are not the same intervention, and a single “per 100ms” figure implies they are

In plain terms: the fast visits in your analytics converted better partly because they were fast and partly because the people having them were different people. Any number derived by comparing them overstates the effect of speed.

Estimating it on your own data

Correlational, but yours — and far better than a borrowed constant. Requires Real User Monitoring joined to conversion.

bucket users by LCP, compare conversion within each bucket

  LCP bucket      sessions    conversions    CR
  < 1.5s            42,000        1,596     3.80%
  1.5 – 2.5s        68,000        2,244     3.30%
  2.5 – 4.0s        31,000          837     2.70%
  > 4.0s            19,000          361     1.90%

That gradient is real information — it tells you where the cliff is and which segment to prioritise. What it does not tell you is that moving the 2.5–4.0s group to under 1.5s would take them from 2.70% to 3.80%.

Two controls that materially improve the estimate:

  • Segment within device and connection type. Comparing fast and slow within mobile-on-4G removes the largest confounder
  • Compare within template. Product pages and category pages have different conversion rates and different speeds, so a site-wide bucket comparison partly measures template mix — Simpson’s Paradox

The only clean answer

An experiment. Randomly assign users to a slowed-down or sped-up experience and measure the difference — see Controlled Experiments.

  • Slowdown tests are the classic method: artificially delay a random arm. Ethically uncomfortable and commercially unattractive, but causally valid
  • Ship a real improvement behind a flag and measure it as a test. This is the practical version, and it’s what Rollouts as Experiments describes
  • Be honest about power. Performance changes move conversion by small amounts, and small effects need enormous samples — a 2% relative lift needs roughly 25 times the traffic of a 10% one. See Minimum Detectable Effect

That last point is the uncomfortable one: most sites cannot detect a genuine performance improvement in a single A/B test. The change is real and the test is underpowered. This is a legitimate case for shipping on judgement plus a holdout, rather than pretending an inconclusive test was a null result — Inconclusive Results.

Building the case anyway

You’ll need a number for a business case. An honest one looks like:

“Users seeing LCP under 1.5s convert at 3.80%; those between 2.5 and 4.0s convert at 2.70%. That gap is partly speed and partly who those users are, so treat it as an upper bound. If we moved half of the slow group and captured a third of the gap, that’s roughly £2,900 a year on this bucket alone.”

With the working shown, on annual figures:

31,000 sessions in the 2.5–4.0s bucket × 50% moved   = 15,500
gap 3.80% − 2.70% = 1.10pp, capture a third          ≈ 0.37pp
15,500 × 0.0037 = 57 extra orders × £50              ≈ £2,850

Note how small that is — and it’s the honest version. Applied across every slow bucket and every template it becomes a real number, but a single bucket on a mid-sized site does not fund a quarter of engineering time. Performance cases built on borrowed percentages routinely come out ten times larger than the same site’s own data supports, which is exactly why they don’t survive scrutiny. The arithmetic is less impressive than the headline and it’s the part that holds up when someone checks it.

The arguments that don’t need a number

Worth having in reserve, because they’re often stronger:

  • Bounce before measurement. Users who leave before the page renders never appear in your conversion data at all — the loss is invisible rather than small
  • Cumulative Layout Shift causes mistaps, which is a specific, observable failure rather than a statistical association
  • Interaction to Next Paint on checkout is a direct abandonment mechanism
  • Core Web Vitals as a ranking signal — modest, but free
  • Slow sites cost more to run. Server time and bandwidth are real

Graph View

Backlinks