Core Web Vitals vs RUM: lab data vs real-user data

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 monitor.

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) monitor 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 monitors. The Core Web Vitals monitor 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) monitor 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 data vs field data on one chart

Core Web Vitals vs RUM is easiest to judge when both sides share one picture. Relvato draws your latest lab run and your real visitors' p75 on one radar chart, "Lab vs real users", per device — in the app's Performance tab and in the WordPress plugin's dashboard. Its five axes are LCP, INP, CLS, FCP and TTFB, each scored 0–100 on the same curve (90 is Google's "good" limit, 50 is "poor"), so seconds, milliseconds and the unitless CLS share one scale. Real users are the filled shape; the lab run is the dashed outline.

Wherever the two shapes part, lab data and field data disagree. An axis where real visitors land in a worse rating band than the test is circled and listed with both values. In the example below, the lab run passes everything — but real visitors on mobile wait 3.1 s for the largest element (lab: 1.8 s) and 940 ms for the server's first byte (lab: 380 ms). That is the gap a lab-only setup never shows, and it sits in the field data Google ranks on.

Two rules keep the picture honest. A metric one side hasn't measured — INP before any visitor has clicked, or too few page views — is left off that shape instead of being drawn as a zero. And on the INP axis the lab plots Total Blocking Time — the stand-in Lighthouse uses — because a scripted page load has no real visitor interaction to time. The chart is part of website speed monitoring in Relvato, alongside the two monitors it compares.