Active Probing vs. Real User Monitoring: Which Is Better for CDN Performance Evaluation?

When evaluating CDNs, you often encounter two conflicting sets of data: speed-test platforms show most nodes responding quickly, while real users keep reporting slow page loads; or real-user monitoring looks normal, while active probes repeatedly find access failures in a certain country or ISP.

This does not necessarily mean either side is measuring incorrectly. Active probing and real-user monitoring look at two different questions:

• Active probing answers: can this URL be accessed reliably and quickly under predefined regions, networks, and test conditions?

• Real-user monitoring answers: what experience do actual visitors get on real devices, browsers, and networks?

For initial CDN screening, pre-launch validation, cross-region comparison, or failure alerting, active probing is more suitable. To understand core users' real experience, identify affected groups, and measure business improvement, real-user monitoring is more valuable.

A complete CDN performance assessment is usually not an either-or choice: first use active probing to establish a comparable baseline, then use real-user monitoring to verify actual results.

What exactly is the difference between active probing and real-user monitoring?

Active probing, also called synthetic monitoring, probe testing, or Synthetic Monitoring, uses pre-deployed test nodes to send requests at fixed intervals, to fixed URLs, and according to fixed test rules. Even if the website has no real traffic yet, it can continuously produce results.

Real-user monitoring, usually abbreviated as RUM (Real User Monitoring), collects performance data generated during actual visits through monitoring scripts embedded in web pages, browser performance APIs, or client-side SDKs.

In Google's explanation ofthe differences between lab data and field datatests in controlled environments are called lab data, and data collected under real user, device, and network conditions is called field data. The former emphasizes consistency and reproducibility, while the latter reflects actual user experience.

Which CDN assessment tasks are better suited to active probing?

The main value of active probing is not 'simulating every user exactly,' but putting different test targets under conditions that are as consistent as possible.

CDN selection and horizontal vendor comparison

When comparing two CDNs, control variables as much as possible. For example, use files of the same size, the same test times, and nodes in the same regions and ISPs, then observe:

• HTTP status codes and request success rate

• DNS resolution time

• TCP connection time

• Download duration and total duration

• Response IP and changes in it

• Latency percentiles such as P50 and P95

• Failing nodes in different regions and carriers

• Actual throughput for medium or large files

If one vendor is tested on China Telecom in Beijing and another on China Mobile in Guangzhou, the two average times are not directly comparable. A complete CDN performance comparison should also distinguish latency, availability, throughput, and regional coverage; it should not compare only the lowest duration from a single test.

Pre-launch validation and CDN migration

When a new CDN is not yet carrying real traffic, RUM does not have enough data. Active probing can check in advance:

• Whether the domain resolves correctly

• Whether HTTPS requests succeed

• Whether expected nodes are returned in different regions

• Whether abnormal 301 or 302 redirects occur

• Whether 403, 502, 503, or timeouts occur

• Whether performance across mainland China's three major carriers and overseas regions meets expectations

After migration, you can repeat the checks using the same set of URLs and test nodes to reduce interference from changes in test conditions.

Identify regional and carrier-specific failures

When users only say 'the website won't open,' it is hard to tell whether the problem comes from the local network, DNS, CDN, or origin. Multi-region active probing can quickly determine the scope: whether all regions fail, or only a certain country, carrier, or a few nodes are abnormal.

Google Cloud's documentation onsynthetic monitoringalso emphasizes that this type of monitoring sends simulated requests at regular intervals and records availability, latency, and request results, making it suitable for continuous checks of pages, APIs, and critical business processes.

In CdnChart'swebsite speed test toolyou can enter a domain or URL and observe HTTP status codes, response IPs, IP locations, resolution time, connection time, download duration, total duration, redirects, and failing nodes from nodes in different regions and carriers. These results are useful for identifying regional differences and can provide clear direction for further troubleshooting.

What questions is real-user monitoring better at answering?

Active probing can tell you that 'test nodes can access the site normally,' but you cannot infer from that that all real users are fast. Users may be on low-end phones, mobile networks, corporate proxies, home broadband, or cross-border connections; pages may also contain large amounts of JavaScript, images, ads, and third-party services.

These are exactly the factors RUM is good at observing.

Which users are actually affected?

RUM can break down data by country, region, carrier, device, browser, page type, and network conditions. For example, sitewide P75 load time may look normal, but further grouping may reveal:

• Users on mobile networks in Southeast Asia are noticeably slower

• The failure rate for a certain carrier keeps rising

• LCP is poor on low-end Android devices

• Product detail pages are much slower than the homepage

• Cache-miss visits are significantly slower than cache hits

