Cloudflare published BEACON on September 28: an anonymized dataset of real-user Core Web Vitals, updated daily in Google BigQuery from billions of page loads across the 10,000 largest sites on its network. It covers every major browser engine, including WebKit, which Cloudflare describes as currently the only browser engine on iOS.
What is Cloudflare’s BEACON dataset?
BEACON, short for Browser Experience Across Cloudflare’s Observed Network, is the public release of telemetry Cloudflare has collected for years on behalf of its customers. Updated daily in Google BigQuery, it draws on billions of real-world measurements from the 10,000 largest sites on Cloudflare’s network and reports Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) as full histograms, so anyone querying the tables can derive any percentile, not just the p75 most dashboards show. It follows the schema of the community-led RUM Archive project, whose footprint Cloudflare says this contribution expands 100-fold.
Anonymized down to a market benchmark
Publishing at that scale meant stripping identity from the records first, which Cloudflare frames as a privacy obligation. Cloudflare removes domain names and URL paths before publishing, aggregates what’s left by shared dimensions such as country, operating system, browser, and connection protocol, and discards any combination with fewer than five data points. Traffic volume is normalized to the level of the 10,000th-largest site so the biggest properties can’t skew the averages. Anyone with a Google Cloud account can query the tables on their own BigQuery billing; tables are partitioned by date, so filtering on a date range limits how much each query scans.
Where WebKit falls behind Blink
Cloudflare says WebKit performs best on these metrics overall, but that lead isn’t universal. In 46 countries where WebKit carries more than 10% of page-view traffic, its LCP, INP, or both run at least 10% worse than Blink-based browsers such as Chrome, Edge, and Opera. Cambodia is the extreme case: WebKit accounts for 17.5% of page views there, and its LCP runs 50% worse than Blink’s. PPC Land noted that Cloudflare’s post doesn’t say whether these comparisons control for device type; WebKit traffic skews heavily toward iPhone, while Blink spans Android phones and desktops, and that mix alone could explain part of it.
Cloudflare’s own post never compares BEACON to CrUX, and the two don’t measure the same population. Google’s CrUX methodology page limits collection to desktop Chrome and Android Chrome, excluding Chrome on iOS, Android WebView apps, and other Chromium browsers such as Edge, so WebKit traffic was never eligible for CrUX to begin with. We covered this Chrome-only boundary earlier, when Chrome added four experimental ad metrics to CrUX without exposing a JavaScript API that RUM tools could read them through. Cloudflare’s own claim is narrower: BEACON allows study at a scale and level of browser diversity that “has not previously been publicly available.” Safari, which CrUX never sees, is part of it.
Where the load time goes
BEACON extends the RUM Archive schema with LCP and INP sub-parts, breaking each metric into the stages behind the final number. For LCP, downloading the resource itself, an image, a font, or a video, typically contributes the least; for most page views that miss the ‘Good’ threshold, the bigger opportunities sit earlier, in discovering the LCP candidate and clearing whatever blocks its render. For the slowest INP interactions, JavaScript execution covers the longest stretch of the delay, though Cloudflare also flags a rising share of presentation time. The sub-parts are already in the BigQuery tables; Cloudflare says it will add them to its customer RUM dashboard in the coming weeks.
Another cut, built on Chrome’s Soft Navigations API and therefore limited to Blink, shows how much a route change inside a single-page app can save against loading a fresh page:
| Navigation type | P50 | P75 | P90 | P95 |
|---|---|---|---|---|
| Hard navigation | 791 ms | 1,421 ms | 2,636 ms | 4,122 ms |
| Soft navigation | 274 ms | 582 ms | 1,169 ms | 1,816 ms |
| Landing page | 1,370 ms | 2,681 ms | 5,397 ms | 8,940 ms |
Soft navigations render two to three times faster than hard navigations at every percentile in this Blink-only cut. Landing pages run slower still, at a p75 of 2,681 ms against 1,421 ms for hard navigations overall. Cloudflare’s read: if most visitors never get past the landing page, a heavier first load may never pay for itself.
A benchmark, not a lookup tool
None of this replaces a site’s own field data. Domain names and URL paths are stripped, and only Cloudflare’s 10,000 largest sites feed the dataset, so it can’t be searched for a specific origin. It’s a population benchmark, not a per-page audit of the kind Lighthouse runs, where even the recently added check, an agent discovery audit that doesn’t look for ard.json, inspects one URL at a time. BEACON can show how WebKit page loads in Cambodia perform across Cloudflare’s 10,000-site sample; it can’t show how WebKit performs on a team’s own checkout page. Field data on that page’s Safari visitors still has to come from the site’s own RUM collection.