Chrome Just Put Your Ad Load on the Public Record — and ads.txt Decides Whether You're In It

Chrome added four experimental ad metrics to the Chrome User Experience Report on 15 September 2026, announced by Alex Cone on the Chrome for Developers blog.

This is field data from real Chrome users, published in a public dataset. Until now, "this site is buried in ads" was a subjective complaint. It is now a number that anyone — a competitor, a client, an advertiser deciding where to buy — can look up about any qualifying origin.

The four metrics

• Ad Count — how many ads a typical user sees at once.
• Ad Density — the fraction of the visible viewport occupied by ad frames.
• Ad Weight (Network) — bytes consumed by ad resources.
• Ad Weight (CPU) — milliseconds consumed by ad resources.

All four are reported at the 75th percentile of page views, at both URL and origin level, consistent with how CrUX handles Core Web Vitals.

How count and density are actually measured

Chrome samples the viewport once per second and takes a snapshot. That detail matters more than it first appears, because it means these are time-weighted measures, not page-level ones.

Within each sample:

• An ad is counted if at least one pixel of it is in the viewport.
• For density, Chrome calculates the union of overlapping ad areas so stacked or overlapping frames aren't double-counted, and measures only the portion physically inside the viewport.

The two weight metrics accumulate differently — they run from the first response bytes until page unload, capturing everything ads consume across the whole visit rather than only what was on screen.

The practical consequence: a sticky ad unit that follows the user down the page is measured on every single sample. A leaderboard at the top that scrolls away is measured once or twice. Two pages with identical ad counts on paper can produce very different density figures depending on what stays pinned.

The ads.txt requirement is the detail to act on

Only sites with at least one authorized seller in their ads.txt are included in CrUX ad metrics reporting. Origins with no ads.txt, or with only placeholder records, are excluded from the aggregate reports.

This cuts both ways and both directions are worth thinking about.

If you run ads and your ads.txt is missing, malformed or still full of boilerplate, you won't appear — which means you also can't measure yourself, can't benchmark against anyone, and can't demonstrate improvement. That's now a second reason to fix a file most publishers treat as a one-off setup task and never revisit.

If you're checking a competitor and find nothing, absence of data is not evidence of a clean ad experience. It may simply mean their ads.txt doesn't qualify them.

What this is not

These metrics are explicitly experimental. Chrome states they are "not part of Core Web Vitals and don't have suggested targets or thresholds." There is no status colour, no good/needs-improvement/poor banding, and no stated ranking use.

Treat anyone claiming a target ad density number as making it up. Chrome has deliberately published no threshold, and has said it is open to community feedback on how these evolve.

It's also worth separating this from the existing, much older machinery: the Better Ads Standards and Chrome's ad filtering already police specific intrusive formats. These new metrics don't enforce anything. They describe.

Why it still matters for SEO

Two reasons, neither of which requires assuming a ranking factor.

First, ad experience already influences the things that are measured. Ad Weight (CPU) and Ad Weight (Network) are direct descriptions of what makes Interaction to Next Paint and Largest Contentful Paint bad on ad-funded pages. If your Core Web Vitals are poor and you've optimised everything under your own control, these metrics tell you how much of the remaining problem is the ad stack — with field data rather than a lab trace.

Second, public data changes conversations. A metric that anyone can pull is a metric that ends up in pitch decks, in "why is our competitor outranking us" analyses, and in arguments between SEO and revenue teams about how many units belong above the fold. That argument has historically been unwinnable for SEO because nobody had numbers. Now both sides do.

What to do

Check whether you're in the dataset at all — that starts with validating ads.txt on every origin you run ads on, including subdomains, and confirming the records are real authorized sellers rather than placeholders.

Pull your own numbers via the CrUX API or the CrUX History API, and view them in CrUX Vis. Chrome notes data availability will grow over the coming months, so a thin or missing result today isn't necessarily final.

Look at density against your own Core Web Vitals trend, not against an imagined target. The useful question is whether your ad load correlates with your INP and LCP over time, which the History API lets you check.

Watch sticky and interstitial units specifically. Once-per-second sampling punishes persistence, so a single pinned unit can dominate your density figure while a heavier but transient one barely registers.

Don't over-read it yet. Chrome has acknowledged a real limitation already: on single-page applications the metrics accumulate for the entire lifespan of the tab and don't reset on soft navigation. If your site is an SPA, your weight figures are measuring the session, not the page.

Sources

• Chrome for Developers: New ad metrics in Chrome User Experience Report
• Chrome for Developers: Chrome ad metrics documentation
• Chrome for Developers: Ad metrics methodology