Core Web Vitals Are a Revenue Variable

I care about this topic for an unglamorous reason. Performance work is one of the few interventions available to a small service business that does not require traffic volume to justify, does not depend on a copy argument, and cannot be undone by a competitor. It is also the area where the marketing literature is least honest about its evidence.

What the published numbers actually are

Google maintains a roll-up of Core Web Vitals business outcomes across roughly eighteen companies Rajpal & Gopalakrishnan 2021. The figures are real and worth knowing:

The deeper issue is design. With one exception these are self-reported observations of a metric before and after a change, without a control group. Anything else that happened in the same window — a season, a campaign, an algorithm update, a competitor's outage — is inside the estimate.

The one that counts

Vodafone ran a genuine A/B test. A 31% improvement in Largest Contentful Paint produced an 8% increase in sales, with a control group holding the counterfactual.

That single result does more work than the other seventeen combined, and it is also more modest than most of them. This is the normal pattern when you replace uncontrolled observation with randomisation, and it is the same lesson the advertising-measurement literature teaches: non-experimental estimates of a marketing intervention are usually too big. Blake, Nosko and Tadelis found eBay's ordinary regression estimates of paid-search return exceeded 4000%, while the experimental estimate was negative 63% Blake et al. 2015.

What the thresholds mean, precisely

The Core Web Vitals boundaries are not arbitrary marketing numbers; the Chrome team documented how they were chosen, including the constraint that a minimum of roughly 10% of origins must already achieve "good" for a threshold to be considered achievable McQuade & Pollard 2020.

• LCP — good ≤ 2500 ms, poor > 4000 ms. When the main content appeared.
• INP — good ≤ 200 ms, poor > 500 ms. How fast the page answers an interaction. Replaced First Input Delay on 12 March 2024 Viscomi 2024.
• CLS — good ≤ 0.1, poor > 0.25. How much the layout moved under the reader.

All three are assessed at the 75th percentile of page loads — formally, for the distribution $F$ of a metric across visits,

This is the design decision that makes the thresholds useful. A comfortable median with an ugly tail fails, which is correct, because the tail is where your slowest-device visitors live. Google's own rationale is explicit: "by using the 75th percentile, we know that most visits to the site (3 of 4) experienced the target level of performance or better."

A caveat about the data source itself

Core Web Vitals field data comes from the Chrome UX Report. Its own documentation is clear about the sampling: a user is eligible only if usage-statistic reporting is enabled, browser history is synced, no sync passphrase is set, and they are on a supported platform. Origins need "a minimum number of visitors" that is not disclosed Chrome UX Report methodology.

So CrUX is a self-selected sample of consenting Chrome users, with an undisclosed inclusion threshold. That does not make it useless — it is the best field data available — but any CrUX-derived percentage is descriptive of that population, not of the web.

Most small service sites will not appear in CrUX at all, because they lack the traffic. That is not a problem to solve; it just means your performance work should be validated with lab tooling and your own analytics rather than a public dataset.

The position I take with clients

I will not tell you that improving LCP by a second will raise your revenue by a specific percentage. Nobody honest can, because the only controlled estimate available produced 8% for a 31% improvement at a telecom, and your business is not that.

What I will say is this: the response-time limits are real human constraints, the thresholds are documented and achievable, and performance is one of the few things you can fix once and keep. It belongs in the build, not in a quarterly optimisation cycle.

Ariadne's own site is audited publicly for exactly this reason — if I am going to make performance an argument, the argument should be checkable on the thing making it.

References

1. Rajpal, S., & Gopalakrishnan, S. (2021). The business impact of Core Web Vitals. web.dev (Google), last updated 1 September 2021. https://web.dev/case-studies/vitals-business-impactAggregation of self-reported partner case studies; mostly uncontrolled before/after. Vodafone is the one true A/B test.
2. McQuade, B., & Pollard, B. (2020). How the Core Web Vitals metrics thresholds were defined. web.dev / Chrome for Developers. https://web.dev/articles/defining-core-web-vitals-thresholds
3. Viscomi, R. (2024). Interaction to Next Paint is officially a Core Web Vital. web.dev blog, Google Chrome team. https://web.dev/blog/inp-cwv-launch
4. Chrome team (2024). CrUX methodology — Chrome UX Report. Chrome for Developers documentation. https://developer.chrome.com/docs/crux/methodology
5. Blake, T., Nosko, C., & Tadelis, S. (2015). Consumer heterogeneity and paid search effectiveness: A large-scale field experiment. Econometrica, 83(1), 155–174. https://doi.org/10.3982/ECTA12423