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.

The conclusion asks for a baseline before buyers start quoting the numbers, and the baseline is a short exercise. Look up your origin in CrUX Vis, one of the four places Chrome says the data is available, and record Ad Count, Ad Density and both Ad Weight figures with the date you read them. Then do the same for two competitors with similar audiences, because the metrics’ value is comparative and Chrome set no pass mark.

Read each figure as the documentation defines it. It is the 75th percentile of eligible visits over a rolling 28 days, so it describes a worse-than-median visit rather than a typical one, and it moves slowly. Count and density are averages over time within a visit, as Chrome’s own example of two ads for five seconds then none for five shows, so a page that front-loads its ads scores lower than one that keeps them in view. For page-level detail, the Ad panel in Chrome DevTools is the tool; there is no JavaScript API because the ads load in cross-origin frames.

If your origin shows no data, check eligibility before concluding anything: only pages with ads count, the site’s ads.txt file must name at least one authorised seller, Chrome on iOS, Android WebView apps and other Chromium-based browsers are excluded, and Chrome said coverage would grow over the month after launch. Keep the baseline as a dated record, because a later change in ad layout is only measurable against it.

New public metrics get misread in predictable ways. The illustrative misreadings below each follow from skipping one of the four rules in the reading section. They are patterns, not observed publisher decisions.

The snapshot reading: an Ad Density of 25% is read as a quarter of the screen always covered by ads. The metric is an average over the visit; Chrome’s example reaches 25% with half the screen covered for half the time. The invented pass mark: a team sets an internal target and describes it as Chrome’s threshold. Chrome set none, and the metrics are labelled experimental and may change after feedback. The ranking panic: a publisher strips ads to protect rankings because the numbers are public. Google’s page experience documentation says aspects beyond Core Web Vitals do not directly help a site rank, so the direct fear is misplaced, while the indirect route through ad CPU time and responsiveness is real and was already measurable. The missing-data conclusion: an origin with no ad data is reported as having a light ad load. It may simply lack an authorised seller in ads.txt or enough eligible Chrome traffic, which is an eligibility question rather than a finding.

The reading section’s four rules prevent all four. The baseline exercise above is where they are applied for the first time, on your own numbers, before anyone else reads them to you.

Record the four numbers for your origin and two competitors this week, with the date and the 28-day window noted. The exercise takes less time than the first conversation in which a buyer quotes your Ad Density back to you.