Core Web Vitals Are a Revenue Metric, Not a Lighthouse Badge
A green Lighthouse score proves your page was fast once, on your laptop. Field data tells you whether it was fast for the visitor who almost bought something. Here's how to treat web vitals like the conversion lever they are.
Most teams meet Core Web Vitals through a Lighthouse run. You open the tab, click analyze, watch three numbers turn green, and move on feeling good.
The problem is that the run measured one page load, on one machine, on one network, at one moment. Your visitors are on three year old phones, hotel wifi, and a browser with twelve extensions installed. The score that matters is the one they experienced, and it is almost never the one in your report.
That distinction is not academic. Slow pages quietly lose conversions before anyone files a bug, because nobody complains about a checkout that was merely sluggish. They just leave. If you want vitals to earn their keep, you have to measure them in the field and tie them to money.
The three numbers, briefly
Core Web Vitals come down to three questions a visitor asks without knowing it:
- LCP (Largest Contentful Paint): did the main content show up quickly? Aim for under 2.5 seconds. This is your "is anything happening" metric.
- INP (Interaction to Next Paint): when I tapped, did the page respond? Aim for under 200 milliseconds. This is your "is it alive" metric, and it replaced the old First Input Delay because it measures every interaction, not just the first.
- CLS (Cumulative Layout Shift): did the page hold still, or did the button jump as I reached for it? Aim for under 0.1. This is your "do I trust it" metric.
Lab tools simulate all three. Field measurement records what really happened on real devices, which is the only version Google rewards in search and the only version your revenue responds to.
Why lab scores and field scores disagree
A Lighthouse score is a controlled experiment. Field data is the weather. They diverge for reasons that are entirely predictable once you name them:
Device mix. Your team tests on fast laptops. A chunk of your audience is on mid range Android, where the same JavaScript takes three or four times longer to run. INP is where this hurts most.
Network reality. Lab runs use a tidy simulated connection. Real LCP gets dragged out by flaky mobile networks and cold caches that no synthetic run reproduces.
Real interactions. A lab tool loads the page and stops. A person scrolls, opens a menu, mistaps, and submits a form. INP only shows its true face under that kind of use.
The long tail. Averages hide the visitors who suffer most. Your median LCP can look fine while the slowest quarter of loads, often your highest intent mobile shoppers, sit well past four seconds.
Measuring vitals where they actually happen
First-party analytics gives you these numbers from real sessions instead of a synthetic run. With OakData the snippet captures web vitals automatically, so every real load reports its own LCP, INP, and CLS with no extra code. If you have read what first-party analytics actually is, this is the same idea applied to performance: unsampled, collected under your own domain, and queryable on your terms.
The unlock is not the raw number. It is the ability to slice it:
- By page. Your blog can be flawless while your pricing page quietly fails. A site wide average would never tell you which.
- By device and browser. Split desktop from mobile and you usually find one of them carrying all the pain.
- By country. Distance from your servers and local network quality show up directly in LCP for visitors far away.
- By percentile, not average. Track the 75th percentile at minimum, because that is the threshold Google grades you on and the point where real people start abandoning.
Connecting milliseconds to money
Here is the move most teams skip. You already capture conversion events with oak.capture("checkout_started") and the rest of your funnel. You also have a web vital on every session. Put them side by side and the performance conversation stops being about a score and starts being about outcomes.
Concretely, ask questions like:
- Do sessions with LCP under 2.5 seconds convert at a different rate than sessions over 4 seconds, on the same page?
- On the pricing page specifically, does a high INP correlate with people bouncing before they ever click the plan they came for?
- Did the layout shift you shipped last sprint line up with a dip in form completions on mobile?
When you can show that the slow cohort converts noticeably worse on a page that matters, performance work stops being a chore engineering nags about and becomes a line item with a number next to it. That is the argument that gets a fix prioritized.
From a slow number to a shipped fix
Finding the bad metric is half the job. Seeing why it is bad is the other half, and this is where vitals and session replay work together. A high INP on your search box is abstract until you watch a real session where someone types, waits, and types again because nothing responded. Replay turns a percentile into a thing you can fix.
A practical loop that holds up week after week:
- Rank pages by traffic times badness. A small regression on your most visited page beats a large one on a page nobody sees. Sort by impact, not by worst score.
- Confirm the device or country carrying it. Slice until the pain has a face. Usually it is one segment, not everyone.
- Watch real sessions in that segment. See the slow load or the janky interaction happen to an actual visitor.
- Ship one fix and re-measure in the field. Not in Lighthouse. Confirm the 75th percentile moved for real users on real devices.
Common traps
"Lighthouse is green, so we are done." A lab pass means the page can be fast, not that it is fast for your audience. Field data is the scoreboard that counts.
"Our average is fine." Averages launder away the slow tail, which is exactly the cohort closest to leaving. Watch percentiles.
"Performance is an engineering metric." It is a conversion metric that engineering happens to control. Frame it that way and it competes for priority on equal footing with features.
Treat Core Web Vitals as something visitors feel and your funnel records, not a badge you collect once a quarter, and they turn into one of the cheapest conversion levers you have.
OakData captures LCP, INP, and CLS on every real session out of the box, sliceable by page, device, and country and sitting right next to your conversion events, so you can see which slow pages are actually costing you.