The most popular advice about synthetic vs real user monitoring is also the least useful: choose the method that fits your team. That frames two different measurement systems as interchangeable alternatives. They aren't. Synthetic monitoring tells you what a controlled test changed, while Real User Monitoring, or RUM, shows what visitors experienced across devices, browsers, networks, and locations. Google's PageSpeed Insights guidance on lab and field data treats them as complementary layers, and that distinction matters whenever dashboards disagree.
Reading time: 8 minutes
Author: PageSpeed Plus staff
If your team is troubleshooting a performance regression, start by separating the question you're asking from the tool you're using. Use the lab to isolate a change. Use the field to determine whether that change helped the production audience. For teams that need both views, Real User Monitoring for production experience provides the field perspective that scripted checks can't supply.
Synthetic tests and RUM don't measure the same population, under the same conditions, or for the same purpose. A scripted browser follows a known path with a defined device and network profile. RUM observes sessions that already exist, including combinations of hardware, browsers, connection quality, geography, and application state that your test plan may never have anticipated.
Google's PageSpeed Insights model formalizes this split. Lab data is collected in a controlled environment for debugging, while field data is historical and anonymized, collected from real users. PageSpeed Insights reports field Core Web Vitals over a previous 28-day collection period, including FCP, INP, LCP, and CLS. The lab and field distinction documented by web.dev uses the same practical language: synthetic data comes from predefined conditions, while field data reflects actual visitors.
| Measurement layer | Main question | What it's good at | Main blind spot |
|---|---|---|---|
| Synthetic monitoring | What changed under fixed conditions? | Debugging and regression detection | Real-world variability |
| RUM | What did visitors experience? | Production distribution and segmentation | It depends on actual traffic |
The mistake is treating a green synthetic result as proof that every visitor is having a fast session. It only proves that the tested scenario behaved acceptably under the selected conditions. Conversely, a poor RUM result doesn't immediately identify the code or dependency responsible. It tells you where the experience is failing, not necessarily why.
Practical rule: Use synthetic data to reproduce and isolate. Use RUM data to prioritize and verify production impact.
A complete performance practice therefore needs two layers. Removing either one creates a predictable blind spot: synthetic monitoring misses untested user conditions, while RUM can't validate a page or journey before users reach it.
Synthetic monitoring runs an automated browser or request against a chosen URL, flow, or endpoint. The test can define the browser profile, network behavior, and measurement location, then repeat the same scenario so engineers can compare releases against a stable baseline. SpeedKit's explanation of synthetic testing describes the central trade-off clearly: scripted tests are reproducible, while RUM captures production conditions.
A useful synthetic run records more than a single score. It can expose a resource timing waterfall, response timing, rendering milestones, and lab versions of metrics such as LCP, INP, and CLS. Repeating a test reduces the chance that one noisy execution will drive a false conclusion, especially when caches, connection setup, or third-party resources behave differently between runs.
The lab is strongest when the team needs a clean experiment. Change a JavaScript bundle, alter CSS delivery, replace an image format, or modify server behavior, then run the same scenario before and after the change. If the result moves, engineers have a controlled signal that helps narrow the investigation.
Synthetic monitoring also supports proactive testing for performance, particularly when a team wants to exercise important URLs before a release reaches visitors. The Trackingplan guide to synthetic monitoring offers useful context on that preventive role. PageSpeed Plus also describes automated synthetic monitoring workflows for scheduled URL checks.
Control has a cost. A lab run can't reproduce every browser implementation, device capability, network route, cache state, or third-party timing pattern found in production. It can tell you that a release regressed under the selected test profile, but it can't establish how broadly that regression affects the visitor population.
RUM instruments the page so timing information can be collected during genuine browser sessions. Instead of asking a virtual visitor to follow a fixed script, it records the conditions surrounding real navigation and interaction, then groups the results by useful dimensions such as device, browser, country, and time period.
The value isn't a single average. RUM exposes the distribution of experiences. A desktop session on a strong connection may look healthy while a mobile segment encounters delayed rendering, slow interaction processing, or layout movement. Field data makes that split visible because it preserves the conditions attached to each experience.
Google defines the Core Web Vitals boundaries as follows in its PageSpeed Insights metric documentation:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 seconds or less | Above 2.5 to 4.0 seconds | Above 4.0 seconds |
| INP | 200 milliseconds or less | Above 200 to 500 milliseconds | Above 500 milliseconds |
| CLS | 0.1 or less | Above 0.1 to 0.25 | Above 0.25 |
Those thresholds help classify field behavior, but the diagnostic value comes from segmentation. Filter a degraded LCP result by device or country. Examine whether poor INP clusters around a browser family or a particular application state. Compare the current period with the historical window instead of reacting to one isolated session.
Real visitors load content through different network conditions and use devices with different rendering capabilities. They also encounter production cache behavior, consent flows, experiments, and third-party code in combinations a scripted test may not include. RUM can expose those patterns without requiring the engineering team to predict them first.
The limitation is equally important. RUM can't report on a path that receives no traffic, and it won't provide a controlled explanation for every regression. It tells you who experienced the problem and how the experience varies. Synthetic testing remains necessary to reproduce the suspected cause.
The terms can create unnecessary confusion. Documentation commonly uses lab data and synthetic data interchangeably, just as field data and RUM often describe the same production-oriented layer. The labels matter less than the collection method and the decision the data supports.
| Criterion | Synthetic Monitoring | Real User Monitoring |
|---|---|---|
| Data source | Scripted browser or request under fixed conditions | Actual visitor sessions |
| Variability | Intentionally constrained | Reflects real device and network diversity |
| Debugging value | Precise comparison after a code or configuration change | Strong evidence of affected user segments |
| Feedback timing | Immediate after a scheduled or deployment test | Available as sessions generate field data |
| Coverage | Defined URLs, journeys, and locations | Visitor behavior and conditions that actually occur |
| Best use | Regression detection and controlled diagnosis | Production validation and experience analysis |
| Main weakness | Doesn't represent every real-world condition | Doesn't explain root cause by itself |
Synthetic monitoring wins when reproducibility is the priority. If a release changes the waterfall, engineers can compare the same request sequence and inspect the resource responsible. It also gives teams a signal when traffic is low or when a new journey has not yet reached production.
RUM wins when the question is population-specific. A field result can show that one device segment or geography carries the degradation while another remains stable. That distinction prevents a team from optimizing a healthy synthetic profile while overlooking the users who are struggling.
For a broader view of the measurements teams should collect, the web site metrics guide is a useful reference. The key is not to collapse every metric into one score. Keep the controlled signal and the production distribution separate, then correlate them during investigation.
Conflicting results aren't automatically evidence that one monitoring system is broken. They usually mean the two systems are observing different conditions. A lab test may improve after a bundle change while field LCP worsens because the affected users are on different devices, through different networks, or receiving a different cache state.
Start with the release boundary. Run the synthetic test against the previous and current versions, inspect the waterfall, and verify that the test used comparable cache and network settings. If the lab result changed, identify the exact request or rendering step responsible before making a production-wide conclusion.
Then move to RUM segmentation. Filter the field data by device, browser, geography, and time period. A degradation isolated to one segment points toward a compatibility, rendering, delivery, or network-condition issue rather than a universal application regression. A broad change across segments suggests a more general release, backend, or delivery problem.
A lab improvement is a hypothesis about production. RUM is the check that determines whether the hypothesis held.
For a structured way to examine the difference between controlled and field outcomes, use a performance gap analysis workflow. The accompanying video can also help teams visualize why the two signals diverge.
A workable strategy assigns each system a clear job instead of asking both to produce the same answer. Schedule synthetic checks for important URLs and journeys, then run them after deployments or on a recurring schedule that matches the risk of the application. Use RUM continuously to observe how those changes behave across the live audience.
Alerting should preserve that distinction. A synthetic alert can identify a failed check or a regression in a controlled profile. A RUM alert can identify deterioration in a field metric or segment. Send both to the team's existing channels, such as email, Slack, or Microsoft Teams, but route them to different investigation playbooks.
Sitemap-driven scans are useful for sites with many templates and deep URLs. A homepage test can remain healthy while an inner template carries the expensive script or layout behavior. Bulk testing finds those patterns without requiring engineers to select every URL manually.
Public dashboards and shareable reports help product, support, and client teams see the same evidence without giving every stakeholder access to the monitoring system. Competitor comparison charts can provide context, but they shouldn't replace diagnosis. A comparison may show that a page is slower than its peers, yet only the waterfall and field segmentation can explain the cause.
Synthetic monitoring also belongs beside infrastructure visibility. Teams evaluating broader server monitoring tools from ARPHost can use that layer to investigate resource or availability conditions that browser measurements alone can't explain. The monitoring stack works best when each signal narrows the next question.
PageSpeed Plus combines lab measurements and field measurements in one monitoring workflow. Its synthetic checks support mobile and desktop monitoring, measurements from up to 11 locations, scheduled URL scans, sitemap-driven testing, historical trends, and alerts through email, Slack, and Microsoft Teams. Its RUM feature captures LCP, INP, CLS, and TTFB with filters for device, time, and country.
The practical advantage is the connection between detection and remediation. The PageSpeed Plus WordPress plugin provides page caching, Gzip and Brotli compression, JavaScript delay, CSS optimization, and WebP or AVIF lazy-loading. The platform also includes cache warming, Google Sheets export, public dashboards, and an API for custom integrations. For teams designing the wider system around application architecture and delivery, this architectural performance guide adds useful implementation context.
Use the synthetic layer to catch controlled regressions, then use RUM to determine whether real visitors improved. That workflow avoids the most expensive monitoring mistake, treating a clean lab score as the final answer.
PageSpeed Plus combines synthetic checks, field Core Web Vitals, segmented RUM, alerts, and WordPress remediation in one workflow. Visit PageSpeed Plus to start monitoring your site with both layers and investigate conflicting performance results before they become production blind spots.