Chrome Now Measures Your Site's Ads: The Four CrUX Metrics

Since September 15, 2026, Chrome publishes how heavy a website’s advertising is, measured on real visitors. Four new experimental metrics in the Chrome User Experience Report (CrUX) record how many ads people see at once, how much of the screen they cover, and how much processing time and data they use. A week later, Google’s Search documentation on page experience added the metrics to its list of resources.

The numbers are public for eligible sites that carry ads, which means a publisher’s competitors, advertisers and ad buyers can see them as easily as the publisher can. They are not a ranking factor, and Chrome sets no pass mark. Their effect will come through the ad market first.

Chrome announced the metrics on its developer blog on September 15, describing them as a way to put numbers on ad experiences that people recognise but struggle to quantify. The data is available in CrUX Vis, the CrUX API, the CrUX History API and the Ad panel in Chrome DevTools. Chrome says it is still working on adding the metrics to the public CrUX dataset in BigQuery, and that coverage should grow over the month after launch.

Google’s page experience documentation, last updated September 22, now includes the metrics in its list of page experience resources, next to the HTTPS report and Lighthouse. The same page asks site owners whether their content avoids an excessive amount of ads that distract from the main content. The new metrics put a number on that question.

Chrome identifies ads with its own ad detection logic. All four metrics are labelled experimental and may change after feedback. The API key column is what a developer requests from the CrUX API.

Count and density are averages over time, not snapshots. Chrome’s own example: a visitor sees two ads for five seconds, scrolls, and sees none for the next five. That visit scores an Ad Count of 1.00. If the two ads had covered half the screen, the visit’s Ad Density would be 25%, because the ads filled half the screen for half the time. A page that front-loads its ads and then leaves the reader alone scores lower than one that keeps ads in view the whole way down.

Four rules from the Chrome documentation decide whether you have data at all and what it represents:

• Only pages with ads count, and only on sites whose ads.txt file names at least one authorised seller.
• The figure is the 75th percentile of eligible visits over a rolling 28 days, so it describes a worse-than-median visit, not a typical one.
• Some browsers are excluded: Chrome on iOS, Android WebView apps and other Chromium-based browsers.
• There is no JavaScript API for measuring these in your own analytics, because most ads load in cross-origin frames. CrUX and the DevTools Ad panel are the sources.

Heavy ads can still hurt indirectly. Ad scripts that tie up the processor slow the page, and Core Web Vitals do count. The Ad Weight metrics make that link visible: if a page fails on responsiveness and its ad CPU time is high, the ads are the first suspect. Our Core Web Vitals pass-rate reference shows where most sites stand on the metrics that are used for ranking.

Chrome is plain about the audience. Its announcement says the metrics should be most useful to advertisers and the services that place their ads, and it printed supporting statements from people at WPP, The Guardian, Mediavine, Index Exchange, Google’s Display & Video 360 and Adelaide. One of them stated the likely consequence directly.

In practice, a buyer comparing two sites with similar audiences can now see which one crowds its pages. If buyers begin to price that in, a site with a lighter ad load could earn more per impression while showing fewer ads. That is the argument publishers have made for years without shared data to back it. For advertisers, the same numbers are a new placement filter, alongside the brand-safety controls we covered in our post on Microsoft’s page-title exclusions.