Cloudflare Releases BEACON to Open Up Billions of Real-User Web Performance Measurements

Cloudflare Releases BEACON to Open Up Billions of Real-User Web Performance Measurements Cloudflare has made its BEACON (Browser Experience Across Cloudflare's Observed Network) dataset publicly accessible on Google BigQuery. Derived from billions of real-world measurements across 10,000 top sites and adopting RUM Archive standards, the dataset exposes granular web performance distributions across browsers, device types, and geographies. BEACON publishes full histograms of Core Web Vitals across 10,000 of Cloudflare's largest sites, expanding the RUM Archive footprint 100-fold. Resource download time contributes least to poor LCP, while resource discovery and render blocking are the primary bottlenecks. Soft navigations in single-page applications run two to three times faster than hard navigations, but initial landing page loads carry steep performance costs. Correlating BEACON with network and economic metrics reveals geographic variances, such as significantly smaller transfer sizes in Africa. Cloudflare enforces privacy by removing domain names and URLs, normalizing across top domains, and discarding aggregates with fewer than five data points. Dataset Scope and Engine Variations BEACON aggregates daily telemetry across major browser engines using RUM Archive standards to represent real-world user conditions beyond privileged developer environments. Rather than relying solely on the 75th percentile, the release publishes full histograms. Although WebKit generally outperforms other engines, this trend reverses in 46 countries where its traffic exceeds 10%; in Cambodia, for instance, WebKit's LCP is 50% slower than Blink's. Granular Breakdown of Core Web Vitals By dissecting LCP and INP into constituent sub-parts, the dataset overturns standard assumptions about load bottlenecks. The actual download duration of assets like images or fonts accounts for the smallest delay in slow loads; unblocking render delays and resource discovery lag pose the largest hurdles. For interaction responsiveness, slower experiences stem heavily from main-thread JavaScript execution alongside CSS layout recalculations driving presentation delays. Trade-offs in Single-Page Application Navigations Integrating Chrome's Soft Navigations API enabled comparisons between traditional hard page loads and client-side transitions in SPAs. Soft navigations render two to three times faster across every percentile. However, initial landing pages for these applications remain substantially heavier, meaning slower initial experiences only yield net benefits if users traverse multiple subsequent pages. Macro Trends and Privacy Controls When paired with external sources like Cloudflare Radar's Internet Quality Index or World Bank GDP metrics, BEACON links bandwidth quality to user experience while uncovering regional optimizations, such as smaller transfer sizes across Africa. To protect individual and website privacy, Cloudflare strips domains and URLs, limits inclusion to the top 10,000 sites, normalizes records, and prunes any aggregated bucket containing fewer than five data points.

Cloudflare 发布真实用户网络性能开源数据集 BEACON Cloudflare 正式发布开源数据集 BEACON，基于其网络中前 10,000 个大型网站的数十亿条真实用户监测数据，旨在揭示全球真实设备与网络环境下的 Web 性能差异并推动性能优化。 BEACON 数据集涵盖主流浏览器引擎，每日更新至 Google BigQuery，将 RUM Archive 规模扩大了 100 倍。 指标细分发现，资源下载时间并非 LCP 的最大瓶颈，发现资源与消除渲染阻塞才是主要耗时来源。 单页应用软导航渲染速度比硬导航快 2 至 3 倍，但若用户未深入访问，可能无法抵消初始落地页更慢的加载成本。 结合 IQI 与经济数据发现，网络质量与网站性能高度协同，且非洲等低带宽区域展现出更小的数据传输量。 数据集通过去除域名、规范化至前 10,000 站点、聚合多维度并剔除少于 5 个数据点的记录以严格保护隐私。 BEACON 数据集与 Core Web Vitals 直方图 针对开发者设备与数十亿真实终端之间的认知偏差，Cloudflare 基于旗下网络前 10,000 个最大站点推出了 BEACON 匿名数据集。该数据集通过完整直方图呈现 Core Web Vitals 指标，允许研究者查看长尾百分位。数据同时表明 WebKit 优势并非绝对，在 46 个占比超 10% 的国家中其表现差于 Blink 核心；行业分类中，政务、健康与儿童分类性能领先，广告、宗教与天气网站表现较差。 加载与交互细分阶段打破传统认知 BEACON 将 LCP 与 INP 指标解构为具体子阶段。LCP 分析表明，纯图片或字体的下载耗时（Load Duration）通常占比最小，发现候选资源（Load Delay）与消除渲染阻塞（Render Delay）是更关键的优化空间。在 INP 方面，对于最慢的交互，除 JavaScript 执行时间外，复杂的 CSS 布局重新计算所引起的呈现延迟（Presentation Delay）也显著增加。 单页应用软导航与落地页开销权衡 结合 Chrome 的 Soft Navigations API，BEACON 分析了单页应用的客户端导航表现。在各个百分位上，软导航的 LCP 均比硬导航快 2 至 3 倍（例如 P50 软导航为 274ms，硬导航为 791ms）。然而初始落地页负担更重，P50 和 P75 分别达 1,370ms 与 2,681ms，架构设计需权衡后续加速是否足以抵消落地页损耗。 宏观经济、网络质量与区域特征关联 将 BEACON 与世行人均 GDP 以及 Cloudflare 互联网质量指数（IQI）联动，展现了网络基础设施与网站性能的关联。欧洲等地的高带宽伴随更快的 LCP；而低带宽的非洲地区数据传输体量明显较小，表明当地企业针对受限的网络条件做出了特定优化。 数据隐私保护与聚合发布方式 为保护客户隐私，BEACON 剥离了域名及 URL 路径，将样本限定在 10,000 个最大网站以兼顾代表性与数据量，并按国家、操作系统、浏览器与网络协议聚合。所有样本数低于 5 条的数据点均被剔除。目前该数据集及查询示例已向公众开放于 Google BigQuery。

If you work in technology, you’re probably reading this on a powerful laptop or flagship mobile on robust, lightning-fast Wi-Fi. This is fantastic for building software, but often is far removed from the reality facing many who are using that software. End users might be nursing a four-year-old budget phone, running low on battery, on a data plan that throttles after 2 GB, living with under-invested public infrastructure, or even just walking into that corner of the gym where the Wi-Fi never seems to work. Multiply this by billions of people around the world and the gap between “works on my machine” and “works for everyone” starts to widen, distorting critical decisions regarding our technology choices and priorities. Closing the perception gap with objective data is central to our mission of helping build a better Internet, one that's fast and accessible to everyone, not just those of us using the best hardware. That’s why today, we’re sharing a view that offers insight on how real people experience the web, by publishing the Cloudflare BEACON dataset — **B**rowser **E**xperience **A**cross **C**loudflare's **O**bserved **N**etwork. Cloudflare has collected this kind of telemetry for years on behalf of our customers, giving them a customer-specific, detailed understanding of how real users experience their sites. Today, we're opening that view up to everyone. BEACON is an anonymized dataset built from billions of real-world performance measurements across 10,000 of the largest websites on our network. It covers every major browser engine, is updated daily in Google BigQuery, and uses standards defined by the community-led [RUM Archive](https://rumarchive.com/)[,](https://rumarchive.com/) a publicly available Real User Monitoring (RUM) database. By expanding the footprint of that project 100-fold, BEACON gives researchers an unprecedented view of how the web performs across browsers, devices, and countries. The Core Web Vitals have long been the de facto standard for measuring perceived performance on the web, and BEACON reports all three: Because we’re publishing these as full histograms rather than single averages, you can derive any percentile you like. Instead of stopping at P75 (the 75th percentile), you can examine the long tail and see where the industry still struggles to deliver fast experiences for everyone. WebKit, currently the only browser engine on iOS, performs best on these metrics overall, but that advantage is not universal. In 46 countries where WebKit represents more than 10% of traffic, its LCP, INP, or both are at least 10% worse than those of Blink-based browsers such as Chrome, Edge, and Opera. In Cambodia, for example, WebKit accounts for 17.5% of page views, but its LCP is 50% worse than Blink’s. BEACON also includes domain industry classifications from [our Intel API](https://developers.cloudflare.com/api/resources/intel/subresources/domains/subresources/bulks/methods/get/). Government and Politics, Health, and Safe for Kids stand out as high-performing categories, while Ads, Religion, and Weather typically perform worst: The additional percentiles expose differences hidden by a single P75 result. In several industries, the slowest experiences fall sharply in the long tail, particularly for visual stability as measured by Cumulative Layout Shift. BEACON extends the RUM Archive standard with LCP and INP sub-parts that separate the stages of loading and responding to an interaction. We’ll also add these metrics to our Real User Monitoring (RUM) dashboard in the coming weeks. Aggregating them into the suggested ‘Good’, ‘Needs Improvement’, and ‘Poor’ thresholds helps narrow down what needs to be optimized: | **LCP Sub-part** | **Document TTFB** **(Time to First Byte)** Nothing can be rendered until we have our HTML document. | **Load Delay** Is JavaScript dependence slowing discovery of our LCP candidates? | **Load Duration** Is bandwidth an issue, with the LCP image/video/webfont taking a long time to download? | **Render Delay** When all is ready, is there something blocking the LCP from rendering? | | *Good* | `598ms` | `76ms` | `119ms` | `157ms` | | *Needs Improvement* | `1015ms` | `1049ms` | `199ms` | `437ms` | | *Poor* | `1891ms` | `1485ms` | `119ms` | `2002ms` | *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, such as an image, font, or video, typically contributes the least to perceived loading time. For most page views that breach the ‘Good’ threshold, the larger opportunities are discovering the LCP (load time) candidate and unblocking its render. Cloudflare customers can address some resource-discovery delays with [Smart Hints](https://blog.cloudflare.com/smart-hints/). The same workflow breaks down Interaction to Next Paint (INP), our measure of responsiveness, into input delay, processing time, and presentation delay: | **INP Sub-part** | **Input Delay** Are our interactions waiting on the main thread becoming available? | **Processing Time** Does processing the interactions themselves block the main thread? | **Presentation Delay** How long does it take to paint any update to the screen? | | *Good* | `18ms` | `55ms` | `56ms` | | *Needs Improvement* | `32ms` | `112ms` | `111ms` | | *Poor* | `84ms` | `284ms` | `217ms` | *Query for above table stored as ‘Global INP Sub-parts’ in BigQuery* For the slowest interactions, JavaScript execution time covers the longest period but we also see a significant rise in presentation time, which is typically dominated by complex CSS layout recalculations. Cloudflare customers can use tools such as [Zaraz](https://www.cloudflare.com/en-in/application-services/products/zaraz/) to reduce the performance impact of third-party JavaScript. Speaking of JavaScript, we recently [added support for Google Chrome’s new Soft Navigations API](https://developers.cloudflare.com/changelog/post/2026-08-21-improved-soft-navigation-measurement-for-single-page-applications/), which provides accurate LCP reporting for client-side navigations commonly used in single-page applications built with frameworks such as React, Vue, Angular, and Svelte. | **LCP Percentile** | **P50** | **P75** | **P90** | **P95** | | *Hard Navigations* | `791ms` | `1,421ms` | `2,636ms` | `4,122ms` | | *Soft Navigations* | `274ms` | `582ms` | `1,169ms` | `1,816ms` | *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 eliminate the cost of the initial landing page, which is often considerably heavier: | **LCP Percentile** | **P50** | **P75** | **P90** | **P95** | | *Landing Page* | `1,370ms` | `2,681ms` | `5,397ms` | `8,940ms` | *Query for above table stored as ‘Blink - Landing Pages’ in BigQuery* For teams choosing this architecture, it’s important to be mindful of tradeoffs: faster subsequent navigations must offset a slower first experience. If users rarely progress beyond the landing page, a heavier initial load may never pay for itself. Because BEACON is an open dataset, its value is not limited to the fields it contains. Researchers can join it with other sources to explore new questions. For example, combining BEACON with the [World Bank Group’s measure of GDP per capita](https://data.worldbank.org/indicator/NY.GDP.PCAP.KN) reveals how economic conditions correlate with web performance by country: [Cloudflare Radar](https://radar.cloudflare.com/), our public data insights and visualizations platform, will start using this approach in a new Web Performance section on Radar, featuring correlations of their Internet Quality Index (IQI) data with BEACON data. IQI is an aggregation of the performance benchmarking data that powers our bi-annual network performance updates. Pairing BEACON and IQI is particularly compelling because it splits the user experience into its two most influential components: the performance of the website a user is visiting, and the performance of the eyeball network getting them there. Both affect how quickly the page will load, and together they determine whether a visit to a website 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. In the above graphs we see that the higher the bandwidth, the faster the perceived load time (LCP). For example in Europe, the bandwidth is higher relative to other continents, while the LCP is higher overall with the lower end. The relationship between bandwidth and LCP was expected, but when comparing IQI to Transfer Size we saw something surprising. We would expect that transfer size would be uniform across continents — after all, the content of the sites are typically the same. However, see that Africa has a noticeably smaller transfer size, suggesting less content being downloaded by these users. Although we can’t be sure of the cause, we can observe that in the IQI data Africa has lower bandwidth, which suggests that businesses on the continent are adapting their websites to optimize towards the constraints of network conditions. High-quality eyeball networks are also potentially more forgiving to poorly-optimized websites, while a slow one exacerbates bottlenecks. Each of these hypotheses are potential directions 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 the gains made by the other. Follow our progress on [Radar](https://radar.cloudflare.com/). We’ll continue to introduce more metrics and more dimensions over time, and **we welcome requests for data you’d like to see next**. Publicizing a real-world dataset at this scale brings with it responsibility for privacy. Our Real User Monitoring (RUM) product is already built to be privacy-first, and for BEACON, we also strip out any potential customer website identifiers such as the domain name and URL paths. Ultimately, the community gains valuable insight without compromising the trust of the people and businesses behind it. For the primary table, including *all* websites from our data would lead to one of two problems: These two extremes made it necessary to scope the dataset to the greatest number of the largest websites on our network to provide maximum diversity across architectures, technologies, geography, and more, all while retaining the total beacon count after normalizing. We found 10,000 to be a good balance: a globally representative sample with enough volume in the 10,000th that when we normalize the data down to their level, the overall dataset still represents billions of daily records collectively. Finally, we aggregate records together where they share dimensions such as country, operating system, browser, and connection protocol, and discard any records with fewer than five data points to further guarantee no individual or specific site can be identified. BEACON is publicly available [on Google BigQuery](https://console.cloud.google.com/bigquery?ws=!1m4!1m3!3m2!1scf-open-web-performance!2srumarchive). We’ve included queries for all the data included in this post as examples you can adapt for your own analysis, and the [RUM Archive](https://rumarchive.com/docs/querying/) website includes further documentation too. We’d love to hear what you discover. Share your findings in [our community forum](https://community.cloudflare.com) or on [Discord](https://discord.cloudflare.com/). BEACON makes it possible to study web performance at a scale and level of geographic and browser diversity that has not previously been publicly available. We hope researchers, browser vendors, developers, and standards groups use it to identify where the web falls short and help make fast experiences available to everyone. A special shout out to [Cloudflare’s 1,111 intern project](https://blog.cloudflare.com/cloudflare-1111-intern-program/). This couldn’t have happened without the hard work of two of our wonderful summer interns, taking the initial idea through to what you see today. Their contributions were instrumental in launching this project. Thanks Chisara Duru and Tong Zhou!