Chrome Adds New Ad Metrics to CrUX for Web Developers

Chrome has added four experimental advertising metrics to the Chrome User Experience Report (CrUX), giving web developers a new way to see how much advertising users actually encounter on a page. The September 15, 2026 update measures ad count, screen coverage, network usage, and CPU time, turning ad-heavy experiences into data that can be tracked alongside other real-user measurements.

CrUX now measures the cost of advertising

CrUX is Google's public dataset of real-world Chrome browsing experience data. Until now, developers could use it to study measurements such as loading, responsiveness, and visual stability, but it did not provide a direct view of a site's advertising footprint. The new metrics add four experimental measurements: Ad Count, Ad Density, Ad Weight for network usage, and Ad Weight for CPU usage. Together, they describe both what users see and what advertising resources consume while a page is being used.

The four measurements answer different questions

Ad Count measures the average number of distinct advertisements visible in the browser viewport during a visit. Ad Density measures how much of that visible area is occupied by ads, so two pages with the same number of advertisements can still produce very different results. Ad Weight for Network measures the compressed bytes transferred by advertising resources, including scripts, images, and stylesheets. Ad Weight for CPU measures JavaScript execution time consumed by ad frames and their resources, making it possible to see an advertising load that may be expensive even when it is not visually dominant.

Chrome samples the page while people use it

The measurements are based on the page visit rather than a single screenshot of the initial load. Chrome begins the ad measurement lifecycle when it receives the first response bytes for the main HTML document and continues collecting data until the tab is unloaded. For Ad Count and Ad Density, Chrome samples the viewport once per second while the user moves through the page. That means a long article with ads at the top and fewer ads farther down can produce a different measurement from a page that keeps the same advertising load throughout the visit.

The numbers come from real Chrome users

CrUX reports field data collected from eligible Chrome users, rather than measurements from one developer's computer. The new ad metrics use a rolling 28-day window and are reported at the 75th percentile, which represents the upper portion of observed user experiences while reducing the influence of extreme outliers. The metrics are available at both page and origin levels when the relevant CrUX eligibility requirements are met. They should therefore be read as aggregated user-experience data, not as a guaranteed measurement for every visitor.

There is an important limitation for sites without ads.txt sellers

Chrome does not report these ad metrics for every website automatically. The documentation says pages and origins without at least one authorized seller defined in an ads.txt file do not receive CrUX ad-metric data. Ads.txt is a publisher-controlled file used to declare which advertising sellers are authorized to sell a site's inventory. This requirement means a developer may have advertising on a page and still find that the corresponding CrUX ad measurements are unavailable.

Developers can inspect the data through several tools

The new measurements are already exposed through the CrUX API, CrUX History API, CrUX Vis, and Chrome DevTools' Ad panel. The API provides programmatic access, which makes the data useful for performance monitoring and CI/CD workflows where teams automatically check changes over time. The History API can provide historical weekly data for trend analysis, while CrUX Vis offers a more visual way to inspect results. Google says BigQuery support for querying the ad metrics is still being developed, so teams that rely on large SQL-based CrUX analysis will have to wait for that addition.

The metrics are useful, but they are not a performance score

Chrome explicitly classifies the new ad measurements as experimental, so their definitions and implementation can change as feedback arrives. They also do not use the Good, Needs Improvement, or Poor thresholds familiar from Core Web Vitals. That distinction matters because a higher ad count or larger network weight is not automatically a failure for every business model. The measurements are better treated as evidence about the advertising experience, which developers can compare with page performance, engagement, and business requirements.

What web teams can learn from the new data

The practical value is in connecting advertising decisions with what real visitors experience. A team can use network and CPU measurements to investigate whether advertising resources are consuming substantial bandwidth or processing time, while Ad Density shows how much of the visible page advertising occupies. Because the measurements come from real Chrome sessions, they can also reveal differences that a clean local development environment may miss. The next step for developers is to watch the experimental data over time and use it alongside existing performance measurements rather than treating any single metric as a verdict on the page.