The RUM Diaries: enabling Web Analytics by default

From Browser to Origin: Closing the Performance Visibility Gap

Diagnosing performance problems on the web is notoriously difficult because a single page load traverses many independent systems: the user's device, the browser, DNS, the network, Cloudflare's edge, and the origin server. Each hop adds its own variable latency, from bandwidth constraints to server CPU load to third-party scripts. Observability tooling helps, but engineers still face the hard problem of correlating front-end events with network timing and server logs to pinpoint the actual cause of slowdowns.

To address this, Cloudflare is announcing the start of a major upgrade to its performance analytics suite. Web Analytics, part of the company's real user monitoring (RUM) tools, will soon be combined with network-level insights. The goal: a single view that traces a packet's entire journey—from a visitor's browser, through Cloudflare's network, to the origin—so developers can see where and why latency occurs. Crucially, this depth of insight will not come at the cost of user privacy. Client-side metrics like Core Web Vitals will be correlated with network and origin data while aggregating data by visits and dropping client-specific information.

Key Milestones

Two dates matter here. On October 15, 2025, Cloudflare will enable Web Analytics for all free domains by default. This gives site owners real-time visibility into how visitors around the world experience their site, with no collection of personal data. By the middle of 2026, Cloudflare plans to deliver a comprehensive, privacy-first platform for performance monitoring and debugging that helps you fix bottlenecks, not just observe them.

You can explore the journey in this series, The RUM Diaries, which will cover how Web Analytics works, real-world debugging examples, and tips for getting the most from Cloudflare's analytics tools.

The Gap in Today's Tools

Traditional performance monitoring products usually focus on a narrow layer of the stack—either the client or the origin—and treat everything in between as a vague "processing time." For modern, increasingly complex web applications, knowing that a page was slow is not enough. Teams need to understand why a bottleneck happened: Was it a network condition? A code change? A single external script?

Consider Shannon, an e-commerce operator in Detroit selling rare watches to global customers. Symptom: complaints about slow loads from German buyers, while her own tests in Michigan look fine. A synthetic monitoring tool might tell her "server processing time" is the culprit in Germany, but she still can't decide whether to add a server in Europe, tweak her CDN configuration, or blame her user's transit connection. This is a three-option puzzle: networking problem, server problem, or something else?

Cloudflare is positioned to solve this puzzle. As a reverse proxy between client and origin, it is often the first server a user connects to. Because Cloudflare also can generate responses at the edge (e.g., Workers), steer traffic across its dedicated backbone, and route around congestion via Argo, it can correlate:

• client performance data
• real-time network metrics
• customer configuration settings
• origin performance measurements

That combination illuminates what's hidden in the vague "processing time" metric, letting developers understand what specific knob to turn to make their site faster.

How Web Analytics Works

Web Analytics measures real visitors by adding a lightweight JavaScript snippet to your website. In the dashboard, you see aggregate performance data, including how the browser painted the page (via LCP, INP, and CLS), load time metrics tied to server processing, and aggregate visitor counts. If you've used DevTools to inspect a slow page's waterfall, you have a sense of what Web Analytics does—except it works from the browsers of actual users across the world, not just your local machine.

The architecture has two main parts:

The Browser Beacon

Each tracked page includes a tiny, asynchronously loaded JavaScript snippet that does not block rendering. This snippet hooks into modern browser APIs like the Performance API and Resource Timing to collect Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint), resource load times, and TLS handshake duration from the client's perspective.

Aggregation at the Edge

When the browser sends performance data, it goes to the nearest Cloudflare data center. Raw events are not pushed straight to a database; instead, they are pre-processed at the edge. This reduces storage needs, minimizes latency, and removes personal identifiers like IP addresses. Only then is the data forwarded to a core data center for querying.

You will find Web Analytics under the Analytics & Logs section of the dashboard, at both the account and domain level. Starting October 15, 2025, free domains will have it enabled by default. Pro, Business, and Enterprise accounts can enable it by selecting the hostname and choosing Automatic Setup, or by manually pasting the JavaScript beacon before the closing </body> tag on any HTML page using the "manage site" option.

Once enabled, the dashboard provides client-side performance metrics alongside resource attribution tables, which break down which assets consume the most load time per metric. This helps you identify the specific resources worth optimizing.

What Privacy-First Means Here

Privacy-first is a design principle, not a marketing label. Cloudflare's Web Analytics does not track individual users. It uses no client-side state (cookies, localStorage) for analytics and no fingerprinting via IP address, User Agent, or any other technique.

The concept of the visit is central to this approach. Instead of counting unique IP addresses—which would require storing per-visitor state—Web Analytics counts page views from distinct referral or navigation events. This same concept extends to network and origin metrics, enabling deep debugging without collecting unneeded visitor data.

Additionally, you can choose to drop requests from European and UK visitors entirely, per these settings. The version of Web Analytics that will be enabled by default excludes EU visitors, though this can be changed in the dashboard if you prefer to include them.

Disabling Web Analytics

While the service is designed to be privacy-first, you may still want to opt out. The steps differ slightly depending on whether you use the dashboard or the API.

Dashboard method

For free domains where Web Analytics has been automatically enabled, you can opt out before October 15, 2025:

1. Open the zone in the Cloudflare dashboard and select Web Analytics from the left-hand menu.

2. Choose either Enable Globally or Exclude EU to activate the feature first.

3. After activation, go to Manage RUM Settings in the Web Analytics dashboard.

4. Select Disable to turn off Web Analytics for the zone. Alternatively, remove it entirely by selecting Advanced Options and then Delete.

Once you disable the product, it will not be re-enabled automatically. You can choose to turn it back on at any time.

API method

The API offers an equivalent path with the option to create a configuration that never starts collecting data.

1. Create a Web Analytics configuration using the API call below. Setting auto_install to false ensures no RUM data is collected for your zone.

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/rum/site_info \
    -H 'Content-Type: application/json' \
    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
    -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
    -d '{
          "auto_install": false,
          "host": "example.com",
          "zone_tag": "023e105f4ecef8ad9ca31a8372d0c353"
        }'

2. From the response, collect the site_tag and zone_tag fields. The site_tag corresponds to $SITE_ID in the subsequent calls.
3. Either disable the configuration:

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/rum/site_info/$SITE_ID \
    -X PUT \
    -H 'Content-Type: application/json' \
    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
    -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
    -d '{
          "auto_install": true,
          "enabled": false,
          "host": "example.com",
          "zone_tag": "023e105f4ecef8ad9ca31a8372d0c353"
        }'

Or delete the configuration entirely:

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/rum/site_info/$SITE_ID \
    -X DELETE \
    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
    -H "X-Auth-Key: $CLOUDFLARE_API_KEY"

On the Roadmap

Current Web Analytics focuses on how visitors experience your site in the browser. The next iteration widens that focus to the full request path—from the click, through Cloudflare's network, to your origin and back.

• Cross-layer correlation. RUM data from the client will be matched with network timing, edge processing, and origin response latency. This will let you determine whether a TTFB spike is caused by a slow script, a cache miss, or an origin bottleneck.
• Proactive alerting. Configurable alerts will notify you when performance degrades in specific geographies, when a data center underperforms, or when origin latency spikes.
• Granular insights. "Processing time" as a single number will be broken into its components: proxy routing, security checks, cache lookups, origin fetches, and more.
• Unified view. All of this will be accessible from a single place in the Cloudflare dashboard, alongside analytics, logs, firewall events, and configuration, so cause and effect are visible in one workflow.

These additions aim to deliver proactive alerts, cross-layer correlation, and insights not available elsewhere. Future installments of the RUM Diaries will cover these features as they take shape.