• Performance differs considerably between logged-in and anonymous users

These issues are difficult to fully reconstruct with a small number of fixed nodes.

Is slow page performance really caused by the CDN?

Users perceive the entire page, not an isolated CDN request. Page speed is also affected by origin processing, front-end rendering, image size, JavaScript execution, and third-party APIs.

Therefore, a decline in LCP or page load time in RUM does not directly prove that the CDN has a problem. You need to correlate it with:

• TTFB for navigation requests and static resources

• CDN cache hit status

• Response IP and serving region

• Page version and resource size

• Front-end errors and third-party requests

• Origin processing time

• CDN access logs and origin logs

If static resources respond quickly but LCP is still poor, the problem is more likely in image dimensions, render blocking, or client-side execution, rather than CDN transport itself.

Has CDN optimization improved business experience?

After changing node policies, compressing resources, or increasing cache hit rate, RUM can show whether the performance distribution for real users has changed, and further analyze error rates, bounce rates, or critical business processes.

Here, compare the same user group and page type, not simply sitewide averages before and after optimization. Traffic sources, promotions, device mix, and regional composition can all change the results.

RUM data is not a complete record of all users either

Real-user monitoring sounds 'real,' but it still has sampling boundaries.

If the monitoring script runs only after the page loads, users who abandon the visit, lose connectivity, or fail to load before the script runs may never report data. This creates survivorship bias: the data looks good because the worst visits never made it into the sample.

In addition, RUM is affected by these factors:

• Insufficient website traffic leaves too few samples after regional breakdowns

• Ad blockers or privacy settings prevent the script from running

• Different browser versions expose different performance fields

• User networks and device mix keep changing

• Sampling rate adjustments cause inconsistencies in before-and-after data

• Privacy policies restrict the collection of geolocation or user identifiers

Chrome'sCrUX data methodology documentationalso notes that field data must meet user and site eligibility requirements; not all browsers, devices, and visits enter the dataset, and a page or site must have sufficient traffic.

Therefore, low-traffic websites, newly launched pages, and niche countries usually cannot rely on RUM alone.

Why is active probing normal while real-user monitoring shows slow performance?

This is fairly common and usually means the test nodes do not cover all the conditions real users encounter.

Possible reasons include:

• Active probing uses data center networks, while real users use mobile or home broadband

• The test target is a well-cached static file, while users open a complete dynamic page

• Real pages contain many third-party scripts and cross-origin requests

• Test nodes have high performance, while real users use low-end devices

• Core users are concentrated in regions not covered by active probing

• Personalized content, cookies, or login state cause cache bypass

• First-time visitors need to establish more connections, while probe requests may reuse connections

• The CDN itself is fine, but the origin, API, or front-end rendering is slow

When website performance fluctuates, do not choose just the fastest or slowest single result.How to test CDN speed when a website is sometimes fast and sometimes slowYou need to observe test times, node distribution, failure ratio, and latency percentiles together.

Why is real-user data normal while active probing frequently fails?

The reverse can also happen:

• The region where the probe nodes are located is not the website's target market

• WAF or anti-bot policies block probe requests at a fixed frequency

• The test URL is not representative

• Each probe uses a cold connection, while users' browsers reuse connections

• Real users are concentrated on popular resources that are already warmed up

• Probe requests lack specific cookies, headers, or authentication information

• Some regions have no actual traffic, so RUM has no corresponding samples

If active probing consistently fails in a certain region and RUM has no data for that region, you cannot directly conclude that the failure 'does not affect users.' Users may also have been unable to complete the monitoring script report because the page would not open. In this case, continue checking CDN logs, origin logs, and DNS queries.

Use a browser to inspect the performance phases of a single navigation request

If a full RUM system is not yet deployed, you can first use the browser Performance API to inspect the navigation timing of the current visit:

window.addEventListener("load", () => {
  const nav = performance.getEntriesByType("navigation")[0];

  const metrics = {
    dns: nav.domainLookupEnd - nav.domainLookupStart,
    connect: nav.connectEnd - nav.connectStart,
    tls: nav.secureConnectionStart > 0
      ? nav.connectEnd - nav.secureConnectionStart
      : 0,
    ttfb: nav.responseStart - nav.requestStart,
    download: nav.responseEnd - nav.responseStart,
    total: nav.loadEventEnd - nav.startTime
  };

  console.table(metrics);
});

Output is usually in milliseconds. Focus on the DNS, connection, TLS, TTFB, and download phases. A phase showing 0 is not necessarily abnormal; the browser may be using DNS cache, connection reuse, or preconnect.

