Real User Monitoring
The Core Web Vitals Google actually ranks you on.
Every performance score you have ever run came from one machine, on one connection, in one place. Your visitors are on four-year-old Android phones, hotel Wi-Fi, and mobile networks in cities your server has never heard of. Real User Monitoring measures the page on their hardware — and reports the same three metrics, at the same percentile, that Google uses when it ranks you.
Your performance score is not your visitors' experience
Run a page speed test and you get a number. Run it again from a different network and you get a different number. Neither is wrong, and neither is what your visitors experienced — because a test runs on a machine you chose, over a connection you chose, at a moment you chose. It is a controlled experiment, and controlled experiments are valuable precisely because they hold everything constant. Real users hold nothing constant.
This gap has direct commercial consequences, because Google does not rank you on lab measurements. Core Web Vitals are assessed from field data — measurements collected from real Chrome users on real devices. If your test machine loads the page in 1.4 seconds and a third of your traffic is on mobile networks where the same page takes five, the field number is the one that counts, and it is the one you cannot see.
The failure mode is not that you are slow and don't know it. The failure mode is that you optimised the thing you could measure. Teams spend weeks shaving milliseconds off a metric their lab tool reports, while the actual bottleneck — a hero image that is fine on a desktop and ruinous on a phone, a third-party script that is cached for you and cold for everyone else, a region your CDN quietly doesn't serve — never shows up, because it never happens on the test machine.
How Real User Monitoring works
You add one script tag to your pages. It is served from NetTests, it loads with
defer so it never blocks
rendering, and it is built on Google's own
web-vitals library — the
same measurement code Chrome's own tooling uses, so the numbers are directly
comparable to what Search Console reports.
<script defer src="https://nettests.net/rum/v2.8.0/rum.js" integrity="sha384-4818lK6xIptN7PSIkSBX7pLSHUs6Z1WRZFLB8S7hvTK1nZwDtLMtB9rFcgFQVWRR" crossorigin="anonymous" data-site="YOUR_SITE_KEY"></script>As a visitor uses the page, the script records Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, First Contentful Paint, and Time to First Byte. When the visitor leaves, all of it ships in a single beacon — one request, sent in a way the browser guarantees to deliver even as the page is being torn down. There is no polling, no periodic upload, and no second request.
NetTests aggregates those measurements hourly and reports each metric at the 75th percentile, which is the aggregation Google uses: the experience of your slowest quarter of visits, rather than an average that a few fast desktop loads can flatter. Alongside the number you get the distribution — what share of visits were good, needed improvement, or were poor — so you can tell "everyone is slightly slow" apart from "most people are fine and a segment is suffering". Those are different problems with different fixes.
Every measurement is segmented by page, device, browser, operating system, country, and connection type, and you can view any window from the last 24 hours out to 90 days. First data appears about an hour after your first visitor.
Key features
All three Core Web Vitals
LCP, INP, and CLS at the 75th percentile, graded against Google's own thresholds. FID is retired and deliberately not collected.
Attribution, not just numbers
Which element was the largest paint, which interaction was slow, which elements shifted — the difference between a score and a fix list.
Six ways to segment
Break any metric down by page, device, browser, OS, country, or connection type — worst-first, so the biggest problem is always at the top.
Field vs lab comparison
Your visitors' LCP set against a scheduled browser check of the same page. When they disagree, the disagreement is itself the finding.
Alerts that don't cry wolf
Fire on entering a bad rating and on worsening within it, with a 24-hour cooldown and a minimum sample floor — to email, Slack, or Microsoft Teams.
Client-ready report section
A Core Web Vitals section in your scheduled PDF: pass or fail, month-over-month movement, and a fix list ranked by visitors affected.
Portfolio view
One Core Web Vitals badge per site across your whole portfolio, sorted worst-first — the agency landing view for forty client sites.
No cookie banner required
No cookies, no local storage, no visitor identifier of any kind. Nothing the snippet does writes to your visitor's device.
What you'll see
The scorecard for a 28-day window, with the good / needs-improvement / poor split behind each number.
Want the lab half first?
The free HTTP Request Timing tool loads any URL in a real headless browser and reports its Largest Contentful Paint and full resource waterfall. No account required — it is the same measurement Real User Monitoring compares your visitors against.
Try the free tool →Related diagnostic tools
Measure the lab side of the same page with these free tools.
Load a URL in headless Chromium and stream every fetch, with timing and a full resource waterfall.
Chain navigate, click, fill, and assert steps into one browser session and verify the journey completes.
Fetch a URL and inspect response headers, status code, and the redirect chain behind it.
Send HTTP requests with custom method, headers, and body, and measure exactly what came back.
Frequently asked questions
What is Real User Monitoring?
Real User Monitoring (RUM) measures page performance from the browsers of the people actually using your site, rather than from a test machine. A small script reports what each visit experienced, and those measurements are aggregated into the Core Web Vitals that Google assesses. Because the data comes from your real traffic, it reflects your actual mix of devices, networks, and geographies — including the segments a test from a datacentre will never represent.
How is this different from synthetic monitoring?
They measure different things and you want both. Synthetic monitoring drives a real browser from our datacentre on a schedule — reproducible, controlled, and it keeps running whether or not anyone visits, which is what catches a broken checkout at 3am. Real User Monitoring is passive: it only sees what real traffic exercises, but it sees it on real hardware. NetTests compares the two directly for the same page, because when our probe is fast and your visitors are slow, that gap is the finding. See Synthetic Monitoring →
Will the script slow my site down?
It loads with the defer attribute, so it never blocks parsing or rendering, and it does its work using browser APIs that are already recording these measurements whether or not you collect them. It sends exactly one request per page view, when the visitor leaves — so it never competes for bandwidth with your own content while the page is loading.
Do I need a cookie banner or consent notice for this?
Nothing in the snippet writes to a visitor's device. There are no cookies, no local storage, no session storage, and no identifier of any kind — which also means there are no cross-page sessions and no returning-visitor metrics, an accepted trade for a Core Web Vitals product. Query strings are stripped before the measurement leaves the page, high-cardinality paths are collapsed into templates such as /order/:id, and no IP address is ever written to disk — the database has no column for one. Country is resolved from a CDN header at the moment of collection and nothing else is retained. As always, confirm your own obligations with whoever advises you on them.
Why report the 75th percentile instead of an average?
Because an average hides the visits that matter. A handful of fast desktop loads will pull a mean down while a quarter of your visitors are having a bad time. The 75th percentile answers a more useful question — was this good for at least three out of four visits — and it is the aggregation Google itself uses to assess Core Web Vitals, so the number you see is comparable to the one that affects your ranking.
What happened to First Input Delay?
FID was replaced by Interaction to Next Paint as a Core Web Vital in March 2024 and has since been removed from Google's field data set entirely. NetTests does not collect or display it. INP is a strictly better measurement: FID only timed how long the first interaction waited to begin processing, while INP measures the full latency of interactions across the whole visit, through to the next frame the user actually sees.
How long before I see data, and how much traffic do I need?
Measurements are aggregated hourly, so the first numbers appear roughly an hour after your first visitor. Interaction to Next Paint only reports once someone actually interacts with a page, so it fills in slightly later than the others. Percentiles need a reasonable sample to be meaningful — a very low-traffic page may show a value for the site overall before it shows one for that individual page.
Stop guessing what your visitors experience
Add one script tag and NetTests reports the Core Web Vitals Google ranks you on, from your own traffic — with the element responsible when a page is slow, alerts when a metric regresses, and a client-ready section in your scheduled report.
Start monitoring free →