Synthetic Monitoring vs Real User Monitoring: Which Do You Need?

Synthetic monitoring runs scripted checks against your site from outside your infrastructure on a fixed schedule, so it catches outages even when no one is visiting. Real user monitoring (RUM) records the experience of actual visitors, so it shows real-world performance across devices and networks. Most teams need both: synthetic for availability and alerting, RUM for real-world speed.

Key takeaways

• Synthetic monitoring is proactive: it tests your site on a schedule from the outside, so it finds problems before a customer does, even at 3am with zero traffic.
• RUM is descriptive: it measures what real visitors actually experienced, including slow devices, far-away networks, and pages you never thought to test.
• Synthetic is your alerting and uptime layer. RUM is your real-world performance and Core Web Vitals layer.
• They are complementary, not competing. Synthetic tells you something broke; RUM tells you who it affected and how badly.
• If you only run one to start, run synthetic monitoring: you cannot fix an outage you never hear about.

What synthetic monitoring is

Synthetic monitoring sends automated, scripted requests to your site from servers around the world on a fixed interval. It does not wait for a visitor. It simulates one, again and again, and records whether the response was correct and how long it took.

Because it runs on a schedule from outside your own network, synthetic monitoring is what catches the failures that matter most:

• A full outage when traffic is low, so you find out before your customers wake up.
• A broken checkout, login or API endpoint, by scripting that exact flow and asserting it still works.
• An expired SSL certificate or a DNS problem, checked from the visitor's side of the connection.
• Slow or failing responses from specific regions, by testing from multiple locations at once.

This is the layer that pages your on-call engineer. Uptime checks, API checks and transaction checks are all forms of synthetic monitoring.

What real user monitoring is

Real user monitoring (RUM) takes the opposite approach. Instead of simulating a visit, it measures actual visits. A small script in the page reports back how long things really took for each person who loaded it.

That gives you data synthetic checks can never produce, because it reflects the messy reality of real traffic:

• Performance on the devices and networks your visitors actually use, not a fast test server.
• Core Web Vitals (LCP, INP, CLS) from the field, which is what search engines grade you on.
• Slow pages and slow regions you would never have written a synthetic test for.
• How performance changes under real load, during a sale or a traffic spike.

RUM cannot alert you to an outage, because if the site is down there are no real users to report anything. What it does is tell you, in the real world, who is having a slow or broken experience and where.

How RUM sampling works

RUM does not have to record every single pageview. On a low-traffic site you can capture 100% of sessions and keep the data volume manageable. On a high-traffic site, teams sample: they collect a representative slice of pageviews instead of all of them, because the marginal cost of storing and processing every beacon outweighs the precision it buys. A well-chosen sample still produces accurate percentiles, which is all the Core Web Vitals assessment needs.

