Core Web Vitals business impact, without the hand waving

A founder asked us last month what a Core Web Vitals score was worth in revenue. The honest answer is that nobody can tell you, and anybody who quotes you a figure is quoting somebody else's site. That is not a reason to ignore the metrics. It is a reason to understand what they actually measure before deciding how much to spend fixing them.

This note is the specification, in plain terms, plus the argument for why the thresholds are set where they are. It is deliberately not another piece telling you that a fast site sells more. We wrote that one already, in a slow site is a revenue problem, and this is the technical companion to it.

The three metrics, and what each one is really asking

Google's documentation defines three Core Web Vitals, each measuring a different kind of user frustration. They are not interchangeable and a site can pass two comfortably while failing the third badly.

Those thresholds come from Google's own Core Web Vitals documentation, which states that LCP should occur within 2.5 seconds, that pages should have an INP of 200 milliseconds or less, and that CLS should be 0.1 or less.

The percentile is the part everybody misses

Here is the detail that changes how you should test. Google assesses these at the 75th percentile of page loads, segmented across mobile and desktop. Not the average, and emphatically not your one run on a laptop on office wifi.

The practical consequence is that your own experience of your site is close to worthless as evidence. You are a repeat visitor with a warm cache on a good device. The 75th percentile is a first time visitor on a mid range phone on a congested network, and that person decides your score.

This is also why a site can feel fine to the team that built it and fail the assessment. It is not a contradiction. It is two different measurements, and only one of them counts.

INP replaced FID, and it is the one most sites fail

Interaction to Next Paint became a stable Core Web Vital in 2024, after being promoted from experimental status in 2023 with the intent to retire First Input Delay. The change matters because the two measure genuinely different things.

Google's documentation on INP defines it as the time from when a user initiates an interaction until the next frame is painted, across all or most interactions in the session. Only three interaction types count: clicking with a mouse, tapping on a touchscreen, and pressing a key. Scrolling does not.

It splits that latency into three phases, and knowing which phase is yours is the whole diagnostic job. Input delay is the time before your event handlers start running. Processing duration is your handlers actually executing. Presentation delay is the gap between your code finishing and the frame reaching the screen.

• Long input delay usually means something else was already occupying the main thread, often a third party script.
• Long processing duration is your own JavaScript doing too much work in the handler.
• Long presentation delay usually means the resulting render is expensive, not that your logic is slow.

The thresholds are 200 milliseconds or less for good, above 200 and up to 500 for needs improvement, and above 500 for poor. That middle band is where a lot of otherwise well built sites sit, and it is invisible until somebody measures it, because 300 milliseconds does not feel broken. It feels slightly cheap.

What you can honestly claim about the money

Now the part where most articles overreach. There is no published multiplier that converts an LCP improvement into a revenue figure for your site, and the case studies that circulate are single companies with their own traffic mix, product and price point. Borrowing one is guessing with a citation attached.

What you can say defensibly is narrower and still useful. Passing the thresholds removes a known cause of abandonment on the slowest quarter of your traffic. Whether that quarter is worth the engineering time depends on what they are worth to you, which is a question your analytics can answer and a blog post cannot.

So the honest way to fund this work is to measure your own field data first, find which metric you fail and on which template, and size the fix against the revenue attributable to that template. If that number is small, the correct decision is to leave it alone. That is a legitimate outcome and not a failure of the exercise.

Where to look before you start optimising

Diagnosis before treatment, in this order. Get field data rather than lab data, because the lab tells you what is possible and the field tells you what is happening. Identify which of the three metrics fails and at which percentile. Then find the template, not the page: sites almost never fail uniformly, they fail on the product page or the article page while the homepage passes.

Only then look at causes. The usual suspects on a marketing site are images that are larger than their display size, render blocking third party tags, and fonts that force a reflow. On an application the usual suspect is a heavy interaction handler. Our sequence for the mobile case is in why is my website slow on mobile, and the architectural version of the question is in static site versus WordPress performance.

If the failure is under load rather than at rest, that is a different problem with a different fix, and we set out the order to work through in how to scale a web app for more users.

Honest limits

Three caveats worth stating plainly. Core Web Vitals are one input among many in ranking, and a site that fixes them while remaining thin on content will not suddenly rank. Performance work is a tiebreaker rather than a cause.

The metrics also change. INP replaced FID within the last three years, and the thresholds themselves are periodically reviewed. Anything you build that hard codes today's numbers will need revisiting, so treat the documentation as the source of truth rather than any article, this one included.

Finally, the assessment window is rolling and populated by real users, which means a fix does not show up immediately. If your traffic is low the field data may be too sparse to report at all, and in that case you are optimising on lab data and reasonable inference, which is fine as long as you know that is what you are doing. If you want the marketing side of this rather than the engineering side, the team at U Courses cover it from the practitioner angle in their guide to what to learn first in SEO.