Cloudflare opens anonymized speed data from 10,000 top websites

Cloudflare on September 28, 2026 placed a public performance dataset in Google BigQuery, drawn from billions of real browser visits to the 10,000 largest websites on its network, and its first readings show landing pages, iPhone users in dozens of countries and several industries faring worse than headline averages suggest.

In Short

Cloudflare, a company that carries traffic for a large share of the web, has made public a big collection of measurements showing how quickly real pages load and react for real people. It matters to anyone who pays to send visitors to a website, because the data shows the first page of a visit is often the slowest, and that iPhone browsers in 46 countries fall behind Chrome-style browsers. You cannot look up any named website in it, but browsers, countries and industries can now be compared without relying on Google's Chrome figures alone.

What Cloudflare published

The dataset is called BEACON, short for Browser Experience Across Cloudflare's Observed Network. It was set out in a blog post published on September 28, 2026 by Ryan Townsend and Nic Jansma, carried under the company's Birthday Week banner. According to Cloudflare, BEACON is built from billions of real-world performance measurements across 10,000 of the largest websites on its network, covers every major browser engine and is refreshed daily in Google BigQuery. Its records follow standards defined by the RUM Archive, a community-led public database of field measurements, and Cloudflare says BEACON expands that project's footprint 100-fold. No absolute record count accompanies the claim; the post speaks only of billions.

The name borrows from the mechanics of real user monitoring, in which a script running in the visitor's browser collects timings and sends them home in a single request known as a beacon. Cloudflare has gathered this kind of telemetry for years on behalf of its customers, according to the post, giving each a detailed view of its own visitors. What changed on September 28 is that an aggregate of those views became available to anyone with access to BigQuery.

The authors framed the release around a perception gap. Software is typically built on powerful laptops, flagship phones and fast Wi-Fi, while the people using it may be nursing a four-year-old budget phone low on battery, or a data plan that throttles after 2 GB. Multiply that across billions of people, the post argues, and the distance between "works on my machine" and "works for everyone" widens, distorting decisions about technology choices and priorities.

Three metrics, full distributions

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 responsiveness. INP replaced First Input Delay as a Core Web Vital on March 12, 2024. Google's thresholds, applied at the 75th percentile of page views, classify LCP as good at 2.5 seconds or less and poor above 4 seconds, INP as good at 200 milliseconds or less and poor above 500, and CLS as good at 0.1 or less and poor above 0.25.

The distinguishing choice is format. Cloudflare publishes full histograms rather than single averages, so any percentile can be derived from the data. Most tooling stops at the 75th percentile, known as P75. The long tail beyond it, according to the post, shows "where the industry still struggles to deliver fast experiences for everyone."

The WebKit advantage has limits

WebKit, the engine behind Safari and, in Cloudflare's description, currently the only browser engine on iOS, performs best on these metrics overall. That lead is not universal. In 46 countries where WebKit accounts for more than 10% of traffic, its LCP, its INP or both are at least 10% worse than those of Blink-based browsers such as Chrome, Edge and Opera, according to Cloudflare. Cambodia is the example the authors chose: WebKit carries 17.5% of page views there, and its LCP is 50% worse than Blink's.

Several qualifications apply. The post does not list the 46 countries. Nor does it say whether the comparison controls for device type, which matters because WebKit traffic is overwhelmingly iPhone traffic while Blink spans Android handsets at every price point as well as desktop machines. The description of iOS also simplifies matters: Apple has permitted alternative browser engines in the European Union since iOS 17.4 in March 2024, a nuance the post does not address.

Comparisons of this kind are recent. Safari 26.2 added the interfaces for measuring LCP and INP in December 2025, alongside Firefox 146 and Chrome 143, closing a gap that had prevented like-for-like measurement across engines. Google's own public field dataset, the Chrome User Experience Report, is still collected from Chrome on desktop and Android and excludes iOS entirely. BEACON therefore covers a population that the dataset behind Google Search's page experience signals does not see at all.

Government sites fast, ad sites slow

