Chrome Now Measures Ad Count, Density and Weight in CrUX
Chrome added four experimental ad metrics to CrUX. We measured a fixed publisher panel and found why count, density, CPU and network weight need separate diagnoses.
Chrome has added four experimental advertising metrics to the Chrome UX Report: ad count, ad density, ad CPU weight and ad network weight. They turn real-user ad exposure into field data, but they are not Core Web Vitals, do not have published pass/fail thresholds and should not be combined into an invented quality score.
What publishers can do now: establish an origin baseline at the 75th percentile, segment by device, then investigate page templates and partners locally. A higher number identifies where to look; it does not by itself diagnose the cause.
Four measurements, four different questions
| Metric | Question it answers | Important boundary |
|---|---|---|
| Ad Count | How many ads are visible during a typical one-second viewport sample? | This is a time-sampled average, not the total number of ad slots in the page HTML. |
| Ad Density | What share of the viewport is covered by ads during those samples? | It measures exposure over the visit, not only above-the-fold layout. |
| Ad Weight: CPU | How much main-thread CPU time is attributed to ads? | Origin data cannot name the responsible creative, vendor or template. |
| Ad Weight: Network | How many network bytes are attributed to ads? | Transfer weight and render impact are related but not interchangeable. |
Chrome says count and density are sampled once per second. The public CrUX surfaces report field distributions over a rolling 28-day window. The metrics are available through the CrUX API, CrUX History API, CrUX Vis and the DevTools CrUX panel. Local DevTools measurements do not apply the same ads.txt eligibility filter used for CrUX aggregation.
A fixed five-publisher field panel
To make the new metrics concrete, SearchEngineAnswer recorded the latest available mobile-origin p75 values for five named publishers in CrUX Vis. The window ended September 12, 2026. The panel was chosen in advance to include large news and search-industry publishers; it is not a representative industry sample.
| Publisher | Ad count | Density | CPU | Network |
|---|---|---|---|---|
| The New York Times | 0.44 | 15% | 1,069 ms | 1,042 KB |
| The Guardian | 0.88 | 13% | 4,766 ms | 1,889 KB |
| CNN | 0.51 | 8% | 5,080 ms | 2,652 KB |
| Forbes | 1.16 | 14% | 5,920 ms | 5,985 KB |
| Search Engine Journal | 0.88 | 11% | 803 ms | 1,065 KB |
| Panel median | 0.88 | 13% | 4,766 ms | 1,889 KB |
Download the disclosed panel as CSV. The file includes the origins, device, percentile, window end and SearchEngineAnswer’s missing-data case.
The panel shows why a single ad score would mislead
The New York Times had the highest density in this small panel, but not the highest count, CPU or network weight. CNN had lower density than every other measured origin while its ad CPU value was the second highest. Search Engine Journal matched The Guardian’s count but used roughly one sixth of its measured ad CPU time.
Those differences are diagnostic. They suggest that exposure, script work and transfer weight can move independently. They do not establish that one publisher has a better user experience, because the origin aggregate can mix templates, session lengths, consent states, markets and advertising demand.
No CrUX record is also a result
SearchEngineAnswer did not have available origin data in CrUX Vis for the same query. Chrome documents two important eligibility conditions: an origin needs enough CrUX traffic, and the aggregation requires at least one authorized seller in ads.txt. Missing data therefore cannot be read as zero ads or good performance.
For a smaller publisher, local DevTools measurements are the starting point. Record the URL, device emulation, consent state, network conditions and ad demand. Repeat the run instead of treating one trace as a field baseline.
A publisher workflow that keeps field and lab data separate
- Record the origin p75. Save all four CrUX values on the same date and device class.
- Find the outlier metric. Do not optimize count when network weight is the actual change.
- Segment templates locally. Compare article, homepage, gallery and tool pages under the same test conditions.
- Map partners and slots. Attribute CPU and bytes to scripts, creatives and auctions in DevTools.
- Change one layer. Test lazy loading, refresh policy, creative limits or vendor removal independently.
- Wait for the field window. CrUX rolls over 28 days, so local improvement will not appear instantly in origin data.
The metrics also add a field counterpart to controlled tests such as our Google Publisher Tag fetch-priority experiment. Lab tests explain a mechanism; CrUX shows the distribution experienced by opted-in Chrome users at scale.
Publishers reviewing advertising operations this week should also check the documented Private Auction block change in our search and AI operations brief.
Primary documentation
- Chrome for Developers: Advertising metrics in CrUX
- Chrome: ad metric definitions
- Chrome: measurement methodology
- Chrome: ad measurement tooling
The fixed panel is an original SearchEngineAnswer measurement collected from CrUX Vis on September 16, 2026. Values are reproduced as displayed and should be rechecked after the 28-day window changes.
Keep learning
Ask a question or join the discussion