Read Ad Load Correctly Without Inventing A Pass Score

CrUX ad metrics measure visible ad count, viewport coverage, CPU usage and network usage—not revenue or campaign performance. They are experimental measurements, separate from Core Web Vitals, with no Google-recommended targets or pass/fail thresholds. Use them to diagnose ad load and evaluate publishing changes, not to create another “good” score.

Chrome introduced the four measurements on September 15, 2026. Chrome’s announcement establishes their experimental status and the absence of recommended targets.

Choose a metric and your evidence source to see what it supports and what to check next.

The Four Metrics Separate Visual Load From Resource Cost

CrUX is the Chrome User Experience Report: aggregated field data from eligible real Chrome users. Its ad measurements describe the ads Chrome detects, rather than an inventory list from your ad server. Chrome’s metrics overview defines the four dimensions:

Metric	Measurement	API Key And Unit
Ad Count	Average distinct ad frames visible in the viewport	experimental_ad_count — unitless
Ad Density	Average fraction of the viewport occupied by ad frames	experimental_ad_density — percentage
Ad Weight: CPU	Cumulative execution time attributed to ad frames and workers	experimental_ad_cpu — milliseconds
Ad Weight: Network	Cumulative network transfer attributed to ad frames and resources	experimental_ad_kilobytes — kilobytes

The tooling guide specifies these API keys and units. Although the launch announcement describes network weight in bytes, the API reports kilobytes. Preserve that API unit in dashboards and exports.

Count and density describe visual load; CPU and network weight describe resource consumption. A small visible footprint does not establish that ads are cheap to run. Chrome still measures CPU and network weight for non-rendering ads.

P75 Summarizes Session Measurements, Not Every Screen

Chrome samples the viewport once per second and averages count and density samples within the measurement lifecycle. It accumulates CPU and network consumption over that lifecycle. CrUX then reports the 75th percentile, or p75, of those measurements—not a simple average across all visits. Chrome’s measurement methodology documents the sampling, attribution and lifecycle rules.

For a hypothetical density p75 of 23%, 75% of measured sessions had an average viewport ad density of 23% or less. It does not mean ads covered exactly 23% of every screen throughout those visits.

Count p75 is not the total number of ads served or a billable impression count. It summarizes average visible ad-frame count. Chrome counts a frame when at least one pixel is inside the viewport at sampling time. For density, only the in-viewport area contributes, and overlapping areas count once.

Reading Behavior Can Change The Measurements

Long visits can accumulate more CPU and network weight because those totals include ad activity throughout collection, not just initial loading. Comparing layouts without considering visit behavior can therefore confuse a longer reading session with a more resource-intensive implementation.

Infinite-scroll idle time affects visual averages. Repeated samples while a reader stays in one place continue contributing to count and density.

SPA route changes do not currently reset collection. Samples and resource usage continue across soft navigations until termination. Background tabs pause collection; on Android, backgrounding the browser app ends it.

These lifecycle behaviors mean a metric change can reflect changed reading behavior as well as changed ad implementation. Keep that distinction visible when interpreting a layout experiment.

Missing Public Data Does Not Mean Zero Ads

As of October 3, 2026, Chrome documents access through CrUX Vis, the CrUX API, the CrUX History API and the local DevTools Ads panel. BigQuery support is still described as planned. The latest API data uses a rolling 28-day collection period and updates daily; historical reporting updates weekly.

For a quick review, use CrUX Vis and keep origin-versus-URL scope and device filtering consistent. For automated monitoring, request the four API keys above and retain the returned collection dates. Those dates identify the visits represented by the result; the date you retrieve it is not a substitute.

CrUX ad reporting has an additional qualification: the site’s ads.txt must list at least one authorized seller. Missing files and placeholder-only records are excluded.

DevTools can attempt local measurement without that qualification, but a local result does not establish eligibility for public reporting. It also does not substitute for a field percentile.

Missing data is not zero ad load. Check eligibility and reporting availability before interpreting an absent metric. Do not fill a missing dashboard value with zero or describe an unreported site as ad-free.

Evaluate A Layout Change With Matched Field Comparisons

Save The Baseline And Commercial Guardrails

Record all four p75 values, collection dates, device filter and reporting scope alongside Core Web Vitals and your own revenue and engagement measures. Comparing an origin-level result with a URL-level result, or changing the device filter between readings, does not isolate the layout change.

Change one mechanism where practical. For example, test removing a sticky placement while keeping other placements stable. Define the commercial trade-off and guardrails beforehand using a content experiment brief.

The four metrics answer different parts of that test. Density describes viewport coverage; count describes visible ad frames; CPU and network weight describe resource use. A reduction in one is not evidence that all four improved.

Use DevTools For Immediate Inspection, Not A Field Verdict

Inspect the change locally with a repeatable viewport, scrolling sequence and observation duration. DevTools provides immediate feedback, while public field reporting reflects collected user experiences.

Do not treat one local run as p75. In particular, cumulative CPU and network measurements depend on how long collection continues, so changing the observation duration changes what the local comparison represents.

Allow For The Rolling Collection Window

After deployment, review field trends using the same scope and device filter as the baseline. A rolling 28-day window initially mixes pre-change and post-change visits. Annotate deployment dates and avoid attributing the next day’s movement entirely to the release.

Set internal decision thresholds around the experiment—for example, reducing density without an unacceptable revenue loss. Those are publisher policies, not Chrome requirements. CrUX supplies evidence about ad experience; it does not decide the monetization trade-off for your site.