BEACON tags domains with industry classifications from Cloudflare's Intel API. Government and Politics, Health and Safe for Kids stand out as high performers, according to the post, while Ads, Religion and Weather typically perform worst. The comparison is presented as a table of 90th percentile values split between iOS and Android, with the underlying query saved in BigQuery as "CWVs by Industry".

The extra percentiles earn their place here. In several industries, Cloudflare says, the slowest experiences fall away sharply in the long tail, most visibly for CLS. A single P75 figure would hide that.

What does the Ads label actually cover? The post does not say. It could denote the websites of advertising companies, domains that serve ads, or publishers classified by how they make money, and each reading leads somewhere different. Without a definition, the result supports no conclusion about ad-supported publishers as a group.

It lands at a sensitive moment all the same. On September 15, 2026, Chrome added four experimental advertising metrics to its public dataset - Ad Count, Ad Density, Ad Weight: CPU and Ad Weight: Network - reported at the 75th percentile for sites naming at least one authorized seller in ads.txt, with no thresholds attached and BigQuery support still pending. That release turned ad load into a public, browser-measured number for eligible sites. Layout shift is where advertising and page performance collide most directly: in Chrome's field data, shifts inside iframes count against the page that embeds them, so a badly behaved ad frame drags down the publisher's score.

The Health result echoes earlier work using a different method. A study of retail sites during the 2025 holiday season, built on PageSpeed Insights, found health and wellness retailers performing best overall, with a 55% pass rate on Core Web Vitals.

Where the milliseconds go

BEACON extends the RUM Archive format with sub-parts for LCP and INP that divide loading and interaction into stages. Cloudflare plans to add the same breakdown to its own RUM dashboard in the coming weeks, according to the post.

For loading, there are four stages. Time to first byte (TTFB) covers the wait for the HTML document, before which nothing can render. Load delay is the time before the browser discovers the LCP resource, often lengthened by dependence on JavaScript. Load duration is the download itself. Render delay is anything that blocks the element from painting once it has arrived. Cloudflare grouped page views into Google's three bands:

Source: Cloudflare BEACON, query stored as "Global LCP Sub-parts". The table does not state which statistic each cell represents.

Adding the four cells in each row, a rough exercise given the unlabeled statistic, gives about 950 milliseconds for good page views, 2,700 for those needing improvement and 5,497 for poor ones - totals that fall inside Google's respective LCP bands. In the poor row, render delay accounts for about 36% of that total, TTFB for 34% and load delay for 27%. The download itself accounts for about 2%. As published, the load duration for poor page views, 119 milliseconds, is identical to the figure for good ones.

That is the post's central finding on loading. In the authors' words, "downloading the resource itself, such as an image, font, or video, typically contributes the least to perceived loading time." For most page views outside the good band, the larger gains lie in discovering the LCP candidate sooner and unblocking its render, according to Cloudflare, which points its own customers to its Smart Hints product for some discovery delays.

Server response has not stopped mattering. Cloudflare's Observatory analysis of 9 billion events, released on September 26, 2025, found sites with a TTFB above 1,800 milliseconds were 70.1 percentage points less likely than the average site to achieve a good LCP; the company described its network at the time as handling traffic for more than 20% of the web. BEACON's poor row sits at 1,891 milliseconds of TTFB, just past the 1,800 millisecond boundary Google uses for a poor score on that metric.

Discovery failures also sit behind one well-documented setback. In a case shared on November 7, 2025, an agency applied lazy loading to a client's hero image, lifting a PageSpeed score from 65 to 92 while field LCP worsened from 1.8 to 4.2 seconds and traffic fell 20%, all figures reported by the agency. A lazily loaded hero image is a load delay problem in its purest form.

Interactions

The INP breakdown follows the same logic: input delay while an interaction waits for the main thread to become available, processing time for the event handlers themselves, and presentation delay before the next frame reaches the screen.

Source: Cloudflare BEACON, query stored as "Global INP Sub-parts".

Summed, the rows come to 129, 255 and 585 milliseconds, again consistent with Google's 200 and 500 millisecond boundaries. For the slowest interactions, JavaScript execution takes the largest share, about 49% of the poor-row total, but presentation delay also climbs sharply, to about 37%. Cloudflare attributes presentation time mainly to complex CSS layout recalculations, and mentions its Zaraz tool as a way for customers to reduce the cost of third-party JavaScript.

