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.
The core distinction
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:
InteractiveLab gives you a number; field gives you a distribution
Synthetic (Lab)
1 controlled run
Same device, network, and cache every run → repeatable, identical numbers. Great for catching regressions.
RUM (Field)
thousands of real visits
Every real device, network, and location → a distribution. The truth about what users feel (incl. that slow tail).
Synthetic = repeatable single result. RUM = the spread across every real device, network, and location — including the slow tail.
Field data
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.
The overhead trap
RUM runs in your users' browsers, so capturing too much(every request, every frame) makes the monitoring itself a performance problem. Keep it light. Popular tools: New Relic, SpeedCurve, Sentry.
Lab data
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.
Garbage in, garbage out
Lab data is only as honest as its variables. Test on a high-end laptop and Fast 3G while your users are on cheap phones and spotty networks, and your green lab scores are a comforting lie. Pick variables from your real audience (which RUM tells you).
A common surprise
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:
InteractiveSame page, different numbers
Field (RUM)
1.8s
≠
Lab (Synthetic)
3.0s
Same page, different numbers — and that's expected. Why?
Field
Returning users have assets cached → fast
Lab
Cold cache every run → slower
Caching, device/network mix, which element is the LCP, and bfcache all pull field and lab apart.
Use the right one
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: