CrUX vs RUM vs Synthetic Monitoring: differences, use cases & guide

Make Uxify one of your go-to sources on Google

Add Uxify on Google

“Should I be using synthetic monitoring, real user monitoring, or CrUX?” It is one of the most common questions we hear from teams setting up performance monitoring for the first time. The honest answer is that the three are not really alternatives to each other. They measure different things, in different ways, for different reasons.

Pick the wrong one for the job and you either miss regressions before they ship, or you optimize for numbers that have nothing to do with what your customers actually experience. So it is worth understanding exactly what each one is, where it shines, and where it falls short.

The short version

Before we go deep, here is the whole thing in three lines:

• Synthetic tells you how a page performs under controlled, repeatable conditions you choose.
• RUM tells you how your site performs for real people, on their real devices and networks.
• CrUX tells you how Google sees your site, based on an opted-in slice of Chrome users.

Now let us break each one down properly.

What is synthetic monitoring (lab data)?

Synthetic monitoring, often called lab data , is performance data collected by running automated tests against your site in a controlled environment. You decide the variables in advance: the device, the browser, the network speed, the geographic location. Then a bot loads the page on that exact profile, on a schedule or on demand, and records what happened.

Lighthouse (the engine behind PageSpeed Insights’ lab scores) and WebPageTest are the tools most people know. You point them at a URL, they run a scripted load on a fixed profile, and they hand you a detailed breakdown: a full request waterfall, render milestones, opportunities to fix, and a score.

Because every test uses the same variables, synthetic data is clean and repeatable. That is its whole advantage:

• It catches regressions. Run the same test on every deploy and any change in the numbers is a real signal, not noise. This makes synthetic ideal for a CI pipeline or a pre-launch check.
• It works before you have any traffic. You can test a staging URL, a page nobody has visited yet, or a redesign that is not live. Neither RUM nor CrUX can do this.
• It gives you deep, per-request detail. The waterfall shows you exactly which script, image, or third-party tag is holding up the page. Great for debugging a specific slow page.
• You can test any URL, including your competitors’. Because you are not relying on a script installed on the site, you can benchmark a rival’s product page the same way you test your own.
• It is the natural home for uptime and availability alerts. A scheduled synthetic check is what tells you the checkout went down at 2am.

The catch is right there in the name. Synthetic tests are not real users. One scripted load on one profile cannot represent the full spread of devices, connections, and behaviors your actual audience brings. Your test might run on a fast wired connection in a datacenter while half your customers are on mid-tier Android phones on patchy mobile data. And because there is no real person behind the test, synthetic data can never tell you whether a slow page actually cost you a sale.

What is Real User Monitoring (RUM / field data)?

Real User Monitoring , or RUM, is the opposite approach. Instead of simulating a visit, it measures actual ones. You add a small JavaScript snippet to your site, and from then on every visitor’s browser quietly reports back on what they experienced: load times, Core Web Vitals , interaction delays, layout shifts, errors, and behavioral signals like rage clicks or U-turns .

The measurement happens inside each user’s own browser, on their real device, over their real network. That is the entire point. Your RUM data reflects every condition your traffic actually encounters, weighted by how often it actually happens: the shopper on an iPhone on hotel wifi, the visitor in Australia on a mid-tier Android, the desktop user routing through a corporate VPN. All of it shows up.

What that buys you:

• It is comprehensive. RUM captures every session across every browser, device, connection, and country your traffic touches, including experiences you never thought to test for.
• It ties performance to the business . Because RUM sees real journeys, it can connect a slow LCP or a janky “Add to cart” button directly to bounce rate, conversion, and revenue. This is the thing no lab tool can do, and it is what keeps performance funded.
• It is near real time. Ship a fix and you see the effect in your data within minutes, not weeks.
• It shows the full distribution. Not just an average, but the 75th and 95th percentiles, so you can see the slow experiences your worst-off users are actually having.

RUM has trade-offs too. It is noisier than lab data precisely because it captures the messy real world, so it takes a little more care to read. It needs live traffic to produce anything, so it is no help on a page nobody has visited yet. And because it relies on JavaScript, ad blockers or a failed script load can leave small blind spots. None of that undermines its role as the source of truth on how your site actually performs.

What is CrUX?

CrUX , the Chrome User Experience Report, is Google’s public dataset of real-world performance. It is the “field data” you see in PageSpeed Insights, the Core Web Vitals report in Search Console, and the CrUX API and BigQuery exports. Technically it is field data, collected from real users, which is why it often gets lumped in with RUM.

But CrUX is a very specific, heavily filtered slice of reality, and the details matter enormously when you try to compare it to anything else:

• It only sees opted-in Chrome users. A session is included only if the user is on desktop Chrome or Chrome on Android, signed into a Google account with history sync on (and no sync passphrase), and has usage statistics reporting enabled. Chrome on iOS is excluded, and so are Safari, Firefox, and everything non-chromium. For many sites that means a large share of traffic, often the majority, is simply not in the data.
• It is a 28-day rolling aggregate at the 75th percentile. The LCP you see is the experience of the worst 25% of qualifying users, averaged over the last 28 days. It is not a live snapshot and you cannot drill into a single session.
• It lags by about two days. After you ship a fix, it takes roughly three days for any movement to appear and a full 30 days for the change to be fully reflected.
• Your site needs enough traffic to qualify. Below a certain threshold (generally in the low thousands of page views a month), Google has no CrUX data on you at all.
• You cannot connect it to your business. There is no way to flag a conversion, segment by campaign, or see bounce rate. CrUX gives you a handful of performance metrics and nothing about what they cost you.

Put plainly: if a RUM vendor pitched you a tool that only saw one browser, only some of its users, only a 28-day average, with a two-day delay and no link to revenue, you would not call it a serious RUM product. So while CrUX is real user data in the strict sense, it is not a substitute for a first-party RUM tool.