This code only inspects one visit in the current browser and cannot replace full RUM. Production collection must also handle sampling, data reporting, cross-origin resource timing, outliers, and user privacy, and should not collect personal information unrelated to performance analysis.

A more reliable CDN assessment process

If you need to choose or validate a CDN for a real business, organize testing in the following order.

1. Define users and business objects first

Identify the main countries, regions, and carriers, as well as the website type. Image sites, download sites, video, APIs, and e-commerce pages do not focus on the same metrics.

At the same time, select representative URLs:

• 
  A small static file to observe connection and baseline latency
  

• 
  A commonly used image or front-end resource to observe cache delivery
  

• 
  A medium-sized file to observe download and throughput
  

• 
  A dynamic page or API to observe the origin fetch path
  

2. Use active probing to establish a control baseline

Test different candidate CDNs from the same nodes at similar times, and record status codes, response IPs, DNS time, connection time, download time, total duration, and failure rate.

Do not save only averages. P50 reflects typical visits, while P95 is better at exposing long-tail problems; failing nodes can reveal regional failures hidden by averages.

CdnChart's publicly availabletesting methodology and scoring criteriaexplain the data sources, coverage conditions, and sample limitations of active probing. Active probing covers the observation nodes that actually participate in the test and is not equivalent to a vendor's complete node list; when samples are insufficient, short-term results should not be treated as long-term conclusions.

3. Route part of real traffic through the candidate CDNs

After entering the trial or POC phase, deploy RUM and run canary traffic validation. To reduce bias, candidate groups should keep regions, devices, page types, and traffic sources as similar as possible.

4. Break down RUM results by user group

Sitewide averages are often not enough. At a minimum, observe:

• 
  Country, region, and carrier
  

• 
  Desktop and mobile
  

• 
  Page type and resource type
  

• 
  Browser and device performance
  

• 
  Cache hits and misses
  

• 
  Percentiles such as P50, P75, and P95
  

• 
  Successful requests, timeouts, and error requests
  

5. Use logs to confirm which layer the problem belongs to

After active probing and RUM detect anomalies, further check CDN access logs, cache status, DNS records, origin logs, and front-end performance.

Only when multiple types of evidence point to the same link can you confidently determine that the problem comes from the CDN. The final decision should also include cost, contracts, technical support, security features, and operational complexity; it should not rely solely on speed test results.

FAQ

Which is more suitable for CDN selection: active probing or real-user monitoring?

Active probing is more suitable for initial screening and horizontal comparison of candidate vendors because test conditions can remain consistent. After entering the trial or POC phase, use real-user monitoring to confirm whether target users actually see improvement.

Is it necessary for small-traffic websites to deploy RUM?

You can deploy it, but samples may be insufficient after breaking down by region, carrier, or page. Small-traffic websites should use active probing as the foundation and treat RUM as a long-term supplement, rather than waiting for a small number of real visits to draw definitive conclusions.

Can TTFB in RUM directly represent CDN performance?

No. TTFB may also include DNS, connection, TLS, CDN processing, cache origin fetch, and origin response. You need to break it down using cache status, response IP, server logs, and active probing results.

Does a larger number of active probe nodes always mean more accurate results?

Not necessarily. Beyond node count, you also need to check whether regions and carriers match real users, whether nodes are healthy, whether tests use the same URLs, and whether samples remain stable over time. A large number of duplicate or business-irrelevant nodes does not necessarily improve decision quality.

Can CrUX directly replace a website's own RUM?

CrUX is suitable for understanding aggregated user experience on eligible sites, but it has limitations in coverage, eligibility, and data granularity. When you need to analyze specific pages, business versions, CDN routes, or custom dimensions, you still need the website's own RUM data.

How long should RUM data be collected?

At a minimum, cover a complete business cycle; do not look only at a few hours or a single workday. Websites with obvious traffic fluctuations usually need to cover weekdays, weekends, and campaign periods, and ensure sufficient samples in each key region.

Will active probing be misidentified by a WAF as an attack?

Probes with fixed frequency, high concurrency, or uniform request characteristics may trigger rate limiting and bot protection. Use reasonable frequencies, identify probe sources, and distinguish real CDN failures from security policy blocks, but do not disable the WAF for long periods just for speed testing.

When the two types of data conflict, which one should you trust?

First determine whether they tested the same regions, URLs, times, and access conditions. Active probing is used to confirm whether the network and delivery path are abnormal; RUM is used to confirm whether actual users are affected. A conflict usually does not mean choosing one to 'trust'; it signals that you need to check user distribution, cache status, page resources, WAF rules, and data sampling scope.