On publisher sites, third-party JavaScript very often means advertising code. Header bidding wrappers run inside the publisher's own page, and Chrome's new Ad Weight: CPU metric explicitly excludes ad scripts running in that main frame. BEACON, as described, carries no attribution of processing time to individual scripts either. Neither public dataset, in other words, isolates what main-page ad code costs in responsiveness.

Faster clicks, heavier first pages

Cloudflare recently added support for Chrome's Soft Navigations API, according to the post, which provides accurate LCP reporting for client-side navigations in single-page applications built with frameworks such as React, Vue, Angular and Svelte. In a soft navigation, the page swaps its content and URL without a full reload; a hard navigation fetches a new document from the server. The browser interface is Chrome's alone: soft-navigation performance entries shipped in Chrome 151, released on July 28, 2026, with no support in Firefox or Safari, according to the web-features explorer maintained by the W3C's WebDX community group. BEACON's comparison is accordingly Blink data.

Source: Cloudflare BEACON, queries stored as "Blink - Hard vs Soft Navigations" and "Blink - Landing Pages".

Soft navigations render two to three times faster than hard ones at every percentile, according to Cloudflare; the published figures give ratios of 2.9 at the median, 2.4 at P75 and about 2.3 at both P90 and P95. The gains stop at the front door. Landing pages, the first page of a visit, are considerably heavier. Their P75 LCP of 2,681 milliseconds sits above Google's 2.5 second threshold for a good score, and one landing page view in 20 takes longer than 8.9 seconds. At P75, a landing page takes 4.6 times as long as a soft navigation and 1.9 times as long as a hard one. The post does not specify whether the landing page figures are restricted to sites using client-side routing.

The authors spell out the trade-off for teams choosing this architecture: faster subsequent navigations have to offset a slower first experience. "If users rarely progress beyond the landing page, a heavier initial load may never pay for itself," they write.

For paid media, that first experience is precisely what is being bought, since a paid click by definition starts a visit on a landing page. Shopify's analysis of its merchant base, published on April 27, 2026, put conversion about 3.5% lower for every additional 100 milliseconds of load time, a figure Shopify derived from its own data. BEACON was not built to measure conversion, and combining the two sources would require assumptions about audience and device mix that neither supports.

Multi-page sites have other routes to quicker second pages. Cloudflare's Speed Brain, released on September 25, 2024, uses the Speculation Rules API to prefetch a visitor's likely next page, and the company reported a 45% LCP reduction at P75 for domains where it was enabled by default. Google has made a similar pitch to publishers: an AdSense email sent on March 24, 2026 promoted the back/forward cache and speculation rules, citing an 18% ad revenue gain and 27% more page views at German publisher Netzwelt, figures relayed by Google. Both techniques act mainly on the pages that come after the first.

Networks, income and lighter pages in Africa

Because BEACON is public, it can be joined with other data. The post offers one example, pairing it with the World Bank Group's measure of GDP per capita to show how economic conditions correlate with web performance by country; the query is stored as "Country-level Performance Aggregates". The accompanying charts carry no figures in the text of the post.

Cloudflare Radar, the public data platform that dates back to 2020, will take the approach further in a new Web Performance section. It will correlate BEACON with Radar's Internet Quality Index (IQI), an aggregation of the benchmarking data behind the company's bi-annual network performance updates. The pairing divides a visit into its two most influential components, according to Cloudflare: the performance of the website itself, and that of the "eyeball network", the access provider that carries the visitor to it.

Does a fast network hide a slow site? Early analysis suggests the two tend to move together, according to the post, with higher bandwidth coinciding with faster LCP. Its European example is harder to follow. The post states that bandwidth in Europe is higher relative to other continents, "while the LCP is higher overall with the lower end," a phrasing that reads against the general pattern described, since a higher LCP means slower loading. No figures are given to resolve it.

