RUM vs. Synthetic Monitoring
Field data from real users vs. lab data from controlled tests — what each one is good and bad at.
Now you know the metrics — but where do the numbers come from? There are two ways to measure: watch real users in the wild (RUM / field data) or run controlled tests in a lab (synthetic monitoring). They answer different questions, and the pros use both.
One controlled test vs. thousands of real visits
Synthetic monitoring runs your page in a fixed environment — same device, network, and cache every time — so you get a clean, repeatable number. RUM instruments real visits and gives you a whole distribution of what actual people experienced. One is a controlled experiment; the other is the truth on the ground:
RUM — Real User Monitoring
RUM is usually a small third-party script that reports each real visit's metrics (LCP, INP, CLS…) to a dashboard. Because it sees everyone, you can break the data down — by country, browser, device, connection — and discover that your “good” average is hiding a miserable experience for users in one region or on one browser.
Synthetic monitoring
Synthetic tests run away from real users, so they cost your visitors nothing — which means you can capture everything: full request waterfalls, screenshots, console logs, main-thread traces. Because the variables are fixed, the same version yields the same result, which makes it perfect for two things: deep debugging a specific scenario, and pre-release testing to catch a regression before it ships. Tools: Lighthouse, WebPageTest, DebugBear.
Why field and lab numbers disagree
It throws people off when the same page reads 1.8 s in the field and 3.0 s in the lab. That's not a bug — they measure different things. Click through the reasons:
Which tool for which question
You don't pick one forever — you pick per question. Field tells you what is wrong and for whom; lab lets you reproduce and fix it. Toggle to see the questions each is built to answer:
| RUM (field) | Synthetic (lab) | |
|---|---|---|
| Source | Real users, in production | Controlled, scripted runs |
| Result shape | A distribution (p75, breakdowns) | A single repeatable number |
| Overhead | Runs in users' browsers | Zero cost to users |
| Detail captured | Lightweight (keep it lean) | Deep (traces, filmstrip, logs) |
| Before release? | No — needs real traffic | Yes |
| Best at | What real users feel; who's affected | Reproducing & debugging; CI gates |
Field or lab?
For each goal, pick the right approach:
- →RUM (field) = real users → a distribution you can break down by segment.
- →Synthetic (lab) = fixed variables → repeatable, deep, and usable before release.
- →Lab is misleading if its variables don't match your real audience — pick them from RUM.
- →Field vs lab numbers differ by design (cache, device, LCP element, bfcache).
- →Use both: field to find what's wrong & for whom, lab to reproduce, debug, and gate releases.