Real User Monitoring vs Synthetic Tests for Website Speed

Short answer: A synthetic test loads your page from a chosen place with chosen settings and gives a repeatable result. Real user monitoring collects measurements from the browsers of actual visitors and shows what they experienced. Synthetic tests are best for finding causes and catching regressions before launch. Real user data is best for knowing whether visitors are happy. Most sites need both.

What a synthetic test is

A synthetic test, also called a lab test, is a controlled experiment. A tool opens your page in a browser that it runs itself, with a set device speed, network speed and location, and records what happens. Lighthouse, the lab part of PageSpeed Insights and WebPageTest work in this way. The conditions are the same each time, so a change in the result points to a change on the site.

The strength of this method is control. You can test a page before it is live, compare two versions, throttle the network to see the effect on slow connections and get a detailed waterfall of every request. The guide to reading a waterfall chart shows how to use that detail.

What real user monitoring is

Real user monitoring, often shortened to RUM, collects timing data from real visitors as they use the site. A small script in the page, or the browser itself, records measures such as when the main content appeared, how much the layout moved and how quickly the page responded to taps. The data is sent to a collection service and combined into reports.

The Chrome User Experience Report is a public example. It gathers measurements from consenting Chrome users and powers the field data in PageSpeed Insights and Search Console. The article on field data and the Chrome UX Report explains where the numbers come from and how long they take to change. Your own RUM tool can show the same kind of data for every page and every visitor group, and not only for the ones that Google reports.

The differences at a glance

Who is measured. A synthetic test measures one simulated visitor. RUM measures everyone who loads the page.
Conditions. A lab test fixes them. RUM captures the full range of phones, networks, locations, browsers and extensions.
Repeatability. Lab results are stable enough to compare. RUM results vary with traffic, and you need enough visits to see a trend.
When you can use it. A lab test works on a staging site or an unreleased page. RUM works only after real people visit.
Depth. A lab test gives a detailed trace. RUM gives breadth, but only the measures the browser reports.
Interactions. A lab test usually does not click or type unless scripted. RUM records real interactions, which matters for responsiveness.

Why the numbers disagree

Owners are often confused when a lab score looks good and the field data looks bad, or the other way around. The disagreement is normal, and it has clear causes.

Device and network. Your test uses a standard profile. Real visitors may be on older phones and weak connections, which are slower than the test setting, or on fast laptops that are quicker.
Caching. A lab test usually loads a page cold. Returning visitors may have files already stored and see faster loads.
Logged-in and dynamic pages. Tests of a public page do not show what a signed-in customer sees. See the guide to speed testing logged-in pages.
Interaction. A lab test stops after loading. A real visitor scrolls, taps menus and fills in forms, and the page may respond slowly to those actions. The metric covered in the guide to Interaction to Next Paint is based on such real interactions.
Time and traffic. A test run at midnight shows a quiet server. Real visitors arrive at busy times.
Averages and percentiles. Google assesses Core Web Vitals at the 75th percentile of visits, which means that a quarter of visits can be worse than the reported figure. A single lab run is one sample, not a distribution.

Because of this, a lab score may change every time you test. The article on why your PageSpeed score changes explains the sources of noise.

What each method is best at

Use synthetic tests to

find which resource or script causes a slow page, and compare options;
test before a launch, a redesign or a new plugin goes live;
catch regressions after each deployment, as described in the guide to performance regression testing;
check a competitor or a page that you do not own;
test slow connections and low-end phones on purpose.

Use real user monitoring to

know whether real visitors pass the Core Web Vitals thresholds;
find which pages, countries, devices or browsers are slowest;
see the effect of a change on actual people, over days and weeks;
connect speed to business results, such as bounce rate or orders;
detect problems that appear only in the wild, such as a slow third-party service in one region.

Limits and risks of each

Synthetic tests can mislead if you treat the score as the goal. A page may reach a high lab score and still feel slow, because the test did not include a heavy script that runs later, or a region with poor connections. Optimising only for the tool is a known trap.

RUM has its own problems. It needs enough traffic, and a small site may see few visits per page. It also takes time to react, because you must wait for data after a change. Scripts that collect data add a little weight, so choose a light one. Because it handles visitor information, it must respect privacy rules and consent settings where they apply, and it should not collect personal data that it does not need. Finally, an average hides the slow tail. Always look at percentiles and not at the mean.

A practical way to combine them

Start with free field data. Look at the Core Web Vitals report in Search Console and at the field section of PageSpeed Insights. This tells you whether a problem exists at all. See the guide to the Core Web Vitals report.
Find the slow page types. Group by template, such as home, article, product and checkout, and not by single address.
Reproduce with lab tests. Test those templates on a throttled mobile profile and find the cause in the waterfall.
Fix one thing at a time and test again in the lab to confirm the improvement.
Watch the field data. Allow a few weeks for the public report to catch up, or check your own RUM for a faster read.
Set up continuous checks. Run a few scheduled lab tests on key pages, and keep monitoring, as in the article on website speed monitoring.

Small sites with little traffic can start without any paid RUM tool. Public field data plus regular lab tests cover most needs.

Which metrics each method covers

The two methods do not report exactly the same measures, which is another reason for the differences between them. Knowing the overlap helps you to read both.

Largest Contentful Paint and Cumulative Layout Shift. Both methods report them. In the lab they are measured for one load, and in the field they are measured across many visits and many screen sizes.
Interaction to Next Paint. This one needs real interaction, so it exists as a field measure. Lab tools often show Total Blocking Time instead, which is a stand-in for how busy the main thread is. See the guide to Total Blocking Time. The two numbers are related but not equal.
Time to First Byte. Both can measure it, but lab tests show the server from one place, while field data reflects distance, DNS and connection setup for each visitor. The article on server response time covers the causes.
Custom measures. RUM tools can record events that matter to you, such as the time until a product photo or the search box is visible. Lab tools can do the same only through scripts that you write.

When the numbers disagree, compare the same metric for the same page type before you draw conclusions. A lab Largest Contentful Paint on mobile and a field Largest Contentful Paint at the 75th percentile are the closest pair.

How Site AI Audit helps

Site AI Audit is a lab-style check run on demand: it measures the Google PageSpeed score, Core Web Vitals, server response time, compression and page weight for the pages it crawls, and ranks the findings by impact. It does not collect data from your visitors, so it complements field data and does not replace it. Re-checks show whether a change helped. The free check covers up to 50 pages and needs no sign-up. You can run a free check of your website or see the plans for weekly monitoring and alerts.

The bottom line

Lab tests tell you why a page is slow, and real user data tells you whether people feel it. Use field data to decide where to look, lab tests to find and fix the cause, and field data again to confirm the result.

DUK

Which is more accurate, lab or field data?

They answer different questions. Field data is more accurate about what visitors experienced. Lab data is more accurate about causes, because it is repeatable and detailed.

Does Google use lab or field data for ranking?

Google’s page experience signals use field data from real users, such as the Chrome UX Report. A lab score is a guide for fixing, not the number that is assessed.

Do I need a paid RUM tool?

Not at first. Search Console and PageSpeed Insights show public field data. A paid or self-hosted tool helps once you need per-page detail or faster feedback.

Why does my site have no field data?

The public report needs enough visits from supported browsers. A small or new page may not qualify. Use lab tests and your own measurements until traffic grows.

How often should I run synthetic tests?

After each release, and on a schedule for your most important pages, such as daily or weekly, depending on how often the site changes.