Transfer size produced what the authors called a surprise. They had expected it to be uniform across continents, since the content of sites is typically the same everywhere, yet Africa showed noticeably smaller transfers, suggesting less content was being downloaded. IQI data shows lower bandwidth on the continent. "Although we can't be sure of the cause," the authors write, the pattern suggests businesses there may be adapting their websites to network constraints. A second hypothesis runs the other way: high-quality networks may be more forgiving of poorly optimized sites, while slow ones exacerbate bottlenecks. Cloudflare presents both as directions for further analysis and says the Radar section will examine how often one half of the experience cancels out gains made by the other.

What was removed, and what that means

The method explains both the dataset's strengths and its limits. De-identification comes first. Cloudflare says its RUM product is already built with privacy in mind, and for BEACON it also strips potential customer identifiers, including domain names and URL paths.

Normalization posed the harder problem. Including every website would have let the largest sites dominate by traffic volume, skewing the results toward their architectures and visitor profiles; normalizing every site down to the traffic of the smallest would have shrunk the record count drastically. Cloudflare settled on the 10,000 largest websites on its network, normalized to the traffic level of the 10,000th, which it says still yields billions of daily records collectively.

Aggregation follows. Records are combined where they share dimensions such as country, operating system, browser and connection protocol, and any record with fewer than five data points is discarded, so that no individual or specific site can be identified, according to Cloudflare.

Each choice shapes what the numbers can say. Normalization gives each of the 10,000 sites roughly equal weight, so the figures describe the typical large site on Cloudflare's network rather than the typical page view on the web. The sample is confined to Cloudflare customers, and to the largest of them. With domains removed, industry is the finest commercial cut available, and no named competitor can be benchmarked. The findings in the post are also Cloudflare's own analysis, published alongside references to Smart Hints, Zaraz, the RUM dashboard and Radar, all of them Cloudflare products.

Access runs through BigQuery, with example queries for every table in the post and further documentation on the RUM Archive website. Cloudflare says it will add metrics and dimensions over time and invites requests through its community forum and Discord. The project grew out of Cloudflare's 1,111 intern project; the authors credit two summer interns, Chisara Duru and Tong Zhou, with taking it from initial idea to release.

Why this matters for the marketing community

Public field data on web performance has, until now, come mainly from Google, whose Chrome dataset reports over rolling 28-day windows and summarizes at P75. BEACON adds WebKit, daily updates and full distributions, drawn from a different population and weighted differently. The two will not agree, and that disagreement is itself information.

For media buyers, the country and engine splits bear directly on campaign traffic. In the 46 countries Cloudflare identified, audiences skewed toward iPhones may meet slower pages than Chrome-based benchmarks imply, although without the country list that exposure cannot be sized. The landing page figures matter more broadly: every paid visit begins on the kind of page BEACON places at the slow end of each distribution it publishes.

Publishers face a sharper question. Standards are hardening around them - Joost de Valk's website specification, published in May 2026, lists Core Web Vitals targets at the 75th percentile as required rather than recommended - and Google's publisher products now tie performance to revenue in their own communications. For publishers, the sub-part tables may prove more useful than any single headline finding, since they show where the time goes in each band, across browsers that Chrome's dataset does not cover.

Human visitors are also now the minority of requests. Cloudflare Radar data for the week ending June 5, 2026 put bots at 57.4% of HTML requests, against 42.6% for humans. BEACON, by Cloudflare's account, describes how real people experience the web - the audience advertisers are paying to reach.

Then there is the question of who does the measuring. Google runs the dominant browser and the largest ad server as well as the dataset that informs page experience in its search engine. Cloudflare sells the performance and third-party script products its post mentions. Neither is a neutral party. A second large public dataset, with its method published and its queries open to inspection, at least allows the claims of each to be tested against the other.

Timeline

