Chrome's ad weight tracks demand. Ad density tracks clutter.

Background: Chrome added ad metrics to CrUX on 15 September 2026

Chrome now publishes four experimental ad metrics in the Chrome UX Report (CrUX), pulled from real Chrome users rather than a lab test. Two describe how much of a page an ad occupies; two describe what it costs the browser to run. We joined all four to Sincera's crawl data on ad stacks, ad layout and supply chains. The question we wanted answered: when buyers and publishers finally get a public number for "how heavy is this page's advertising," what is that number actually measuring?

What Chrome measures

Chrome identifies ad frames with its own ad-detection logic, then records four values for every page view. CrUX publishes the 75th percentile (p75) of each value per origin, over a rolling 28-day period.

Four conditions control which origins have data:

• CrUX uses only pages that contain ads.
• The origin must have an ads.txt file with at least one authorized seller.
• The origin must have sufficient eligible Chrome traffic.
• Chrome on iOS and Android WebView do not contribute data.

The metrics carry no "good" or "poor" threshold. Chrome publishes values, not grades. Where this report says "high" or "low," it means a position in our sample, not a judgment Chrome itself makes.

Sources: CrUX ad metrics overview, Ad Density, Ad Weight: CPU, tooling guide.

How we measured

Population

We queried the CrUX API for 19,765 publisher origins in the MediaContext rank-based scope. Of these, 12,154 (61.5%) have ad metrics. Of those 12,154, 4,261 also carry a Sincera profile with ad-stack and supply-chain data — the subset where we can ask not just what Chrome measured, but why.

The CrUX collection period ends on 27 September 2026 for 9,080 origins and on 20 September 2026 for 3,071 origins. Three origins have other end dates. All analyses use origin-level data for all device types.

Sincera signals

Sincera crawls publisher pages and records their ad stacks, ad layout and supply paths, independently of Chrome. We use these fields:

One gap worth stating plainly: we have no CPM, revenue or bid-price data. Demand-stack signals show how much demand a site connects to. They don't show what that demand pays.

Statistics

• We use Spearman rank correlation (ρ), because all metrics have skewed distributions.
• Each 95% confidence interval comes from 1,000 bootstrap samples with a fixed seed.
• We correct p-values for 44 tests with the Benjamini-Hochberg method. All correlations the text cites have q < 0.05. The correlation chart marks the values with q of 0.05 or more.
• Controlled estimates are standardized regression coefficients (β) on ranks. The controls are traffic rank and publisher type. Standard errors are heteroskedasticity-robust (HC3).
• Quartiles and deciles divide the sample into equal-size groups.

The median origin shows one ad on 14% of the screen

The median origin in the sample carries one ad frame in view, ads on 14% of the viewport, 2.5 seconds of ad CPU time and 1.7 MB of ad data. The CPU and network distributions both have long right tails — most sites cluster low, a minority drag the average up hard.

Each value is a distribution across origins of each origin's p75. Of 11,860 origins with Ad Density, 1,105 (9.1%) run a p75 of 30% or more.

Weight and density measure different properties

Ad Weight and Ad Density sound like two measurements of the same problem — too many ads. They are not. Picture a food truck idling in a single parking spot all day: tiny footprint, engine running nonstop. Now picture a billboard that owns half the block and draws no power at all. One is heavy. One is dense. CrUX measures both, separately, and in this sample they barely agree: Ad Weight: CPU and Ad Weight: Network move almost in lockstep (ρ = 0.82), while Ad Density sits at a weak 0.19 against CPU and 0.27 against network. Ad Count splits the difference — it tracks weight at 0.57 and density at 0.43.

Weight is the code and data an ad brings to the page. Density is the space it takes on the screen. So which one should a buyer actually watch — and which one is Chrome's new metric really describing? That's the rest of this report.

Ad weight rises with wrappers, identity providers and refresh

Ad Weight: CPU climbs with every demand-stack signal we have. The strongest relations are wrapper count (ρ = 0.59), identity providers (0.56), desktop slot refresh (0.55) and ad units (0.52). Controlling for traffic rank and publisher type barely moves these (β = 0.49 to 0.56) — this isn't a side effect of big sites having big stacks, it's the stacks themselves.

The median Ad CPU of sites with no detected wrapper is 1,362 ms. With three or more wrappers, it's 4,984 ms — more than triple. Ad Density doesn't follow the same line upward. It goes the other way, from a median of 18% down to 14%.

The quartiles of Ad CPU tell the same story from a different angle:

A multivariable model isolates each signal's own contribution to Ad CPU (n = 3,847, R² = 0.47). Slot refresh carries the largest coefficient by a clear margin:

High ad weight, then, is a demand-side signal and not a space signal. It flags sites running more auctions, more identity calls, more refreshes — not sites with more ad space on the page. One caveat worth keeping in view: Chrome's documentation never says whether header-bidding code sitting in the main page frame counts toward ad CPU. If it does, some share of this relationship is baked into the metric's definition rather than the site's behavior.

Ad density rises with the ads-to-content ratio, not the stack

If ad weight is the demand stack, what moves Ad Density? Of everything we measured, only one Sincera signal tracks it with any strength: the ads-to-content ratio. The two values come from entirely different sources and methods — Chrome watching real sessions, Sincera crawling pages — and they still agree (ρ = 0.36, n = 3,793), more so on mobile (0.41) than desktop (0.28).