Where CrUX genuinely earns its place:

• Search. CrUX is the dataset Google uses to feed its page experience ranking signals. If you care about SEO, you want to know what your CrUX numbers look like, because that is the version of your performance Google is grading.
• Field-based competitive benchmarking. Because CrUX is public, you can pull field data for sites that are not yours. Benchmarking used to be a synthetic-only exercise; CrUX lets you compare real-world numbers against competitors, at least for the traffic CrUX covers.
• A starting point before you have RUM. If you have not installed a RUM tool yet, CrUX gives you some free visibility into the field. Limited visibility beats none while you get set up.

How they compare, side by side

When to use each

The three tools map cleanly onto three different jobs.

Reach for synthetic when you need control and repeatability. Testing a change before it ships, catching regressions in CI, debugging one specific slow page down to the request level, monitoring uptime, or benchmarking a competitor’s page you cannot install a script on. Anytime the value comes from holding the variables steady, synthetic is the right tool.

Reach for RUM when you need the truth about real users. How your site actually performs across the full mix of devices and networks, where friction is costing you conversions, whether a fix moved the numbers for real people, and how speed correlates with revenue. This is your day-to-day source of truth and the data you should be making decisions on.

Reach for CrUX when the question is about Google’s SERP or public benchmarking. Checking how your Core Web Vitals look to the search algorithm, tracking that view over time, or comparing field numbers against competitors. Treat it as a search-and-benchmarking signal, not as your primary performance data.

A simple way to remember it: synthetic guards the release, RUM runs the show, CrUX watches the scoreboard Google keeps.

Do you actually need all three?

For most teams, yes, though not equally.

RUM should be the foundation, because it is the only one of the three that tells you what is really happening to your customers and connects it to money. Synthetic sits alongside it to catch problems before they reach anyone and to cover the cases RUM cannot see, like a page with no traffic yet or a competitor’s checkout. CrUX rounds it out by showing you the specific version of your performance that influences search rankings.

They also explain each other. When your RUM numbers do not match what PageSpeed Insights shows, it is almost never a bug. It is the two datasets measuring different things: your RUM tool sees every browser in real time at full detail, while CrUX shows a 28-day Chrome-only average at the 75th percentile. Neither is wrong. They answer different questions.

Where Uxify fits

Uxify is built to be the RUM layer in that stack, the source of truth on real user experience, and to close the exact gaps CrUX leaves open.

• Reality is our RUM and behavior analytics suite. It tracks Core Web Vitals (LCP, INP, CLS) plus Perceived Load Speed, TTFB, FCP, and thousands of behavioral signals across every real user session. The data is unsampled and updates in near real time, so there is no 28-day lag, no 75th-percentile-only view, and no Chrome-only blind spot. It works across Chrome, Safari, Firefox, and Edge, including iOS Safari, and every signal ties back to conversion and revenue so you can see which friction points actually cost you money.
• Benchmarking and Competitor Intelligence cover the field-based competitive comparison that used to require synthetic tools. You can see how your speed, experience, and engagement stack up against your industry and against specific competitors you choose.
• Ask Uxi lets you query all of it in plain English (“why is my LCP failing on mobile in Germany?”) and get back charts, root causes, and prioritized fixes.
• Navigation AI and INProve go a step further and act on what the data finds, improving LCP and INP automatically without touching your codebase.

For the lab side of the picture, a synthetic tool like Lighthouse is a natural companion for pre-deploy checks and CI. And CrUX stays useful for keeping an eye on the search view. Uxify’s job is to give you the real, revenue-connected truth that neither of those can, and then help you fix what it surfaces.

You can start for free with 2,000 sessions a month and see your own real user data before deciding anything.

Frequently asked questions

Is CrUX the same as RUM?

Not really. CrUX is field data collected from real users, so it is RUM-adjacent, but it is a narrow, filtered version: opted-in Chrome users only, a 28-day 75th-percentile average, a two-day lag, and no link to your business metrics. A first-party RUM tool measures every browser in real time at session-level detail. They overlap in spirit but answer very different questions.

Can CrUX replace a dedicated RUM tool?

No. CrUX is missing most of what makes RUM valuable: real-time data, full browser coverage (including iOS Safari), session-level detail, and the ability to connect performance to conversion and revenue. It is a useful free starting point and a good search signal, but it is not a replacement.

Do I still need synthetic monitoring if I have RUM?

Usually yes. RUM cannot test a page before it has traffic, cannot run in your CI pipeline pre-deploy, and cannot measure a competitor’s page you have no script on. Synthetic covers all of that. The two are complementary: synthetic guards releases and catches regressions, RUM tells you what is really happening in production.

Why don’t my RUM numbers match CrUX or PageSpeed Insights?

Because they measure different things. CrUX only counts opted-in Chrome users (no Safari, Firefox, or iOS), reports a 28-day rolling aggregate at the 75th percentile, and lags by about two days. A first-party RUM tool measures every browser in near real time and shows the full distribution. Neither is wrong; they are answering different questions.

Which one should I set up first?

If you have never measured real user performance, PageSpeed Insights and the CrUX Vis tool are free and take seconds, so start there for a quick read. But to actually improve anything, a first-party RUM tool should be your first real investment, because it is the only source that reflects all your users and ties speed to revenue. Add synthetic for pre-deploy and uptime once RUM is in place.

Does synthetic monitoring measure Core Web Vitals?

It measures lab versions of them. Lighthouse reports LCP, and can estimate INP-style interaction cost, under its simulated conditions. Those lab numbers are useful for catching regressions, but they are not what Google ranks on and they are not what your users experience. For the Core Web Vitals that count, field data from RUM or CrUX is what you want.