• 2020 - Cloudflare Radar debuts as a public data platform
• March 12, 2024 - Interaction to Next Paint replaces First Input Delay as a Core Web Vital
• September 25, 2024 - Cloudflare releases Speed Brain, prefetching likely next pages through the Speculation Rules API
• September 26, 2025 - Cloudflare releases Observatory in open beta; analysis of 9 billion events ties TTFB above 1,800 milliseconds to worse LCP
• November 7, 2025 - Agency case links a lazily loaded hero image to LCP rising from 1.8 to 4.2 seconds and a 20% traffic fall
• December 2025 - Safari 26.2, Firefox 146 and Chrome 143 complete cross-browser LCP and INP measurement
• December 2025 - Holiday retail study finds health and wellness sites strongest overall, with a 55% Core Web Vitals pass rate
• March 24, 2026 - AdSense emails publishers about bfcache and speculation rules, citing Netzwelt's 18% ad revenue gain
• April 27, 2026 - Shopify ties each additional 100 milliseconds of load time to about 3.5% lower conversion
• May 2026 - Joost de Valk publishes a 128-rule website specification with Core Web Vitals targets listed as required
• Week ending June 5, 2026 - Cloudflare Radar data puts bots at 57.4% of HTML requests
• September 15, 2026 - Chrome adds four experimental ad metrics to the Chrome User Experience Report
• September 28, 2026 - Cloudflare publishes BEACON in Google BigQuery, covering the 10,000 largest websites on its network
• Coming weeks - LCP and INP sub-parts due in Cloudflare's RUM dashboard; Radar's Web Performance section to follow, undated

Related PPC Land coverage

• Cloudflare launches Observatory and Smart Shield for website performance - Cloudflare's RUM platform, its four-part LCP breakdown and the TTFB analysis across 9 billion events.
• Chrome puts publishers' ad loads on public record with 4 new metrics - The CrUX ad count, density and weight metrics, their ads.txt eligibility gate and the absence of thresholds.
• Major browsers achieve cross-platform parity on web performance metrics - How Safari 26.2 made LCP and INP measurable outside Chromium in December 2025.
• Shopify data shows 3.5% conversion drop per 100ms slower load time - Merchant-wide analysis linking storefront speed to purchase conversion.
• Google AdSense pushes bfcache, speculation rules, and AI debugging to publishers - Google's March 2026 performance guidance to publishers and the Netzwelt figures it cited.
• Lazy loading implementation causes 20% traffic drop despite PageSpeed gains - A case in which a lab score improved while field LCP deteriorated.
• Cloudflare's Speed Brain makes websites load faster - Cloudflare's prefetching feature and the P75 LCP reduction it reported.
• Two-thirds of retail sites fail mobile speed tests this holiday season - Sector-level Core Web Vitals pass rates from the 2025 holiday period.
• Bots now outnumber humans on the web - and most aren't here to search - Cloudflare Radar's June 2026 split between automated and human traffic.
• Interaction to Next Paint (INP) to replace First Input Delay (FID) on March 12, 2024 - The responsiveness metric change on which BEACON's INP data rests.
• Cloudflare launches comprehensive TLD tracking on Radar platform - Background on Radar's datasets and its 2020 origins.

Summary

Who: Cloudflare, through a post by Ryan Townsend and Nic Jansma, with summer interns Chisara Duru and Tong Zhou credited for the project. The data describes visits to the 10,000 largest websites on Cloudflare's network and is aimed at researchers, browser vendors, developers and standards groups, with implications for advertisers, media buyers and publishers.

What: BEACON, a public dataset of real-user performance measurements covering LCP, CLS and INP as full histograms, plus LCP and INP sub-parts, stripped of domain names and URL paths and following the RUM Archive format. Early findings include worse WebKit LCP or INP in 46 countries, strong Government, Health and Safe for Kids categories against weak Ads, Religion and Weather, soft navigations two to three times faster than hard ones, and a Blink landing page P75 LCP of 2,681 milliseconds.

When: Published on September 28, 2026 and refreshed daily. LCP and INP sub-parts are due in Cloudflare's RUM dashboard in the coming weeks, and a Radar Web Performance section is to follow without a date.

Where: Google BigQuery, with documentation on the RUM Archive website. The data spans countries worldwide, with Cambodia and Africa singled out in the post, and a Radar section will pair it with network quality data.

Why: Cloudflare says the gap between developers' hardware and users' real conditions distorts technology decisions. For the marketing community, it is the first large public field dataset beyond Chrome, arriving two weeks after Chrome began publishing ad-load metrics and as performance is increasingly tied to conversion and advertising revenue.