---
title: "Chrome's ad weight tracks demand. Ad density tracks clutter."
description: "We joined Chrome's new CrUX ad metrics for 12,154 publisher origins to Sincera ad-stack data. Ad weight tracks the demand stack; ad density tracks clutter."
author: "Vishveshwar Jatain"
author_url: "https://mediacontext.dev/authors/vishveshwar-jatain/"
published: 2026-10-22
updated: 2026-10-22
canonical: https://mediacontext.dev/blog/report-002/
license: "CrUX data: CC BY 4.0, Google"
data:
  - "https://mediacontext.dev/research/report-002-summary.json"
  - "https://mediacontext.dev/research/report-002-crux.json"
  - "https://mediacontext.dev/research/report-002.py"
---

## At a glance

We joined Chrome's new CrUX ad metrics for 12,154 publisher origins to Sincera ad-stack data.

- **Ad CPU rises with the demand stack:** ρ = 0.59 with header-bidding wrappers. Identity providers, ad units and slot refresh show the same pattern.
- **Ad Density rises with the layout:** ρ = 0.36 with the Sincera ads-to-content ratio (0.41 on mobile), and slightly negative with the stack.
- **The two are different signals:** Ad CPU and Ad Density correlate at only 0.19.
- **Heavy ads go with slower interaction, not slower loading:** poor INP rises from 19.8% to 30.3% across Ad CPU quartiles. Poor LCP falls.
- **Dense, heavy sites carry twice the resellers:** median 530, against 229 to 292 for every other group.
- **Better Ads passes dense pages:** 154 passing sites have Ad Density of 30% or more.

**What to do:** Buyers, stop filtering on ad weight and screen on Ad Density plus reseller count. Publishers, track Ad CPU against INP and cost each wrapper and refresh rule before adding it.

**Limits:** One 28-day period, so associations, not causes. No CPM or revenue data; demand-stack signals stand in for yield.

## 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.

| Metric | API key | Unit | What Chrome records |
|---|---|---|---|
| Ad Count | `experimental_ad_count` | Ad frames | The average number of ad frames in the viewport during the visit |
| Ad Density | `experimental_ad_density` | Percent of viewport | The average share of the viewport that ad frames cover, sampled one time each second |
| Ad Weight: CPU | `experimental_ad_cpu` | Milliseconds | The total JavaScript execution time of ad frames and their subresources |
| Ad Weight: Network | `experimental_ad_kilobytes` | Kilobytes | The total data that ad frames and ad resources transfer |

### Figure 1: What Chrome records for each page view

| Metric | What it measures |
| --- | --- |
| Ad Count | ad frames in the viewport, averaged over the visit |
| Ad Density | ad area / viewport area, sampled once per second |
| Ad Weight: CPU | JavaScript time in ad frames (ms) |
| Ad Weight: Network | bytes transferred by ad frames and resources (KB) |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026_
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](https://developer.chrome.com/docs/ads/metrics), [Ad Density](https://developer.chrome.com/docs/ads/metrics/density), [Ad Weight: CPU](https://developer.chrome.com/docs/ads/metrics/weight-cpu), [tooling guide](https://developer.chrome.com/docs/ads/tooling).

## 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.

### Figure 2: 12,154 origins have ad metrics; 4,261 also have Sincera data

| Stage | Origins |
| --- | --- |
| Publisher origins queried in CrUX | 19,765 |
| Origins with CrUX ad metrics | 12,154 (61.5%) |
| Origins also in Sincera | 4,261 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, n = 19,765_
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:

| Signal | Definition | Use in this report |
|---|---|---|
| Wrappers | Number of header-bidding wrappers detected, for example Prebid or Amazon APS | Demand stack |
| Identity providers | Number of identity solutions detected | Demand stack |
| Ad units | Number of unique ad slot identifiers (GPIDs) observed | Demand stack |
| Refresh share | Percent of ad slots that refresh, desktop and mobile | Demand stack |
| Video players | Number of video players detected | Demand stack |
| Ads in view | Average number of ad units in the viewport | Layout |
| Ads-to-content ratio | Average share of the page that ads occupy | Layout |
| Supply paths | Number of seller paths to the inventory | Supply chain |
| Resellers | Number of reseller relationships | Supply chain |
| Traffic rank | Position in a public traffic ranking | Control |

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.

### Figure 3: The median origin: 1 ad, 14% density, 2.5 s of ad CPU

| Metric | p25 | Median | p75 |
| --- | --- | --- | --- |
| Ad Count | 0.77 | 1.01 | 1.54 |
| Ad Density (%) | 10 | 14 | 20 |
| Ad Weight: CPU (ms) | 1,319 | 2,528 | 5,333 |
| Ad Weight: Network (KB) | 744 | 1,735 | 3,981 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, n = 12,154_
| Metric | p10 | p25 | Median | p75 | p90 |
|---|---|---|---|---|---|
| Ad Count | 0.51 | 0.77 | 1.01 | 1.54 | 2.03 |
| Ad Density (%) | 6 | 10 | 14 | 20 | 29 |
| Ad Weight: CPU (ms) | 762 | 1,319 | 2,528 | 5,333 | 8,790 |
| Ad Weight: Network (KB) | 328 | 744 | 1,735 | 3,981 | 6,920 |

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).

