Cloudflare’s BEACON Measures the iPhone Traffic That Google’s CrUX Leaves Out

On September 28, Cloudflare published BEACON (Browser Experience Across Cloudflare’s Observed Network), a public dataset of real-user performance measurements from 10,000 of the largest websites on its network, updated daily on Google BigQuery. It covers every major browser engine, including WebKit, the engine behind Safari and, in Cloudflare’s words, “currently the only browser engine on iOS.” Google’s Chrome User Experience Report (CrUX), the field data we used in August to compare hosting platforms, measures only Chrome on desktop and Android, so iPhone users are not in it.

BEACON also splits loading and responsiveness into the stages where time is lost. What it leaves out is the name of any site. It can describe the web by country, browser or industry, but it cannot rank hosts.

Key facts

• Size: about 4.5 billion page loads aggregated per day, with daily data available from September 20, 2026.
• Access: BigQuery project cf-open-web-performance, dataset rumarchive, under a CC BY-SA 4.0 license. Queries are billed by BigQuery, which has a free tier.
• New columns: browser engine, industry, HTML transfer size, interim response (Early Hints) timing, three LCP stages and three INP stages. Akamai’s mPulse data in the same archive has none of them.
• Removed: domain names and URL paths. Records with fewer than five data points are discarded, and the site column reads “(multiple).”

How BEACON Differs From Google’s CrUX

CrUX takes data only from Chrome users who “Enable usage statistic reporting” and “Sync their browser history.” Google’s methodology lists notable exceptions: “Chrome on iOS,” “Android apps using WebView” and “Other Chromium browsers (for example Microsoft Edge).” BEACON comes from a JavaScript snippet added to the site itself, so it is not tied to one browser. The main differences:

BEACON and CrUX compared. Sources: Cloudflare, RUM Archive, Google Chrome Developers.

The browser coverage produces the post’s first finding, and it cuts both ways. In Cloudflare’s comparison of Core Web Vitals at the 90th percentile on iOS and Android, WebKit “performs best on these metrics overall, but that advantage is not universal.” In 46 countries where WebKit carries more than 10 percent of traffic, its LCP, INP or both are at least 10 percent worse than in Blink-based browsers such as Chrome, Edge and Opera. In Cambodia, WebKit accounts for 17.5 percent of page views, and its LCP is 50 percent worse than Blink’s.

Where the Time Goes When a Page Loads Slowly

LCP, the time until the largest image, video or block of text on screen appears, breaks down into four stages: document time to first byte (TTFB), load delay before the browser discovers the LCP image, video or font, load duration while it downloads, and render delay before it shows. Cloudflare’s post groups page loads by their LCP rating and gives a figure for each stage in each group:

LCP stages by the page load’s LCP rating, in milliseconds. Source: Cloudflare.

Cloudflare says its full results challenge a common assumption, finding that “downloading the resource itself, such as an image, font, or video, typically contributes the least to perceived loading time.” For most page views that miss the good rating, the post places the larger opportunities in discovering the LCP element and unblocking its render. TTFB, the stage that covers the network and the server delivering the HTML document, grows as well. In page loads rated poor, it is about three times its value in good ones.

INP, which measures how quickly a page responds to input, gets the same treatment. In interactions rated poor, the post reports 84 milliseconds of input delay, 284 of processing and 217 of presentation. For the slowest interactions, it finds that JavaScript execution takes the longest, with a significant rise in presentation time, “typically dominated by complex CSS layout recalculations.”

Why BEACON Cannot Rank Hosts

Our August league table rested on the HTTP Archive’s breakdown of CrUX results by the platform behind each site. That is how we could report that on mobile, 80.1 percent of Wix customer sites passed all three Core Web Vitals, against 38.7 percent of HostGator’s. The breakdown needs each site’s origin, and BEACON removes it. Cloudflare strips “any potential customer website identifiers such as the domain name and URL paths,” the RUM Archive sets the site column to “(multiple),” and records with fewer than five data points are discarded “to further guarantee no individual or specific site can be identified.” A host cannot find its customers, its competitors or itself in the data.

What remains are dimensions such as country, device type, operating system, browser and engine, HTTP protocol, navigation type, landing page and industry. That supports benchmarking against the population rather than against named rivals. A host serving Southeast Asian markets, for example, can set the WebKit and Blink gap in those countries against its own real-user data.

The sample has its own limits. It covers large sites running Cloudflare’s RUM beacon, each capped at the traffic of the 10,000th-largest “so larger websites do not dominate the dataset sampling.” Smaller sites fall outside that top 10,000. On free plans, the beacon is on by default, a change Cloudflare set for October 15, 2025, and it excludes traffic through Cloudflare data centers in the EU, the rest of the EEA, Switzerland and the UK unless the owner changes the setting. On other plans, customers enable it as needed.

About the Data

This article draws on Cloudflare’s announcement and RUM documentation, the RUM Archive’s dataset, table, release-note and querying pages, and Google’s CrUX methodology, BigQuery and API documentation. We have not run queries against BEACON. Stage figures are reproduced as Cloudflare published them, and the post does not name the statistic behind them. The Wix and HostGator figures come from our August analysis of HTTP Archive data for June 2026, mobile, at origin level.