Synthetic Monitoring

Synthetic monitoring (also called active monitoring or lab-based testing) collects web performance data in a controlled environment using automated scripts running from fixed hardware, browser, and network configurations. It simulates user interactions on a schedule, measures key metrics, and reports results without requiring real visitors to be present.

How it works

Synthetic monitoring runs scripted probes against URLs at set intervals (typically every 1–30 minutes). The tester controls: browser type (Chrome, Edge), device characteristics (screen size, CPU throttling), network profile (3G, 4G, cable, fibre), and geographic test location. Because conditions are fixed across every run, results can be trended reliably over time. (DebugBear, October 2025)

Lab data is more detailed than Real User Monitoring (RUM) data in one dimension: it is collected via internal browser developer tools rather than JavaScript APIs. Synthetic reports can include video recording of page rendering, full request waterfall (with priorities, HTTP headers, response bodies), detailed CPU task attribution, and iframe processing tasks. (DebugBear, October 2025)

One data-quality risk: some Lighthouse-based synthetic tools report "Simulated" throttling (a post-processing statistical adjustment) rather than actually throttling the network during the test run. Tools using simulated throttling do not produce a real request waterfall — a signal of lower-fidelity results. (DebugBear, August 2026)

Synthetic vs Real User Monitoring (RUM)

Dimension	Synthetic	RUM
Timing	Scheduled, proactive	Always-on, reactive
Environment	Controlled (fixed device/network)	Real visitors (variable device/network)
Coverage	Scripted paths only	All paths real users visit
Staging / pre-launch	✅ Works (no real users needed)	❌ Requires real traffic
Competitor benchmarking	✅ Can run scripts on competitor sites	❌ Not possible
Waterfall / video	✅ Full detail	❌ Limited by browser API access
Conversion correlation	❌ No real outcomes	✅ Links performance to revenue
Sample size	Small (N runs)	Large (real user population)

Division-of-labour framing from practitioners: "Synthetic tells you something broke; RUM tells you who it affected and how badly." (Last9, April 2025)

SpeedCurve's stated position: "you need both — they are not interchangeable." (SpeedCurve docs, ~late 2025)

performance.now() 2024 conference framing (via DebugBear blog): "Synthetic is for testing, not monitoring; RUM is for monitoring."

Synthetic lab data vs CrUX field data

The Chrome User Experience Report (CrUX) is built from real Chrome users who opt into sharing usage statistics, aggregated at the 75th percentile (p75) over a rolling ~28-day window. It powers Core Web Vitals field data in PageSpeed Insights, Google Search Console, BigQuery, and the CrUX API. (Front End Vitals, May 2026)

Key divergence: Interaction to Next Paint (INP)

Interaction to Next Paint (INP) cannot be measured by Lighthouse (the most common synthetic engine) because there is no real user to interact with the page. Lighthouse uses TBT (Total Blocking Time) as its INP proxy, weighted at 30% of the Lighthouse performance score. INP only exists in field data. (multiple sources including web.dev, April 2026)

Why a site can score 95 in Lighthouse but fail CrUX:

1. Real users are on slow mobile networks that lab throttling profiles do not fully simulate
2. Heavy JavaScript hydration (e.g. React/Next.js) — page appears loaded but interactions remain blocked
3. Third-party scripts (analytics, chat widgets, tag managers, A/B tools) add main-thread blocks and layout instability
4. Weak CDN edge coverage — users far from edges see higher TTFB and worse Largest Contentful Paint (LCP)
5. Browser extensions in real users' browsers (absent in lab) can affect INP

(Front End Vitals, May 2026; search result synthesis)

CrUX structural limits:

• Requires minimum traffic thresholds — low-traffic pages and staging environments return no field data
• Origin-level aggregates: a few slow high-traffic pages (heavy PDP template, checkout flow, campaign landing pages) can drag the whole origin's Core Web Vitals down in Search Console (Front End Vitals, May 2026)
• Lab improvements read out immediately; CrUX improvements take days or weeks (28-day rolling average) (Front End Vitals, May 2026)
• Google uses only CrUX field data for search rankings — not Lighthouse lab scores (DebugBear docs; Front End Vitals, May 2026)

Ecommerce use cases

• CI/CD pipeline gates: Lighthouse CI enforces performance budgets on every PR or deploy — builds fail when LCP, CLS, TBT, or JS byte caps are breached (Unlighthouse.dev, April 2026)
• Pre-launch regression testing: synthetic works on staging where no RUM data exists
• Checkout flow scripting: multi-step synthetic scripts simulate the full purchase journey (login → search → PDP → basket → payment → confirmation), catching payment gateway timeouts before real users hit them (Dotcom-Monitor, 2025–2026; iplocation.net)
• Competitor benchmarking: the same test script can be run against competitor sites for direct speed comparison — RUM cannot do this (DebugBear, October 2025; Last9, April 2025)
• Core Web Vitals SEO monitoring: track CWV synthetic proxies to catch regressions before they affect search rankings (dotcom-monitor.com, 2025–2026)

Typical synthetic test frequency: availability checks every 1–5 minutes; complex transaction tests every 15–30 minutes. (Last9, April 2025)

Tooling landscape (as-of 2026-08-31)