Sampling can happen client-side, where the tracker decides whether to send a beacon at all (which also saves the visitor's bandwidth), or at the collection endpoint after the beacon arrives. The risk with sampling too aggressively is that small but important cohorts disappear: a specific country, a slow device class, or the checkout flow. A common pattern is to keep 100% of sessions that hit an error or a conversion step and sample everything else.

Synthetic vs RUM at a glance

2.5s

LCP good threshold: time to paint the largest element

200ms

INP good threshold: interaction responsiveness

0.1

CLS good threshold: visual stability

75th

percentile of real visits Google scores you at

The numbers RUM actually reports against: Core Web Vitals

Synthetic checks tell you a page is up. Core Web Vitals tell you whether it felt fast to the people who loaded it. Google defines three field metrics, each with a hard cutoff for "good", and judges a site at the 75th percentile of real visits. That last detail is the catch: hitting "good" on your own laptop means nothing if a quarter of your visitors are slower than the threshold. Only real-user field data tells you which side of the line they are on.

In March 2024, Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness metric. FID only measured the delay before the first interaction was handled. INP measures the full latency of interactions across the whole page lifecycle, which makes it much harder to fake in a lab and far more honest about how a heavy JavaScript page behaves.

What drives a poor LCP

Largest Contentful Paint breaks into four phases: time to first byte (TTFB), resource load delay, resource load duration, and element render delay. Google's guidance is that a healthy LCP spends roughly 40% of its time on TTFB and roughly 40% on actually downloading the LCP resource, leaving the two delay phases under about 20% combined.

Real sites rarely look like that. In CrUX field data analysed by the Chrome team, sites with poor LCP spent around 2,270 ms on TTFB alone, plus about 1,290 ms of load delay before the browser even started fetching the LCP image, versus only about 350 ms actually downloading it. The median site with poor LCP waits almost four times as long to start downloading the image as it does to download it, which is why the usual LCP fixes are server response time and removing render-blocking resources, not image compression.

What drives a poor INP

Interaction to Next Paint splits into three phases: input delay (time before any event callback runs), processing duration (time for the callbacks to execute), and presentation delay (time until the next frame paints). An INP at or below 200 ms is good; above 500 ms is poor.

The usual culprit is long tasks on the main thread. Any task that occupies the main thread for more than 50 ms is a long task, and while one runs the browser cannot respond to a tap or paint a new frame. Heavy JavaScript is the most common source: large scripts during load, expensive event callbacks, third-party tags scheduling work, and big DOM updates. It is also why INP is so much harder to pass on phones. In the 2024 Web Almanac, 97% of desktop sites had good INP versus only 74% of mobile sites, a gap of more than 20 points driven by weaker mobile CPUs.

Where Google's field data comes from: CrUX

The 28-day window and the 75th percentile

When Google assesses Core Web Vitals for Search and PageSpeed Insights, it does not run a synthetic test. It reads the Chrome User Experience Report (CrUX), the field dataset collected from real, opted-in Chrome users around the world. CrUX is the official source behind the page experience signal, so the numbers that affect ranking are real-user data, not lab scores.

CrUX reports each metric over a trailing 28-day window. PageSpeed Insights aggregates the previous 28 days and refreshes daily, so a fix you ship today only fully shows up roughly four weeks later, as the old slow days age out of the window. Each metric is judged at the 75th percentile, meaning three out of four pageviews must clear the threshold. That percentile is chosen deliberately so developers see the experience of their more frustrated users, not just the median.

How to read a CrUX field report

A CrUX or PageSpeed field report shows three coloured bars per metric, the share of pageviews that landed in good, needs-improvement and poor, with the 75th-percentile value printed above. To pass, that value has to sit inside the good band: LCP at or under 2.5s, INP at or under 200 ms, CLS at or under 0.1. If a single metric fails, the page fails the overall assessment.

Two things trip people up. First, look at the metric whose poor bar is widest, not the average, because the 75th-percentile rule means your slowest quarter of visits decides the verdict. Second, segment by device: across the web in 2024 only 43% of mobile sites passed all Core Web Vitals versus 54% of desktop sites, so a page that looks fine on desktop can still be failing the mobile assessment that Search uses for mobile results.

Expect your own RUM numbers to differ from CrUX, too. CrUX only covers opted-in Chrome users on sufficiently popular pages and reports on a 28-day lag, while a RUM tool sees every browser in near real time and can slice by release, country or page template. They are complementary: CrUX tells you how Google grades you, and your RUM tells you why, the moment something regresses.

What each one catches that the other misses

The real split is not synthetic versus RUM as rivals. It is lab versus field, and they fail in opposite directions. Lab tests run one device, one network and one fresh cache, on a schedule you control. Field data is a distribution of every real device, network and cache state your visitors actually have.

What synthetic misses, and only RUM catches: a lab test cannot predict when a user will tap, so INP is effectively unmeasurable synthetically. Lazy-loaded images and late ads without reserved dimensions shift layout only after a real person scrolls, so synthetic CLS reads clean while field CLS is poor. And your synthetic agent runs on a fast wired connection from one data center, so it never sees the mid-tier Android phone on patchy mobile data that defines your 75th percentile.

What RUM misses, and only synthetic catches: RUM needs traffic. A page no real user has visited yet, a checkout step behind a login, a new release at 3am, or a low-traffic region produce no field data at all. Synthetic checks run on a fixed cadence regardless, which is why they are the right tool for an API endpoint, an SSL certificate nearing expiry, or an SLA you have to prove uptime against. RUM tells you a problem is happening to someone; synthetic tells you it is happening at all, even at the quietest hour.

Why most teams run both

The two are not competitors, they are two halves of the same picture. Synthetic monitoring is the smoke alarm: it is always on and it wakes you up when something breaks. RUM is the thermostat: it tells you how the room actually feels to the people in it.

Pulsetic covers the synthetic side with uptime and API monitoring from 15-plus locations, and tracks real-world performance with real user monitoring, so the same dashboard answers both "is it up?" and "is it fast for real people?"

See how Pulsetic's uptime and API monitoring catches this from the outside, across 15+ locations.