Cloudflare's BEACON Dataset: What 10,000 Sites of Field Data Reveal About Where Your LCP and INP Time Actually Goes

On September 28, 2026, Cloudflare published BEACON: billions of anonymized real-user measurements from the 10,000 largest sites on its network, free in Google BigQuery. And its sub-part tables say something uncomfortable for most performance audits: in the "Poor" band, downloading the resource averages 119ms — exactly the same as in the "Good" band — while render delay hits 2,002ms and the main thread eats 284ms of every failed interaction. Your compressed image was never the bottleneck.

We have started performance audits the same way for a decade: "compress the images." BEACON is probably the largest field dataset ever opened to the public, and the flattest row in its tables is the one we optimize the most.

What BEACON is (and why it isn't CrUX under a new name)

BEACON stands for Browser Experience Across Cloudflare's Observed Network. It is an anonymized dataset built from billions of real-world performance measurements across the 10,000 largest websites on Cloudflare's network, covers every major browser engine, updates daily in Google BigQuery, and follows the standard defined by the community-led RUM Archive, a public Real User Monitoring database that BEACON expands roughly 100-fold. The full announcement is in Cloudflare's September 28, 2026 blog post.

The practical difference from CrUX is not small:

One detail already changes meetings: BEACON publishes full histograms instead of the usual p75. Once you can look at p90 and p95, you find that several industries collapse in the long tail — especially visual stability (CLS) — and that information had been hiding behind a single number.

The LCP table that should reorder your audit

BEACON breaks LCP into four stages and buckets them into Google's three bands:

The row that should annoy any agency is the third: download time in the "Poor" band (119ms) is identical to the "Good" band (119ms) and lower than "Needs improvement" (199ms). The slowest pages on the web are not downloading slower — they download at the same speed. What separates them is 2,002ms to paint their main content and 1,485ms just to discover which element to paint.

Cloudflare states it plainly: downloading the resource itself — image, font, or video — typically contributes the least to perceived loading time. The bigger opportunities are discovering the LCP candidate and unblocking its render.

Our read is harsher: image compression is the performance task with the best effort-to-impression ratio and the worst effort-to-impact ratio that exists. It takes an afternoon, it demos beautifully in Lighthouse, and in the field it moves a row that was already green. The real work — preload, fetchpriority, removing render-blocking resources, cutting TTFB with edge cache — is less photogenic, and it is where the 2,002ms live.

INP: you are almost never waiting — you are processing and painting badly

The INP breakdown tells the same story from the other side:

Input delay — the main-thread queue — barely grows (18ms → 84ms). What explodes is processing the interaction (284ms) and painting the result (217ms). In the slowest interactions, JavaScript execution dominates, but Cloudflare highlights the jump in presentation delay, typically driven by complex CSS layout recalculations: deep DOM, expensive selectors, styles that change geometry at click time.

This is where our article on debugging INP with LoAF and scheduler.yield() becomes the natural diagnostic layer: BEACON tells you which stage fails at industry scale, LoAF tells you which script blocks it on your page.

The SPA tradeoff, finally with numbers

BEACON also supports Chrome's new Soft Navigations API, and the numbers in the SPA vs MPA debate are no longer opinions:

Soft navigations are two to three times faster at every percentile. Also true: the landing page that enables them costs 2,681ms at p75 — nearly five times the soft navigation that follows it. Cloudflare's conclusion matches what we argued in our analysis of Chrome's ICP and soft-navigation metrics: if users rarely move past the landing page, that heavier first load never pays for itself. The hybrid framework — the one behind this site and the projects we ship with Astro in production — keeps winning this argument because it gets both sides without forcing the debate.

What changed in our checklist (and the one we propose)

Eight months ago we published an analysis of the ad-load metrics Chrome added to CrUX and were already saying something similar: field data is being opened layer by layer. BEACON is the largest layer so far. Our audit order now looks like this:

Bytes still matter: on projects with heavy video and galleries we keep enforcing strict page-weight budgets. But leaving them in first place was a comfort decision, not a data decision. With BEACON, the client conversation shifts from "let's change the format of 40 images" to "your LCP candidate takes 1.4 seconds to be discovered because it depends on JavaScript."

Where BEACON will mislead you if you are not careful

Three limits we keep in mind before citing it in a meeting:

• It is not your site. These are the 10,000 largest on Cloudflare's network, running enterprise-grade infrastructure. Your SMB client is almost certainly not in the sample, and the aggregated bands do not distinguish CMS or technology.
• It is a benchmark, not your RUM. Use it to prioritize — if your field sub-parts look like the Poor band, you know where to attack — but the only answer to "do we pass Core Web Vitals?" still comes from your own users, measured with web-vitals or your RUM dashboard.
• There is vendor interest behind it. The announcement itself recommends Smart Hints for resource discovery and Zaraz for third-party JavaScript. The data is open and verifiable; the solutions it suggests are theirs. Read both at the same pace.

What to do this week with BEACON

Open the dataset in BigQuery (Cloudflare ships the queries from every table in this post as templates), run the LCP and INP sub-part tables, and compare them with your own field percentiles. If your page looks like BEACON's "Good" band, leave it alone and spend the time on what actually fails. If it looks like "Poor", you already have the attack order: discovery, render, main thread — and bytes, last.

The question is no longer whether your site is fast on your laptop. It is whether the open data from 10,000 sites says it is fast for everyone.