Source: DebugBear "The 9 Best Synthetic Monitoring Tools Reviewed For 2026" (published January 2026; updated August 31, 2026) unless otherwise noted.

Commercial tools

Tool	Positioning	Pricing	Notable capability
DebugBear	Synthetic + RUM + CrUX overlay	From $49/mo	Waterfall, CrUX integration, one-click experiments, LCP debug detail
SpeedCurve	Synthetic + RUM, 100+ metrics	From $12/mo	Competitor benchmarks; CPU activity in waterfall; visual filmstrip
Calibre	Synthetic + CrUX + CI/CD API	From $75/mo	CI/CD-first; budget alerts via email/Slack
Datadog	Full observability + synthetic	From $5/mo / 10k checks	Scripted multi-step user journeys; regional uptime
New Relic	Suite including synthetic + RUM	Usage-based	Full session recording; backend trace correlation
Catchpoint / Dotcom-Monitor	Enterprise synthetic, multi-step transactions	—	Scripted checkout-flow monitoring
Pingdom	Uptime + basic synthetic	From $10/mo	Status pages; limited Core Web Vitals (no INP)

Open-source / self-hosted

• Lighthouse CI (@lhci/cli): Google's official tool for Lighthouse in CI pipelines. ~2M monthly npm downloads (as-of 2026). Version 0.15.x, Lighthouse 12.6.1. Lighthouse 13 not yet supported. lhci autorun runs: collect → assert → upload. GitHub App provides PR status checks. (Unlighthouse.dev, April 2026)
• WebPageTest: open-source gold standard for one-off deep diagnostic runs; packet-level throttling (more accurate than PageSpeed Insights' simulated throttling); widely cited as more precise than PageSpeed Insights for synthetic analysis. (YouTube metadata, May 2024)

Field data (not synthetic)

• Chrome User Experience Report (CrUX): Google's real-user dataset — not synthetic, but often confused with it. Powers PageSpeed Insights field data, Search Console CWV, BigQuery, CrUX API. (Front End Vitals, May 2026)

Performance budgets

A performance budget is a threshold that Lighthouse CI enforces in a CI/CD pipeline — builds exit non-zero when breached, blocking merges. Budget types: (1) lab metrics (LCP, CLS, TBT, Lighthouse scores); (2) resource budgets (caps on JS, CSS, image bytes, request counts, third-party weight); (3) custom checks. (technori.com, March 2026; unlighthouse.dev)

Practitioner framing (across implementation guides): "A performance budget without a failing CI check is just a suggestion."

Benchmarks (as-of sources noted)

• Google research: bounce probability increases 90% as load time goes from 1s to 5s. Source: Unlighthouse.dev (April 2026) citing web.dev/articles/why-speed-matters.
• Lighthouse score of 90 = top 8% of all websites (as-of 2026). Source: Unlighthouse.dev (April 2026) citing developer.chrome.com.
• 53% of origins pass all Core Web Vitals (as-of 2025 Web Almanac data, cited April 2026). Source: Unlighthouse.dev (April 2026).
• DORA research: elite performers are 2.6× more likely to have automated performance testing in CI/CD pipelines.

• Typical cost for combined RUM + synthetic monitoring for a medium-sized application: $500–$2,000/month (as-of April 2025). Source: Last9, "RUM vs Synthetic Monitoring" (April 29, 2025).

Key terms

Term	Meaning
Synthetic monitoring	Controlled, scripted performance testing from outside the site
Real User Monitoring (RUM)	Performance data collected from real visitors' browsers
Lab data	Synthetic Lighthouse test result (not real users)
Field data	CrUX-sourced real-user metrics (what Google ranks on)
Performance Budget	Threshold enforced in CI/CD; fails build when breached
TBT (Total Blocking Time)	Lighthouse's lab-only proxy for Interaction to Next Paint (INP)
p75	75th-percentile threshold used by CrUX and CWV pass/fail assessment
Applied throttling	Network throttled during the test run — produces real waterfall
Simulated throttling	Network throttled post-processing — no real waterfall, lower fidelity

What practitioners report

• SpeedCurve: synthetic and RUM are not interchangeable; both are needed. Synthetic provides the consistent baseline and competitive view; RUM provides conversion correlation and real network diversity. (SpeedCurve docs, ~late 2025)
• performance.now() 2024: "Synthetic is for testing; RUM is for monitoring." (via DebugBear blog)
• DebugBear framing: "Synthetic tells you something broke; RUM tells you who it affected and how badly." (Last9, April 2025)
• RUM coverage limits: browser APIs do not report resource size for third-party requests or code running inside iframes. (DebugBear, October 2025)
• Pre-launch / staging coverage is a structural RUM gap — synthetic fills it. (DebugBear, August 2026)

Gaps

• No ecommerce-specific performance budget examples from primary public sources (what thresholds teams actually set for PDP vs checkout pages)
• No retailer-named conversion/performance case studies with measured numbers beyond generic Amazon/BBC stats
• No quantified study on the typical magnitude of lab-vs-field INP divergence
• WebPageTest documentation not fetched in this run — no detailed scripting syntax or self-hosting setup
• Dareboost and Rigor named in prior research but not covered here (low 2025–2026 market visibility)
• No Reddit practitioner voices (MCP unavailable, no web-search threads found)