How fast is the web? Explore billions of real-user measurements with BEACON

Cloudflare has published BEACON — Browser Experience Across Cloudflare's Observed Network — an anonymized dataset drawn from billions of real-world performance measurements collected across 10,000 of the largest websites on its network. The telemetry behind it has been gathered for years on behalf of customers, giving each a private view of how real users experience their site; BEACON opens that view to everyone.

The dataset covers every major browser engine, is updated daily in Google BigQuery, and follows the standards of the community-led RUM Archive, a public Real User Monitoring database. BEACON expands that project's footprint 100-fold.

What the data measures

BEACON reports all three Core Web Vitals: Largest Contentful Paint (LCP) for load time, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for interaction responsiveness. They are published as full histograms rather than averages, so any percentile can be derived — not just P75. That makes the long tail visible, showing where the industry still fails to deliver fast experiences.

Browser engines and industries

WebKit, currently the only browser engine on iOS, performs best on these metrics overall, but the advantage is not universal. In 46 countries where WebKit holds more than 10% of traffic, its LCP, INP, or both are at least 10% worse than Blink-based browsers such as Chrome, Edge, and Opera. In Cambodia, WebKit accounts for 17.5% of page views and its LCP is 50% worse than Blink's.

Domain industry classifications from Cloudflare's Intel API are included as well. Government and Politics, Health, and Safe for Kids perform well; Ads, Religion, and Weather typically perform worst.

Additional percentiles expose differences a single P75 result hides. In several industries the slowest experiences fall sharply in the long tail, particularly for visual stability as measured by CLS.

Breaking down LCP and INP

BEACON extends the RUM Archive standard with LCP and INP sub-parts that separate the stages of loading and of responding to an interaction. These metrics will also arrive in Cloudflare's RUM dashboard in the coming weeks. Aggregating them into the suggested 'Good', 'Needs Improvement', and 'Poor' thresholds helps narrow down what needs optimizing:

The query for the table above and others for every data is stored in BigQuery alongside the dataset as 'Global LCP Sub-parts' so you can customize it as you see fit.

The results challenge a common assumption: downloading the resource itself — an image, font, or video — typically contributes the least to perceived loading time. For most page views that breach the 'Good' threshold, the bigger opportunities lie in discovering the LCP candidate and unblocking its render. Cloudflare customers can address some resource-discovery delays with Smart Hints.

The same workflow splits INP into input delay, processing time, and presentation delay:

Query for above table stored as 'Global INP Sub-parts' in BigQuery

For the slowest interactions, JavaScript execution covers the longest period, but presentation time also rises significantly, typically dominated by complex CSS layout recalculations. Cloudflare customers can use tools such as Zaraz to reduce the performance impact of third-party JavaScript.

Architecture: soft vs. hard navigations

Cloudflare recently added support for Google Chrome's new Soft Navigations API, which provides accurate LCP reporting for the client-side navigations common in single-page applications built with frameworks such as React, Vue, Angular, and Svelte.

Query for above table stored as 'Blink - Hard vs Soft Navigations' in BigQuery

Soft navigations render two to three times faster than hard navigations at every percentile, but they do not remove the cost of the initial landing page, which is often considerably heavier:

Query for above table stored as 'Blink - Landing Pages' in BigQuery

Teams choosing this architecture must weigh the tradeoff: faster subsequent navigations have to offset a slower first experience. If users rarely go past the landing page, a heavier initial load may never pay for itself.

Combining BEACON with other data

Because BEACON is open, its value is not limited to its own fields; researchers can join it with other sources. Combining it with the World Bank Group's measure of GDP per capita, for instance, shows how economic conditions correlate with web performance by country:

Cloudflare Radar, the company's public data insights platform, will adopt this approach in a new Web Performance section, correlating its Internet Quality Index (IQI) data with BEACON. IQI aggregates the performance benchmarking data behind Cloudflare's bi-annual network performance updates.

The pairing is useful because it splits user experience into its two most influential components: the performance of the website being visited and the performance of the eyeball network delivering it. Both affect load speed, and together they determine whether a visit feels painful or seamless.

Early analysis shows the two tend to move together: good web performance usually coincides with good network quality, and vice versa. The graphs show that the higher the bandwidth, the faster the perceived load time (LCP). In Europe, bandwidth is higher relative to other continents, while LCP is higher overall at the lower end.

The bandwidth–LCP relationship was expected, but comparing IQI to transfer size produced a surprise. Transfer size would be expected to be uniform across continents, since site content is typically the same. Yet Africa shows a noticeably smaller transfer size, suggesting less content is downloaded by these users. The cause is uncertain, but IQI data shows lower bandwidth in Africa, suggesting businesses there are adapting their websites to network constraints. High-quality eyeball networks may also be more forgiving of poorly optimized sites, while a slow one exacerbates bottlenecks. Each hypothesis is a direction for future analysis.

The new Web Performance section will explore how common these patterns are, and in particular how often one half of the experience cancels out gains made by the other.

Privacy, normalization, and aggregation

Publishing real-world data at this scale carries a privacy responsibility. Cloudflare's RUM product is already privacy-first, and for BEACON any potential customer website identifiers — domain name and URL paths — are stripped out, so the community gains insight without compromising the trust of the people and businesses behind the data.

Normalization presented a choice. Including every website would mean either that the largest sites dominate by traffic volume, skewing metrics toward their architecture and visitor profiles, or that reducing every site to the traffic volume of the smallest would drastically shrink the record count. Cloudflare scoped the dataset to as many of the largest sites on its network as possible for maximum diversity across architectures, technologies, and geographies, while retaining the total beacon count after normalizing; 10,000 sites proved a good balance, leaving enough volume in the 10,000th that normalizing to its level still represents billions of daily records collectively.

Records sharing dimensions such as country, operating system, browser, and connection protocol are then aggregated, and any record with fewer than five data points is discarded so no individual or specific site can be identified.

Access and contribution

BEACON is publicly available on Google BigQuery. Queries for all the data in the announcement are included as examples to adapt, and the RUM Archive website carries further documentation. Findings can be shared in Cloudflare's community forum or on Discord. The company says it will continue adding metrics and dimensions over time and welcomes requests for data to include next.

A special shout out to Cloudflare's 1,111 intern project: two summer interns, Chisara Duru and Tong Zhou, took the initial idea through to launch.