### Figure 4: Weight and density are weakly related (ρ = 0.19)

|  | Ad CPU | Ad Network | Ad Count | Ad Density | INP | LCP | CLS |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Ad CPU | 1.00 | 0.82 | 0.57 | 0.19 | 0.21 | 0.01 | 0.21 |
| Ad Network | 0.82 | 1.00 | 0.58 | 0.27 | 0.18 | -0.02 | 0.23 |
| Ad Count | 0.57 | 0.58 | 1.00 | 0.43 | -0.02 | -0.09 | 0.12 |
| Ad Density | 0.19 | 0.27 | 0.43 | 1.00 | 0.06 | -0.05 | 0.11 |
| INP | 0.21 | 0.18 | -0.02 | 0.06 | 1.00 | 0.36 | 0.21 |
| LCP | 0.01 | -0.02 | -0.09 | -0.05 | 0.36 | 1.00 | 0.30 |
| CLS | 0.21 | 0.23 | 0.12 | 0.11 | 0.21 | 0.30 | 1.00 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, n = 12,154_
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).

### Figure 5: Ad CPU tracks the demand stack. Ad Density tracks layout.

| Signal | Ad CPU ρ | Ad Density ρ |
| --- | --- | --- |
| Wrappers | 0.59 | -0.14 |
| Identity providers | 0.56 | -0.13 |
| Ad units | 0.52 | 0.04 |
| Refresh share, desktop | 0.55 | -0.16 |
| Refresh share, mobile | 0.49 | -0.07 |
| Video players | 0.46 | -0.08 |
| Ads in view | 0.46 | 0.09 |
| Ads-to-content ratio | 0.32 | 0.36 |
| Supply paths | 0.32 | -0.06 |
| Resellers | 0.09 | 0.14 |
| Traffic rank (log) | -0.05 | 0.18 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, joined to Sincera profiles, n = 4,261_
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%.

### Figure 6: Ad CPU rises with each wrapper. Ad Density does not.

| Wrappers | n | Ad CPU median (ms) | Ad CPU p25-p75 | Ad Density median (%) | Ad Density p25-p75 |
| --- | --- | --- | --- | --- | --- |
| 0 | 1,904 | 1,362 | 896-2,031 | 18 | 10-29 |
| 1 | 646 | 2,299 | 1,326-3,869 | 16 | 10-23 |
| 2 | 628 | 3,667 | 2,057-6,840 | 15 | 10-20 |
| 3 or more | 1,083 | 4,984 | 2,962-8,048 | 14 | 11-19 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, joined to Sincera profiles, n = 4,261_
The quartiles of Ad CPU show the same pattern:

| Ad CPU quartile | Range (ms) | Sites with a wrapper | Sites with refresh | Median ad units | Median resellers |
|---|---|---|---|---|---|
| Q1 (lowest) | 118 to 1,221 | 21.6% | 14.9% | 3 | 215 |
| Q2 | 1,223 to 2,208 | 37.7% | 28.9% | 8 | 295 |
| Q3 | 2,210 to 4,622 | 72.1% | 59.2% | 22 | 444 |
| Q4 (highest) | 4,628 to 84,343 | 89.9% | 79.7% | 50 | 330 |

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.

| Signal | β | 95% CI |
|---|---|---|
| Refresh share (desktop) | 0.21 | 0.18 to 0.25 |
| Ads in view | 0.16 | 0.13 to 0.19 |
| Wrappers | 0.15 | 0.10 to 0.20 |
| Identity providers | 0.15 | 0.11 to 0.19 |
| Ad units | 0.10 | 0.07 to 0.14 |
| Video players | 0.08 | 0.05 to 0.11 |
| Traffic rank (log) | 0.03 | 0.01 to 0.06 |

**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).

### Figure 7: Ad Density rises with the Sincera ads-to-content ratio

| ACR decile median | n | Ad Density median (%) | p25-p75 |
| --- | --- | --- | --- |
| 3.6% | 380 | 9 | 5-15 |
| 6.4% | 379 | 12 | 8-21 |
| 9.0% | 379 | 13 | 9-21 |
| 11.4% | 379 | 14 | 10-22 |
| 14.1% | 380 | 16 | 11-22 |
| 16.5% | 379 | 16 | 12-23 |
| 19.2% | 379 | 18 | 13-27 |
| 22.3% | 379 | 17 | 13-26 |
| 27.1% | 379 | 19 | 14-28 |
| 35.6% | 380 | 22 | 16-29 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, joined to Sincera profiles, n = 3,793_
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).

| Ad Density quartile | Range (%) | Sites with a wrapper | Median ads-to-content ratio | Median resellers | Median traffic rank |
|---|---|---|---|---|---|
| Q1 (lowest) | 1 to 10 | 55.1% | 0.09 | 222 | 46,518 |
| Q2 | 11 to 15 | 69.0% | 0.16 | 287 | 49,824 |
| Q3 | 16 to 23 | 64.0% | 0.17 | 426 | 56,301 |
| Q4 (highest) | 24 to 84 | 35.6% | 0.19 | 459 | 70,365 |

