What a 0.8 second LCP is actually worth in revenue

Performance work is easy to justify with a chart and hard to justify with a budget. The gap between the two is that most performance arguments are made in milliseconds, and budgets are approved in revenue. Here is how to translate.

Start with your own field data, not a lab score

A lab score from a synthetic test tells you how one machine performed on one network on one run. It is useful for catching regressions and useless for estimating revenue. What you want is field data: real devices, real networks, real customers, segmented by template and by device class.

Take twelve weeks of field data before a change and twelve weeks after, split by template. Then join it to your own conversion data at the same granularity. The relationship you are looking for is not a global average. It is conversion rate by largest contentful paint bucket, for a single template, on a single device class.

What the numbers looked like on four storefronts

Across four storefronts we rebuilt between 2023 and 2026, all mid to large European retailers, the pattern was consistent enough to be useful and variable enough to be honest about.

Table. Conversion rate indexed to the fastest bucket at 100. Aggregated across four storefronts, mobile sessions, product detail template, twelve weeks.

Read that carefully, because it is the part most performance articles get wrong. This is a correlation across buckets, not a causal estimate. Sessions that load slowly are also more likely to be on older devices, on worse networks, in different markets, and arriving from different channels. Some of that gap is speed. Some of it is the kind of session that tends to be slow.

Getting to a defensible number

To separate the two, you need a change rather than a comparison. On one of the four sites we moved the product detail template from 4.2 seconds to 0.9 seconds in a single release, with no other change to the page, no change to pricing and no change to media spend. Sessions that had previously sat in the 2.5 to 4.0 second bucket moved into the sub second bucket.

Conversion for that cohort, on the same device classes and the same channels, rose by 22 percent over the following eight weeks. That is the number we are willing to defend. The full site conversion uplift over the same period was 38 percent, but that included checkout changes shipped in the same programme, and attributing all of it to speed would be dishonest.

Translated to money on that client’s volume, the speed component alone was worth roughly 1.9 million EUR of additional annual revenue against a storefront rebuild that cost 74,000 EUR. That is the arithmetic that gets a budget approved, and it is why we insist on measuring before and after rather than presenting a lab score.

Where the milliseconds actually came from

Nobody gets from 4.2 seconds to 0.9 seconds with one clever trick. On that project the breakdown was roughly:

• 1.4 seconds from moving the template to static generation at the edge instead of rendering on a shared origin in one region
• 0.9 seconds from image work: correct formats, correct sizes, priority hints on the hero, and lazy loading everything below the fold
• 0.6 seconds from removing three tag manager containers that had accumulated over four years and loading what remained after interaction
• 0.3 seconds from font loading: two families instead of five, subset, preloaded, with a metric compatible fallback so nothing shifted
• 0.1 seconds from the JavaScript bundle, which everyone assumes is the main cost and which was worth the least of the five

That last line is the one worth remembering. Teams spend months on bundle size because it is the part engineers control directly, and it was the smallest contributor on this project by a wide margin.

Keeping it

Performance regresses. It regresses because marketing adds a script, because a supplier changes an image pipeline, because a developer imports a date library to format one timestamp. The only reliable defence is a budget enforced in the pipeline, where a change that pushes largest contentful paint or transferred bytes past the agreed threshold fails the build rather than generating a ticket somebody will get to later.

Eighteen months after that project, the same site is still under one second at the 75th percentile. Not because anyone is being careful, but because the pipeline will not let them not be.