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). The metrics come from real Chrome users. They describe how many ads a user sees and how much of the screen the ads use. They also describe the CPU time and network data that the ads consume. We joined these metrics to Sincera crawl data on ad stacks, ad layout and supply chains.

What Chrome measures

Chrome identifies ad frames with its ad detection logic. It then records four values for each page view. CrUX publishes the 75th percentile (p75) of each value for each 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 have no "good" or "poor" thresholds. Chrome publishes values, not grades. In this report, "high" and "low" refer to positions in our sample, for example quartiles.

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 origins, 12,154 (61.5%) have ad metrics. Of the 12,154 origins, 4,261 also have a Sincera profile with ad-stack and supply-chain data.

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. Its data is independent of Chrome. We use these fields:

We have no CPM, revenue or bid-price data. Demand-stack signals show how much demand a site connects to. They do not show what the 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 that 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 has one ad frame in view and ads on 14% of the viewport. It uses 2.5 seconds of ad CPU time and 1.7 MB of ad data. The distributions of CPU and network have long right tails.

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

Weight and density measure different properties

Ad Weight: CPU and Ad Weight: Network are closely related (ρ = 0.82). Ad Density is weakly related to both (ρ = 0.19 and 0.27). Ad Count is in the middle. It relates to weight (0.57) and to density (0.43).

This pattern shows two separate properties. Weight describes the code and data that ads bring to the page. Density describes the space that ads take on the screen. The next two sections show what each property relates to.

Ad weight rises with wrappers, identity providers and refresh

Ad Weight: CPU increases with each demand-stack signal. The strongest relations are with wrapper count (ρ = 0.59), identity providers (0.56), slot refresh on desktop (0.55) and ad units (0.52). The relations stay almost the same after control for traffic rank and publisher type (β = 0.49 to 0.56).

The median Ad CPU of sites with no detected wrapper is 1,362 ms. With three or more wrappers, the median is 4,984 ms. Ad Density does not increase with wrapper count. It decreases from a median of 18% to 14%.

The quartiles of Ad CPU show the same pattern:

A multivariable model gives the separate contribution of each signal to Ad CPU (n = 3,847, R² = 0.47). Slot refresh has the largest coefficient.

Interpretation. In this sample, high ad weight identifies sites that run more auctions, more identity calls and more refreshes. It does not identify sites with more ad space. Chrome's documentation does not state whether header-bidding code in the main page frame counts as ad CPU. If it does, part of this relation comes from the definition of the metric.

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

Ad Density is the only CrUX ad metric with a clear relation to the Sincera ads-to-content ratio. The two values come from different sources and different methods, but they agree (ρ = 0.36, n = 3,793). The agreement is stronger on mobile pages (ρ = 0.41) than on desktop pages (ρ = 0.28).

Ad Density has small negative relations with the demand stack. Examples are wrappers (ρ = −0.14) and desktop slot refresh (ρ = −0.16). It has positive relations with resellers (ρ = 0.14) and with the share of phone traffic (ρ = 0.30). Denser sites also have less traffic (ρ = 0.18 with rank number).

Interpretation. The densest sites in the sample are smaller, have more phone traffic and connect to less header-bidding demand. They also sell through more resellers. Ad Density is the CrUX metric that relates most to inventory quality as buyers usually define it.

Sites with heavy ads have slower interaction, not slower loading

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

Across the ten deciles of Ad CPU, the median INP increases 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). After control for traffic rank and publisher type, the coefficient is 0.23 (n = 4,236).

Device mix can affect INP, because phones are slower than desktop computers. CrUX reports device mix for 3,061 of the origins. In that group, the coefficient is 0.11 without the control and 0.11 with the phone-share control. Device mix does not explain the relation. The relation is weaker in this group than in the full sample. We do not know the cause of this difference.

Interpretation. Ad code can compete with the page for the main thread, for example when ad scripts run in the page itself. The data agree with this mechanism, but the data cannot prove it. Lower LCP failure in the heavy quartile probably shows that sites with large ad stacks are also better-engineered sites. Cumulative Layout Shift (CLS) has no consistent direction.

Dense sites with heavy ads carry twice the resellers

We divided the 4,261 matched origins at the median Ad CPU (2,208 ms) and the median Ad Density (15%). The result is four groups of approximately equal size.

The heavy, dense group has approximately twice the median reseller count of each other group. The difference is significant (Mann-Whitney U, p < 0.001). The light, dense group has the lowest wrapper adoption and the lowest median traffic rank.

Interpretation. The heavy, sparse group connects to much demand and gives ads a moderate share of the screen. The heavy, dense group combines a large ad stack, a crowded layout and long reseller chains. We have no labelled data for made-for-advertising (MFA) sites. We therefore do not classify any group as MFA.

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%) have a CrUX Ad Density p75 of 30% or more. Of these 156 origins, 154 pass. The 9 failing origins have 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 occurred before 2020.

The Better Ads mobile density rule measures ad height against page content height. CrUX measures viewport area over time. The two values are not the same measurement. But the comparison shows that a "passing" status gives little information about the current ad layout.

The results hold across subsets

The main correlations do not change materially in 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 proxies for yield. A site with many wrappers can still have low prices.
• Selection. CrUX includes only origins with sufficient traffic and an ads.txt file. Sincera covers 4,261 of 12,154 origins. Matched origins have lower median Ad CPU (2,208 ms) than unmatched origins (2,734 ms).
• Different collection times. The Sincera data and the CrUX periods do not cover the same days.
• Metric definition. Chrome does not document whether main-frame ad scripts count toward Ad Weight: CPU.
• Experimental metrics. Chrome can change the definitions. Later periods may not be comparable.

What to do

For buyers and supply-path teams

1. Do not use Ad Weight: CPU or Ad Weight: Network as an inventory-quality filter. In this sample, high weight identifies sites with more header-bidding demand, not sites with more clutter.
2. Use Ad Density as the CrUX signal for clutter. Use it together with reseller count, because dense sites with long reseller chains are a separate group.
3. Do not use a Better Ads "passing" status as evidence of a clean layout.

For publishers

1. Monitor Ad Weight: CPU together with INP. In this sample, the share of origins with poor INP increases from 19.8% to 30.3% between the lowest and highest Ad CPU quartiles.
2. Measure the CPU cost of each wrapper, identity provider and refresh rule before you add it. Slot refresh has the largest coefficient in our model.
3. Monitor Ad Density p75, especially on mobile. Buyers can now see this value in a public dataset.

For further research

1. Join CrUX ad metrics to realized CPM and revenue per session. This step is necessary to measure yield directly.
2. Use the CrUX History API to examine changes over time on the same origins, for example after a site removes a wrapper.

How to reproduce this analysis

The CrUX data contains the CrUX fields for each 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-002.py. The Sincera data is licensed. We do not republish it at the origin level, so 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.