Performance monitoring conversations often collapse two different questions into one: "Are we fast in a controlled test?" and "Are we fast for real visitors?" Synthetic monitoring answers the first; real user monitoring (RUM) answers the second. Teams that pick only one layer usually discover the gap after a deploy, when lab scores look fine but conversion drops on mobile, or when CrUX turns red a week later. What follows is a practical split for web teams and agencies: what each method measures, when each is worth the operational cost, and how scheduled PageSpeed monitoring with CrUX context fits beside first-party RUM without forcing a rip-and-replace.
What is synthetic monitoring for web performance?
Synthetic monitoring runs automated tests against URLs you choose, on a schedule you control, in a lab environment, loading each page with a fixed device profile, simulated network, and throttled CPU (for example Lighthouse mobile emulation through PageSpeed Insights) so results stay comparable run to run.
Typical outputs include:
- Core Web Vitals from the lab run (LCP, INP, CLS where Lighthouse reports them).
- Lighthouse Performance score and supporting timings (FCP, TBT, Speed Index).
- Diagnostics and opportunities (render-blocking resources, image sizing, third-party cost).
- Chrome User Experience Report (CrUX) percentiles when Google publishes field data for that URL and strategy.
Synthetic monitoring is not a one-off PSI paste into a browser tab. It is the same class of measurement, repeated and stored so you can trend, alert, and report. Our PageSpeed Insights vs automated monitoring guide explains why spot checks fail once you manage more than a handful of URLs. Agencies use synthetic schedules to cover client portfolios (homepage, pricing, lead forms, checkout paths, and campaign landers), usually on both mobile and desktop strategies.
What is real user monitoring (RUM)?
Real user monitoring collects performance data from actual browser sessions on your site. A JavaScript snippet, or tag manager injection, records timings, navigation, and often custom attributes (logged-in state, plan tier, locale) as users browse, which is why RUM reflects real networks, devices, cache states, ad blockers, and consent banners rather than a fixed lab profile.
First-party RUM products (PageVitals, DebugBear, SpeedCurve, Datadog RUM, and others) let you:
- Segment by page, device, geography, and custom tags.
- See distributions and percentiles from your traffic, not only Google's aggregate.
- Monitor routes CrUX rarely covers well (authenticated app shells, low-volume templates).
- Tie performance to business events when you connect analytics or product data.
That traffic mix is also why RUM is harder to compare week to week unless you control for seasonality and campaigns. For metric definitions shared by both lab and field programmes, start with What Are Core Web Vitals? and LCP, INP, and CLS explained.
CrUX vs first-party RUM: both are field data, but not the same thing
Teams comparing RUM vs synthetic monitoring sometimes treat CrUX as "free RUM," yet it is field data without session-level detail, and that distinction matters when you choose tooling or write a client report.
| Source | What it is | Strength | Limit |
|---|---|---|---|
| CrUX | Google's aggregated Chrome experience for URLs with enough traffic | Aligns with Search Console and SEO reporting; no snippet required | Rolling window; URL-level; limited segmentation |
| First-party RUM | Your snippet on your origin | Session paths, custom tags, logged-in views | Consent, tag governance, maintenance per site |
| Synthetic lab | Scheduled Lighthouse-style runs | Same-day, repeatable, works on staging | Simulated users, not real cache or ad mix |
PageSpeed Insights and many monitoring tools show CrUX beside lab results, which helps public marketing URLs, but that pairing does not replace RUM when stakeholders ask what paying customers on 4G in Germany experience on a specific checkout step. Mobile vs desktop Core Web Vitals monitoring matters here as well: CrUX and lab both split by strategy, yet RUM segmentation is where device and connection reality show up for product decisions.
Synthetic vs RUM: comparison for web teams
| Question | Synthetic (scheduled lab) | First-party RUM |
|---|---|---|
| Needs a script on the site? | No | Yes |
| Works on staging / pre-release URLs? | Yes | Usually no (no real traffic) |
| Comparable numbers every run? | Yes | Depends on traffic mix |
| Catches deploy regressions same day? | Yes, if scheduled | Yes, with enough sessions |
| Good for SEO / CrUX alignment? | Lab + CrUX in PSI output | CrUX separate; RUM is your own dataset |
| Portfolio scale without per-site snippets? | Favourable for agencies | Harder (consent and client approvals) |
| Multistep flows (checkout, signup)? | Per-URL unless tool supports journeys | Strong when tagged correctly |
Neither approach wins outright because they answer different risk questions: synthetic shows whether yesterday's release broke lab thresholds on URLs you list, while RUM shows whether real users felt it across segments you care about.
When synthetic monitoring is the right choice
Choose synthetic as your primary web performance layer when you manage many sites or URLs and need one schedule, one history store, and one alert policy without installing tags on every client origin. That is the common agency constraint on marketing sites, brochureware, and public app URLs where the client will not approve another analytics script.
Synthetic also fits when you need repeatable baselines before and after a change. Lab runs on the same URL, strategy, and daypart make comparisons honest, whereas field data drifts when traffic mix shifts. The same logic applies to low-traffic or new pages where CrUX may show "no data" for months while scheduled lab runs still return LCP, INP, and CLS every time.
Use synthetic for staging, preview, or password-protected builds before production, because RUM cannot run where users do not visit yet. Pair schedules with performance budgets and alerts when you need a steady measurement source, and with portfolio reporting when clients want trend lines instead of a PDF assembled from manual PSI tabs; Automated vs manual PageSpeed testing shows the time cost when that layer is missing. Synthetic monitoring still does not replace backend APM, error tracking, or session replay: it measures web URLs in the browser lab, plus CrUX where published, not API latency inside your cluster.
When real user monitoring is the better fit
Choose first-party RUM when authenticated experiences dominate the product. Dashboards, account settings, and checkout after login often lack stable CrUX samples, and RUM with custom tags is how you prove INP on those routes. The same applies when stakeholders require segment-level proof by plan tier, locale, experiment bucket, or campaign source, because CrUX will not break down your traffic that way.
RUM also belongs in the stack when you already operate observability tooling and need web vitals beside traces and errors, when CI/CD or feature flags need session-level validation after release, or when multistep journeys must be measured as flows rather than isolated URLs. Legal and client approval for another script varies by estate, and if RUM is already installed you can add synthetic for URLs RUM under-samples or for pre-production checks, while teams with synthetic schedules add RUM where lab and CrUX disagree with support tickets or conversion data.
How agencies combine synthetic and RUM across client portfolios
Agencies rarely get a single answer across thirty clients, but a workable default is to run scheduled synthetic on mobile and desktop for public marketing and lead-gen URLs, read CrUX from the same test results, and keep budgets and alerts in one place without a snippet on every domain. For flagship SaaS or ecommerce clients with RUM already installed, keep their RUM vendor for logged-in app routes and use synthetic for the URLs the retainer covers and for prospects during performance audit outreach; when clients refuse third-party scripts, synthetic plus CrUX is often the entire programme, so say that explicitly in proposals rather than implying session replay is included.
In client reporting, separate slides for lab trends on priority URLs and for RUM segment summaries from the analytics team. Blending both into one green chart invites arguments about methodology. For tool selection by client shape, see comparing PageSpeed monitoring tools for agencies and PageVitals vs Apogee Watcher when RUM and CI/CD are part of the brief. SaaS product teams face a similar split at single-company scale; our SaaS performance monitoring guide covers URL priorities without repeating the full decision tree here.
How scheduled PageSpeed monitoring fits beside RUM vendors
Apogee Watcher is built for scheduled synthetic monitoring across many sites: PageSpeed Insights-backed lab runs, CrUX when Google returns field data, vitals and optional FCP/TBT budgets, portfolio alerts, and multi-tenant organisations for agencies. We do not ship first-party RUM; we sit beside RUM, APM, and Lighthouse CI gates rather than replacing them, so when a client needs session-level RUM, PageVitals, DebugBear, or an observability vendor still belongs in the stack.
Watcher is often the better primary monitor when you run many client domains under one subscription without per-site RUM rollout, when automated page discovery should keep new templates on the schedule without spreadsheet maintenance, when retainers promise ongoing CWV oversight on public URLs rather than full product instrumentation, or when you want prospecting and free evaluation via the domain PageSpeed check before a client signs. Configure mobile and desktop strategies per URL, set budgets, route alerts, and review history in the app, and use RUM elsewhere when the question requires your traffic, your tags, and your logged-in routes.
FAQ
What is the difference between RUM and synthetic monitoring?
Synthetic monitoring runs controlled lab tests on chosen URLs on a schedule. RUM records performance from real user sessions in the browser, usually via a script you install. Synthetic is repeatable and works without site traffic; RUM reflects actual devices, networks, and behaviour, which is why most mature teams treat the two as complementary rather than interchangeable.
Is CrUX the same as RUM?
No. CrUX is Google's aggregated field dataset for URLs with sufficient Chrome traffic, while RUM is first-party data you collect from your visitors. Both describe real loads in the field sense, but CrUX is not session-level RUM and cannot replace custom segmentation on your origin.
Should I use synthetic or RUM for Core Web Vitals?
Use both when you can. Synthetic and CrUX (via scheduled PSI runs) cover public URLs, staging, and low-traffic pages; first-party RUM covers segmented and authenticated experiences CrUX does not explain. SEO and client reporting often lean on CrUX, while product teams often lean on RUM for route-level proof.
Do agencies need RUM on every client site?
No. Many retainers cover public marketing and key templates where synthetic plus CrUX is enough, and you add RUM when the contract includes logged-in app routes, the client already owns a RUM tool, or stakeholders require session-level segmentation that CrUX cannot supply.
Can synthetic monitoring replace RUM?
Not fully. Synthetic answers whether lab thresholds breached on listed URLs, while RUM answers what users experienced broken down by segment, so use synthetic for portfolio scale and pre-release checks and RUM where traffic truth and custom tags matter.
Does Apogee Watcher include RUM?
No. Watcher schedules PageSpeed lab tests and shows CrUX where available, and you should layer it with your RUM or observability vendor when you need first-party session data on authenticated or heavily segmented routes.
How often should synthetic tests run compared to RUM sampling?
Synthetic frequency is a schedule you set (daily, weekly, or higher on risky URLs), while RUM sampling is continuous or rate-limited by your vendor. Match synthetic cadence to release risk, use RUM for always-on field truth where installed, and see test frequency and priority across a portfolio for scheduling patterns across many sites.
Pick synthetic when you need repeatable lab coverage at portfolio scale without a snippet on every domain, and RUM when session segments and authenticated routes drive decisions. Most mature stacks use both, with clear owners for each signal, rather than debating which single tool should own performance end to end.
Start a free Apogee Watcher account to schedule mobile and desktop tests with vitals budgets across your sites, or run a free domain PageSpeed check to baseline a URL before you add RUM or expand monitoring.
Top comments (0)