Sites in the BEACON dataset: 10,000 (Source: Cloudflare, How fast is the web? (September 28, 2026))
Cloudflare observes that people who work in technology are probably reading on a powerful laptop or flagship phone over fast Wi-Fi, which is often "far removed from the reality" of many users. Some of those users hold an older budget phone or a throttled data plan. It is reasonable to infer that performance reviews held in a meeting room inherit the same blind spot. On September 28, 2026 Cloudflare published a dataset meant to replace assumption with measurement. For a budget-holder, its most useful finding concerns Largest Contentful Paint (LCP), the time until the main content element appears. For most page views that miss the 'Good' LCP threshold, more time is lost discovering that element and waiting for it to render than downloading it.
What Cloudflare published
The dataset is called BEACON, for Browser Experience Across Cloudflare's Observed Network. It draws on billions of anonymized real-user measurements from 10,000 of the largest sites on Cloudflare's network and is refreshed daily in Google BigQuery. It follows the community RUM Archive standard, whose footprint Cloudflare says it expands 100-fold. It covers all three Core Web Vitals: LCP for loading, Cumulative Layout Shift for visual stability and Interaction to Next Paint (INP) for responsiveness. Results are released as full histograms, so readers can look well past the 75th percentile at the slowest visits.
Download is the smaller part of slow loads
Cloudflare divides LCP into four stages: document response, load delay, load duration and render delay. Load delay is framed around whether dependence on JavaScript slows the browser in finding the main element. Load duration is the actual download of the image, video or font. Cloudflare says the results challenge a common assumption: that download stage typically adds the least to perceived load time. For most page views that miss 'Good', it names two larger opportunities: discovering the LCP candidate sooner and removing whatever blocks it from rendering.
The source does not say what teams are currently tuning, so what follows is our interpretation. A team told to shrink images may be working on the smaller stage of a slow load. Whether that describes your team is a question your own measurements can answer.
Responsiveness is a separate measurement and should not be blended with the above. For the slowest interactions, Cloudflare reports that JavaScript execution takes the longest share. Presentation time also rises meaningfully, typically because of complex CSS layout recalculation.
Single-page architecture is a trade
Cloudflare now supports Chrome's Soft Navigations API, which lets it measure page changes that happen inside a single-page application. On that basis, such in-app navigations finish rendering two to three times faster than full page loads at every percentile. The landing page, however, is often considerably heavier. Cloudflare's point is that quicker follow-on pages must make up for a slower first one, and a visitor who leaves after the landing page never collects that benefit.
That is a design decision with a business input: how many pages does a typical visit include? A team that cannot say has little basis for weighing the trade.
Browser and country change the result
WebKit is currently the only engine on iOS, and Cloudflare finds it performs best overall. The advantage is not universal. Across 46 countries where WebKit handles more than 10% of traffic, it is at least 10% worse than Blink-based browsers such as Chrome, Edge and Opera on LCP, INP or both. Cloudflare's example is Cambodia, with WebKit at 17.5% of page views and a 50% LCP gap against Blink.
Industry classifications add another cut. Cloudflare places Government and Politics, Health, and Safe for Kids among the stronger performers, and Ads, Religion and Weather at the weaker end. Beyond the 75th percentile, several industries show far worse experiences for their poorest visits than the headline number implies, with layout stability the clearest case.
One observation carries a caveat Cloudflare states itself. Africa shows a noticeably smaller transfer size, and Cloudflare's network-quality data shows lower bandwidth there. The company suggests businesses may be adapting sites to network limits but says it cannot be sure of the cause.
What this data does not say
BEACON covers 10,000 of the largest sites on one network. It is a broad sample, not a census, and Cloudflare removes domain names and URL paths, so you cannot look up a competitor. Treat it as a benchmark for the sites it covers and as a method for questioning your own telemetry.
Questions to put to your team
First, ask for your own LCP split into its four stages. Without it, the team may lack evidence of which stage dominates on your slow page views. Second, ask which third-party scripts run on your key pages and who decides whether they stay. The source does not link them to LCP delays, so treat this as a question, not a finding. Third, ask for results by browser engine and by country, including the slow tail rather than only the 75th percentile. Fourth, if you run or plan a single-page application, ask how many pages a typical visit includes.
A fast site is judged on the phone your slowest customer holds, not the laptop in the meeting room.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
