Core Web Vitals vs RUM: lab data vs real-user data
Updated 27 August 2026 · 8 min read
LCP, INP and CLS are the same three metrics wherever you see them — but you can measure them two very different ways. A synthetic 'lab' test runs your page once in a controlled browser; real-user monitoring (RUM) measures the same metrics from your actual visitors. This guide explains the difference, when each is right, and which one Google's ranking actually uses.
The metrics are the same — the measurement isn't
Core Web Vitals are three user-experience metrics from Google: Largest Contentful Paint (LCP, loading), Interaction to Next Paint (INP, responsiveness) and Cumulative Layout Shift (CLS, visual stability). They're the same three metrics no matter where you read them.
What changes is how they're captured. 'Lab' (or synthetic) data comes from a single scripted page load in a controlled browser. 'Field' data — also called Real-User Monitoring, or RUM — is collected from the browsers of your actual visitors as they use the site. Same metrics, two completely different measurement models.
Lab (synthetic) Core Web Vitals
A lab test loads your page in a headless browser on a fixed device profile and network speed, then reports the metrics. Lighthouse and the 'lab' section of PageSpeed Insights work this way, and so does Relvato's Core Web Vitals journey.
Because the environment is fixed, results are stable and repeatable, and you can run them any time — even before launch, on a staging URL, or on every deploy. That makes lab data ideal for debugging a specific problem and for catching a regression before it ships.
The trade-off: one synthetic environment is not your audience. A fast data-center browser on a fixed connection won't reflect a visitor on a mid-range phone over patchy mobile data. And INP, being an interaction metric, can't be truly measured without a real person interacting — lab tools estimate it or fall back to a proxy like Total Blocking Time.
Field data / Real-user monitoring (RUM)
RUM measures Core Web Vitals in your real visitors' browsers. A small script — a 'beacon' — uses the browser's PerformanceObserver API to record LCP, INP, CLS, FCP and TTFB from each real page load, then sends the timings back anonymously and without cookies. Relvato's Real-user Web Vitals (RUM) journey works this way.
Because the data comes from thousands of real sessions across many devices, networks and locations, it reflects the experience your users actually have. INP is a real measurement here, not an estimate. Results are usually reported as the p75 — the 75th percentile — which is the figure Google grades against.
The trade-off: RUM needs real traffic, so it takes time to accumulate and a low-traffic page fills in slowly. It's also noisier by nature — it captures real-world diversity — and you can't 're-run' a single session to debug it.
Which one affects SEO?
Google's page-experience ranking signal uses field data, not lab data. Specifically, it draws on the Chrome User Experience Report (CrUX) — real Core Web Vitals from Chrome users. Your lab score can be perfect while your field score (the one that ranks) is poor, or the other way around.
So RUM is the number that moves rankings, and lab is the tool that helps you fix it. If you only watch lab scores, you can pass every test and still lose ranking to a slowdown your real users feel.
So which should you use? Both.
Lab and field data answer different questions, so the right setup uses both. Run synthetic Core Web Vitals on every change to catch regressions before they reach anyone and to debug them in a controlled environment. Run RUM continuously to know the experience real users get — and to protect the field score Google ranks on.
A common workflow: RUM tells you a metric regressed for real users; the lab test lets you reproduce and fix it; the next RUM window confirms the fix reached your audience.
How Relvato monitors both
Relvato runs both as separate, continuous checks. The Core Web Vitals journey is the lab side: a real-browser synthetic run on your key pages, on every change, with a 0–100 score and specific fixes. The Real-user Web Vitals (RUM) journey is the field side: a cookieless beacon that reports the p75 per page type and device, alerts on the CWV 'poor' band, and flags a regression against the page's own 28-day baseline — then correlates it with the change that shipped around that time.
Together they answer both questions: 'is this change about to hurt performance?' (lab) and 'how does the site actually feel to visitors right now?' (field).
Lab vs field data, side by side
| Lab / synthetic | Field / RUM | |
|---|---|---|
| What it measures | One scripted page load | Real visitors' actual page loads |
| Where it runs | A controlled data-center browser | Your users' own devices & networks |
| Metrics | LCP, CLS, FCP, TTFB; INP estimated | LCP, INP, CLS, FCP, TTFB — all real |
| Sample | A single repeatable run | Thousands of sessions, reported as p75 |
| Variability | Low — stable and repeatable | Higher — reflects real-world diversity |
| Availability | Instant, even pre-launch | Needs real traffic; fills over days |
| Best for | Debugging & catching regressions pre-deploy | Real UX & protecting rankings |
| Google Search ranking | Not used directly | Yes — CrUX field data feeds the signal |
| In Relvato | Core Web Vitals journey | Real-user Web Vitals (RUM) journey |
Questions, answered
Is RUM the same as Google's CrUX?
They're both field data, but not the same. CrUX (the Chrome User Experience Report) is Google's own RUM dataset, collected only from eligible Chrome users and reported on a 28-day rolling basis. Your own RUM beacon covers every browser — not just Chrome — updates in near real time, and can break the data down per page type and device, so it catches regressions sooner and in more detail than CrUX.
Can you measure INP in the lab?
Not truly. INP (Interaction to Next Paint) measures how quickly the page responds to real interactions, so without a real person clicking or tapping there's nothing to measure. Lab tools estimate responsiveness with a proxy like Total Blocking Time. A genuine INP number only comes from field data / RUM.
Does the RUM beacon slow down my site?
No. The beacon is a tiny (~1.6 KB) asynchronous script that uses the browser's built-in PerformanceObserver API and sends its data with navigator.sendBeacon as the page unloads. It sets no cookies, stores no personal data or IP address, and never blocks rendering.
What is p75, and why the 75th percentile?
p75 is the 75th percentile — the value that 75% of page loads are at or below. Google grades Core Web Vitals at p75 because it represents the experience of most visitors while ignoring the slowest outliers. A single average would hide a bad tail; p75 is a stable, representative figure.