Everywhere else, Ad Density runs flat or slightly backwards against the demand stack: wrappers (ρ = −0.14), desktop slot refresh (−0.16). It leans positive on resellers (0.14) and on phone traffic share (0.30). Denser sites also pull less overall traffic (ρ = 0.18 with rank number) — density, in this sample, is a smaller-site signature.

The densest sites in the sample are smaller, lean more on phone traffic, and connect to less header-bidding demand — but sell through more resellers. Of every metric Chrome now publishes, Ad Density is the one that lines up with how buyers already define inventory quality.

Sites with heavy ads have slower interaction, not slower loading

We compared each origin's Ad CPU against its own Core Web Vitals in the same CrUX record. Interaction to Next Paint (INP) rises with Ad CPU. LCP, oddly, does not.

Across the ten deciles of Ad CPU, median INP climbs from 119 ms to 166 ms. The rank correlation over all 12,126 origins with INP is 0.21 (95% CI 0.20 to 0.23); controlled for traffic rank and publisher type, it holds at 0.23 (n = 4,236).

Device mix is the obvious confound — phones are slower than desktops, and CrUX reports device mix for 3,061 of the origins. In that subset the coefficient is 0.11 with or without a phone-share control. Device mix doesn't explain the relationship away. It does weaken it relative to the full sample, and we don't yet know why.

Ad code competing with the page for the main thread is the mechanism that fits — ad scripts running in the page itself would do exactly this. The data is consistent with that story; it doesn't prove it. The lower LCP failure rate in the heaviest quartile probably says less about ads and more about publishers: sites that can afford a large, well-managed ad stack tend to also be better-engineered sites. CLS shows no consistent direction at all.

Dense sites with heavy ads carry twice the resellers

We split the 4,261 matched origins at the median Ad CPU (2,208 ms) and the median Ad Density (15%), producing four roughly equal groups.

Heavy, dense carries roughly double the median reseller count of any other group, and the gap is significant (Mann-Whitney U, p < 0.001). Light, dense has the lowest wrapper adoption and the lowest median traffic rank of the four.

Heavy, sparse reads as sites plugged into a lot of demand that still give ads a modest share of the screen. Heavy, dense stacks all three problems on top of each other: a large ad stack, a crowded layout, and long reseller chains. We have no labelled made-for-advertising (MFA) data, so we're not calling any group MFA — but if you were building a screen for it, this is the corner of the chart you'd start in.

The Better Ads review passes 154 sites with 30% or more ad density

The Google Ad Experience Report applies the Better Ads Standards. We checked the mobile status of 4,180 origins in the sample.

• 2,375 origins have no review.
• 1,796 origins pass.
• 9 origins fail.

Of the 1,805 rated origins, 156 (8.6%) carry a CrUX Ad Density p75 of 30% or more — and 154 of those 156 pass. The 9 origins that do fail span Ad Density values from 5% to 41%. The median year of the last status change is 2019; for 52.2% of rated origins, the last change happened before 2020.

The Better Ads mobile density rule measures ad height against page content height; CrUX measures viewport area over time. They're not the same measurement, so some divergence is expected. But a rule last checked in 2019, passing a page that's 30% ads today, tells a buyer almost nothing about the layout currently running.

The results hold across subsets

The main correlations don't move much across subsets of the data.

What this data cannot show

• Cross-sectional data. The data cover one 28-day period. They show associations, not causes.
• No yield data. We use demand-stack signals as a proxy for yield. A site running many wrappers can still be getting paid badly.
• Selection. CrUX includes only origins with sufficient traffic and an ads.txt file. Sincera covers 4,261 of 12,154 origins. Matched origins run a lower median Ad CPU (2,208 ms) than unmatched origins (2,734 ms).
• Different collection times. The Sincera data and the CrUX periods don't cover the same days.
• Metric definition. Chrome doesn't document whether main-frame ad scripts count toward Ad Weight: CPU.
• Experimental metrics. Chrome can change the definitions. Later periods may not be comparable to this one.

What to do

For buyers and supply-path teams

1. Don't use Ad Weight: CPU or Ad Weight: Network as an inventory-quality filter. In this sample, high weight flags sites with more header-bidding demand, not sites with more clutter.
2. Use Ad Density as the CrUX signal for clutter, read together with reseller count — dense sites with long reseller chains are a distinct, riskier group.
3. Don't treat a Better Ads "passing" status as evidence of a clean layout. The median rated site hasn't been re-checked since 2019.

For publishers

1. Watch Ad Weight: CPU against INP. In this sample, the share of origins with poor INP climbs from 19.8% to 30.3% between the lowest and highest Ad CPU quartiles.
2. Price the CPU cost of every wrapper, identity provider and refresh rule before you add it. Slot refresh carries the largest coefficient in our model — it's also usually the easiest one to dial back.
3. Watch Ad Density p75, especially on mobile. Buyers can now see this number too.

For further research

1. Join CrUX ad metrics to realized CPM and revenue per session — the step that would let anyone measure yield directly instead of inferring it from the demand stack.
2. Use the CrUX History API to track the same origins over time, for example before and after a site removes a wrapper.

How to reproduce this analysis

The CrUX data contains the CrUX fields for every origin in this report. The summary data contains every number in the charts and tables. The calculation script rebuilds the summary with uv run report-001.py. The Sincera data is licensed, so we don't republish it at the origin level — the public files reproduce the CrUX results but not the joined results.

Method note: all random draws use the seed 20261022. We select the origin-level CrUX record for all device types. We join Sincera data by exact domain match. We exclude missing values and do not treat them as zero.