Real user monitoring (RUM) collects performance data from real visits to a website or app, using code that runs in the visitor’s browser. Typical measurements are load times, Core Web Vitals and JavaScript errors, which can be broken down by page, device or country.
How does RUM work?
A small script, or a library such as Google’s open-source web-vitals library, runs on each page view and reports measurements to a dashboard or analytics tool. web.dev advises reporting percentiles (usually the 75th) instead of averages and sending data when the page becomes hidden, because the unload event is unreliable on mobile.
RUM vs. synthetic monitoring
Synthetic monitoring runs scripted tests on a schedule under fixed conditions. It works without traffic and can catch outages and regressions, but it only checks what was set up. RUM shows what actual visitors experience, but it needs enough traffic and cannot see a release that nobody has visited yet. Many teams use both.
RUM and SEO
Google calls data from real users field data. The Chrome UX Report (CrUX) is the public field dataset behind PageSpeed Insights, with eligibility limits for pages that are not publicly discoverable or have too little traffic. web.dev points out that your own RUM data lets you segment by user group and track changes over time, which CrUX alone cannot do.
| Metric | Measures | Core Web Vital? | Field or lab | “Good” per web.dev |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Render time of the largest image, text block or video visible in the viewport, from the start of navigation | yes (loading) | field and lab | 2.5 s or less |
| INP (Interaction to Next Paint) | Latency of interactions across the whole visit until the next paint; one value that all (or nearly all) interactions fall below | yes (interactivity), since 2024-03-12 | field; in the lab only with simulated interactions, Lighthouse does not measure INP | 200 ms or less |
| CLS (Cumulative Layout Shift) | Largest burst of unexpected layout shifts during the entire lifecycle of the page | yes (visual stability) | field and lab | 0.1 or less |
| TTFB (Time to First Byte) | Time from the start of navigation until the first byte of the response arrives | no (helps diagnose LCP) | field and lab | 0.8 s or less |
| FCP (First Contentful Paint) | Time from the start of navigation until any part of the page's content is rendered | no (helps diagnose LCP) | field and lab | 1.8 s or less |
| TBT (Total Blocking Time) | Total time after FCP during which the main thread was blocked long enough to prevent input responsiveness | no (lab proxy for INP) | lab; web.dev does not recommend field measurement | less than 200 ms on average mobile hardware |
| Speed Index | How quickly content is visually displayed during page load (from a video of the load) | no | lab (Lighthouse) | Threshold according to Lighthouse: mobile up to 3.4 s “fast” (web.dev gives no value) |
| FID (First Input Delay), historical | Time from the first interaction until the browser can begin processing event handlers | until 2024-03-12, replaced by INP | field only | 100 ms or less |
According to web.dev, the 75th percentile of page loads is assessed, mobile and desktop separately. A page passes the Core Web Vitals when LCP, INP and CLS are “good” at the 75th percentile. Chrome tools ended FID support on September 9, 2024. Sources: web.dev: Web Vitals; web.dev: Largest Contentful Paint (LCP); web.dev: Interaction to Next Paint (INP); web.dev: Cumulative Layout Shift (CLS); web.dev: Time to First Byte (TTFB); web.dev: First Contentful Paint (FCP); web.dev: Total Blocking Time (TBT); web.dev: First Input Delay (FID); web.dev Blog: Interaction to Next Paint is officially a Core Web Vital (2024-03-12); Chrome for Developers: Lighthouse – Speed Index. Last checked: .
Example
A shop sees good LCP values in lab tests for the home page. Its RUM data shows slow LCP for mobile visitors on category pages, so that is where the team starts.
Sources
- Real user monitoring – Akamai glossaryakamai.com
- Measure and report field data – web.devweb.dev
- Why lab and field data can be different – web.devweb.dev
- Chrome UX Report (CrUX) – Chrome for Developersdeveloper.chrome.com
Last updated: