Field data and lab data
The industry splits performance measurement into two categories, and the distinction is the whole point of RUM.
Lab data comes from a controlled test: a browser you configure, on a network you choose, run on demand. It is reproducible, it isolates one variable at a time, and it keeps producing numbers whether or not anyone visits your site. That is exactly what you want when you are comparing two builds or bisecting a regression.
Field data comes from real visits. A small script records what actually happened in each visitor's browser and reports it back. It is not reproducible, it is noisy, and it only covers pages people actually load — but it is the only measurement that reflects your real mix of devices, networks, and geographies. Google assesses Core Web Vitals from field data, which is why this distinction has commercial consequences and not just technical ones.
What RUM measures
In practice RUM for the web means Core Web Vitals — the three metrics Google treats as a ranking signal:
- Largest Contentful Paint (LCP) — when the biggest thing on screen
finished rendering. Good is
≤ 2.5 s, poor is> 4.0 s. - Interaction to Next Paint (INP) — how long interactions took to produce
a visible response, across the whole visit. Good is
≤ 200 ms, poor is> 500 ms. - Cumulative Layout Shift (CLS) — how much the page moved around under
the reader. Good is
≤ 0.1, poor is> 0.25.
Two more are commonly collected as diagnostics: First Contentful Paint and Time to First Byte. They are not Core Web Vitals and search ranking does not depend on them directly, but they explain the ones that do — a poor LCP sitting behind a 2-second TTFB is a server problem, while the same LCP behind a fast TTFB is a front-end problem.
If you have older documentation referring to First Input Delay, it is gone. INP replaced FID as a Core Web Vital in March 2024 and FID has since been removed from Google's field data set entirely. FID only measured how long the first interaction waited before processing began; INP measures the full latency of interactions across the visit, through to the frame the user actually sees.
Why the 75th percentile, and not an average
RUM tools report each metric at the 75th percentile rather than as a mean, and this is the single most common thing people get wrong when they first look at field data. An example makes it obvious. Suppose twenty visits record these LCP values, in seconds:
1.0 · 1.0 · 1.1 · 1.1 · 1.1 · 1.2 · 1.2 · 1.2 · 1.3 · 1.3 · 1.4 · 1.5 · 1.7 · 2.2 · 2.9 · 4.2 · 4.4 · 4.6 · 4.9 · 5.2
The average is 2.2 s, comfortably inside the "good" threshold. Ship it, write it in the report, move on. But the 75th percentile is 2.9 s — "needs improvement" — and the reason is visible in the numbers: a quarter of these visits took over four seconds. Those five people had a genuinely bad experience, and the fourteen fast desktop loads averaged it out of existence.
The 75th percentile answers a better question — was this good for at least three out of four visits? — and it is deliberately hard to flatter. It is also what Google uses, so it is the number that corresponds to the assessment affecting your ranking.
Where RUM fits alongside synthetic monitoring
RUM and synthetic monitoring are frequently presented as alternatives. They are not; they fail in opposite directions.
Synthetic monitoring is scripted and proactive. It runs on a schedule whether or not anyone is visiting, which is what catches a broken checkout at 3 AM on a page nobody has loaded since yesterday. RUM is passive: it can only report on what real traffic exercised. A page with no visitors produces no RUM data at all, and a bug that only manifests at 3 AM will simply not appear until someone hits it.
Run in parallel, they answer different halves of one question. RUM tells you what is slow and how many people it affects. A synthetic run tells you why, reproducibly, with a full waterfall attached. The most useful signal of all is when the two disagree: if a scheduled browser check loads a page quickly and your real visitors are still waiting, the bottleneck is not your server — it is what the page costs on real devices and networks.
What RUM cannot tell you
Being clear about the limits saves a lot of wasted investigation.
- It needs traffic. Percentiles over a handful of samples are noise. A low-traffic page may show a site-wide number long before it shows a trustworthy figure for that individual page.
- INP requires interaction. A visitor who reads a page and leaves without clicking anything contributes an LCP and a CLS but no INP. On content sites INP is always the sparsest metric.
- It is not error tracking. Core Web Vitals say nothing about a JavaScript exception, a failed API call, or a 500. Those are a different tool.
- It cannot tell you the cause. RUM reports that LCP is 4.8 s on mobile in Brazil. It does not tell you the hero image is an unoptimised PNG. Attribution data — which element, which interaction — narrows it down; a lab run confirms it.
Common mistakes to avoid
Treating a lab score and a field score as the same measurement. They will disagree, and neither is broken. A lab test on a fast connection from a data centre is not predictive of a mid-range Android phone on mobile data. If your lab score is 95 and your field LCP is poor, that gap is information, not an error to reconcile.
Optimising the average. Covered above, and worth repeating because dashboards that report means are common. Improving the experience of visitors who were already fast moves the average and changes nothing that matters.
Reading a percentile off too few samples. A p75 computed from a dozen visits will swing wildly day to day and tempt you into chasing noise. Wait for volume, or widen the window.
Assuming CLS is a page-load metric. It accumulates across the entire visit. A late-loading advertisement, a cookie banner that appears after two seconds, or a lazy-loaded image without reserved dimensions will all push CLS up long after the page looked finished.
Ignoring the device split. Mobile and desktop routinely differ by more than any optimisation you are likely to ship. Looking at a blended number hides which of the two actually has the problem, and comparing them is usually the first genuinely useful thing you can do with field data.
Troubleshooting: why does my data look wrong?
Why does my field LCP differ from PageSpeed Insights? The lab section of PageSpeed Insights runs a simulated mid-tier mobile device on a throttled connection. Your field data is whatever your visitors actually have. If most of your traffic is desktop on broadband, your field number will usually be better than the lab score. If most of it is mobile in a region far from your CDN, it will be worse.
Why is there no INP for this page? Nobody interacted with it, or not enough people did to form a percentile. This is normal for landing pages and articles.
Why did my p75 barely move after I shipped a fix? Because the reporting window still contains the old data. A 28-day window on a fix deployed three days ago is roughly 90% pre-fix measurements. Either narrow the window or wait — the number is not wrong, it is just averaging over a period when the problem still existed.
Why is one page far worse than the rest of the site? Check the traffic mix before you check the code. A page that gets a much higher share of mobile or international visits than your site average will look slower even if its code is identical to a page that looks fine.