Page Speed and Revenue: What the Person-Level Data Shows

A.Where those figures actually come from

The canonical page-speed statistics in circulation come from a small number of large retailers and platform vendors publishing their own results, often a decade ago, usually without the sample size or the confidence interval, and always about a specific site with a specific audience.

None of that makes them false. It makes them uninterpretable as a coefficient for your business. A one-second improvement on a mobile checkout for an impulse-purchase retailer and a one-second improvement on a B2B documentation page are not the same intervention and should not be expected to produce the same result.

Cite them to justify measuring. Never cite them to justify a forecast.

B.The confound that ruins the naive analysis

Here is the trap, and almost everyone falls into it the first time. You split sessions into fast and slow, compare conversion rates, find slow converts far worse, and conclude that speed costs you money.

But slow sessions are not a random sample. They are disproportionately mobile, on worse connections, in worse locations, arriving from channels that skew toward casual browsing. Every one of those factors independently reduces conversion. You have measured the composition of the slow group, and speed is somewhere inside that measurement, mixed with three other things.

A.Record the timing as a property on the person

The mechanism is simple, with one thing to decide first: you need an event that fires on load to hang the timing on. Most sites already have one, or add one. Capture the load timing as a property of that event, so it lives alongside everything else that person did rather than in a separate performance tool nobody joins to revenue.

Bucket it rather than storing raw milliseconds. Under 1s, 1 to 2.5s, 2.5 to 4s, over 4s is enough resolution for a decision and much easier to segment on. Store device class and connection type on the same event while you are there, because you will need both to de-confound the comparison.

B.Compare within segment, never across

Now the comparison that actually means something. Take mobile visitors from organic search, and only those. Split them by load bucket. Compare conversion.

If the difference persists inside a single device class and a single traffic source, you are looking at something much closer to a speed effect. If it collapses, you were looking at the mobile penalty all along and speed work will not recover it.

C.Follow the person, because bounce is not the outcome

The other half of the naive analysis is the outcome variable. Most speed studies stop at bounce rate, which is the easiest thing to measure and among the least informative.

A visitor who hits a slow page, leaves, and returns two days later on a faster connection to buy has bounced and has also become a customer. Counting that as a loss overstates the damage. Conversely a visitor who tolerated the slow page, browsed, and never came back is counted as engaged.

Measuring against revenue per person rather than bounce per session fixes both. It also surfaces the finding that changes priorities most often: slow pages frequently do not lose the sale, they delay it, and a delayed sale is a much cheaper problem than a lost one. The same distinction runs through what bounce rate actually measures.

A.Fix the pages that carry money, in order

Rank your pages by revenue influenced rather than by traffic or by how bad the score is. A slow blog post costs you very little. A checkout step that is slow on mobile costs you a proportion of everything downstream of it.

This is the single most common misallocation in performance work: teams optimise the homepage because it is the most visited page and the most visible internally, when the money sits three steps deeper on a template nobody looks at.

B.The returns curve, and the stopping rule

The relationship between load time and conversion is not linear. Going from 8 seconds to 4 is transformative. Going from 1.2 to 0.9 is usually undetectable in revenue and expensive in engineering time.

Set the stopping rule before you start. Something like: we stop when the revenue-carrying pages are under 2.5 seconds at the 75th percentile on mobile, and we do not resume until a measurement says we regressed. Without that rule, page speed becomes a permanent workstream because there is always another 100 milliseconds available.

C.Making the measurement possible at all

Everything above depends on one capability: load timing recorded as a property on an event, joined to the same person who later paid, across sessions and devices. Performance monitoring tools measure the first part beautifully and cannot do the join. Analytics tools do the join and usually do not capture the timing.

Kissmetrics takes custom properties on any event and resolves them all to a person, so once you have an event firing on load, its timing bucket, the device class and the eventual revenue sit on one record. That is what lets you ask whether the slow visitors came back, which is the question that decides whether this is an emergency or a nuisance.