**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.

### Figure 8: Poor INP rises from 21% to 32% across Ad CPU deciles

| Ad CPU decile median (ms) | n | Median INP (ms) | INP poor (%) | LCP poor (%) | CLS poor (%) |
| --- | --- | --- | --- | --- | --- |
| 548 | 1,218 | 119 | 20.7% | 19.3% | 16.7% |
| 961 | 1,215 | 125 | 19.5% | 19.9% | 22.2% |
| 1,320 | 1,215 | 129 | 18.9% | 18.6% | 26.4% |
| 1,726 | 1,214 | 135 | 19.8% | 17.4% | 26.7% |
| 2,216 | 1,216 | 136 | 19.2% | 16.0% | 29.5% |
| 2,914 | 1,214 | 144 | 21.0% | 16.8% | 31.0% |
| 3,922 | 1,216 | 151 | 23.5% | 15.4% | 31.8% |
| 5,333 | 1,215 | 153 | 23.1% | 12.0% | 28.5% |
| 7,273 | 1,215 | 166 | 32.0% | 11.4% | 23.3% |
| 11,864 | 1,216 | 166 | 32.2% | 14.9% | 22.0% |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, n = 12,154_
| Ad CPU quartile | INP p75 over 200 ms | LCP p75 over 2,500 ms | CLS p75 over 0.1 |
|---|---|---|---|
| Q1 (lowest) | 19.8% | 19.6% | 20.9% |
| Q2 | 19.4% | 16.9% | 27.8% |
| Q3 | 22.4% | 15.7% | 31.5% |
| Q4 (highest) | 30.3% | 12.5% | 23.1% |

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.

### Figure 9: Dense sites with heavy ads carry the longest reseller chains

| Profile | n | Wrapper share | Refresh share | Median resellers | Median INP (ms) |
| --- | --- | --- | --- | --- | --- |
| Light, sparse | 1,102 | 36% | 26% | 229 | 114 |
| Light, dense | 1,029 | 22% | 18% | 292 | 136 |
| Heavy, sparse | 1,091 | 85% | 74% | 257 | 145 |
| Heavy, dense | 1,039 | 77% | 65% | 530 | 154 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, joined to Sincera profiles, n = 4,261_
| Profile | Sites | With a wrapper | With refresh | Median ads-to-content ratio | Median resellers | Median INP (ms) |
|---|---|---|---|---|---|---|
| Light, sparse | 1,102 | 36.4% | 25.7% | 0.09 | 229 | 114 |
| Light, dense | 1,029 | 22.4% | 17.9% | 0.16 | 292 | 136 |
| Heavy, sparse | 1,091 | 84.8% | 74.1% | 0.16 | 257 | 145 |
| Heavy, dense | 1,039 | 77.0% | 64.6% | 0.21 | 530 | 154 |

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.

### Figure 10: 154 passing sites show 30% or more ad density

| Segment | Count |
| --- | --- |
| Checked | 4,180 |
| Not reviewed | 2,375 |
| Rated | 1,805 |
| Passing | 1,796 |
| Passing, Ad Density 30% or more | 154 |
| Failing | 9 |
| Failing at 30% or more | 2 |

_Source: Chrome UX Report API, 28-day periods ending 20 and 27 September 2026, n = 4,180_
- 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.

| Subset | Sites | Ad CPU and wrappers | Ad CPU and desktop refresh | Ad Density and ads-to-content ratio | Ad Density and wrappers | Ad CPU and INP |
|---|---|---|---|---|---|---|
| All matched | 4,261 | 0.59 | 0.55 | 0.36 | −0.14 | 0.22 |
| Ad-monetized publishers only | 3,279 | 0.59 | 0.55 | 0.35 | −0.11 | 0.24 |
| Period ending 27 September | 3,377 | 0.59 | 0.56 | 0.36 | −0.15 | 0.23 |
| Traffic rank above median | 2,131 | 0.58 | 0.55 | 0.36 | −0.06 | 0.20 |
| Traffic rank below median | 2,130 | 0.60 | 0.55 | 0.36 | −0.19 | 0.24 |

## 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](/research/report-002-crux.json) contains the CrUX fields for each origin in this report. The [summary data](/research/report-002-summary.json) contains every number in the charts and tables. The [calculation script](/research/report-002.py) 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.*

## Disclosure

MediaContext sells publisher data and research tools. This report uses data that MediaContext collects. No company paid for or reviewed this research before publication.

## Sources

- https://developer.chrome.com/docs/ads/metrics
- https://developer.chrome.com/docs/ads/metrics/density
- https://developer.chrome.com/docs/ads/metrics/weight-cpu
- https://developer.chrome.com/docs/ads/tooling

## Cite this report

Jatain, V. (2026). Chrome's ad weight tracks demand. Ad density tracks clutter. MediaContext Report 002. https://mediacontext.dev/blog/report-002/

## Corrections

Found an error? Email vj@andorlabs.ca with the section and the evidence. We correct errors in place and note the change and its date at the top of the report.