Chrome now publishes every site's ad load. Use it to audit where your ads run

Until last week, "that site is too cluttered for our ads" was an opinion. On 15 September 2026, Chrome started publishing how many ads a typical visitor sees on a given site, how much of their screen those ads occupy, and how much bandwidth and processing the ads consume. That turns a gut-feel exclusion argument into a number you can look up for any domain in your placement report.

What Chrome actually published

The Chrome User Experience Report is the public dataset behind the field data in PageSpeed Insights and Search Console: real measurements from real Chrome users, aggregated by origin. Until now it covered loading and interaction. It now also covers advertising, through four metrics.

Two qualifications, stated plainly because they bound everything that follows. All four are labelled experimental, meaning Google expects to refine them. And none of them is part of Core Web Vitals, is a ranking signal, or comes with a published "good" threshold. Access at launch runs through the CrUX API, the CrUX History API and the Ad panel in Chrome DevTools; Google has said the metrics will be added to the CrUX BigQuery dataset later, which is the route that will make whole-placement-list analysis practical rather than manual.

Why this matters more to buyers than to publishers

Most of the coverage framed this as a publisher story: sites with clean ad experiences now have a public number to point at in direct sales conversations. True, and useful to the few hundred publishers who compete on that basis.

The larger shift is on the buy side. Open-web display buying has always had an evidence gap between "our ads ran on 4,000 domains" and "our ads were seen". Viewability vendors measure whether your ad was technically in view. Nobody was measuring how much competition for attention surrounded it, at the level of a domain, from real users, for free. That number now exists for any origin with enough Chrome traffic to be reported, whether or not that origin is a customer of anyone.

It is worth being precise about what it is not. CrUX reports the origin, not your placement. It tells you what a typical visitor to that site experiences, not what happened on the specific page where your ad served, and not whether your specific impression was viewable. It is a screening signal, not a measurement of your campaign.

Working thresholds, since Google published none

The absence of thresholds is the single biggest obstacle to using this data, and it will not be resolved quickly on an experimental metric. So here is the banding we are using internally as a starting point. It is our judgement, not a Google standard, and it is deliberately conservative.

The logic behind the density bands is the one number every buyer already understands: attention is a share of screen. If advertising occupies a third of the viewport a visitor sees, your creative is one of several things competing for a glance, and the probability that yours is the one that registers falls accordingly. Above that, the page has stopped being content with ads on it.

Treat the weight metrics differently. There is no sensible universal byte or millisecond threshold, because a video-heavy news site and a recipe blog are not comparable. Use them relatively: rank the domains in your own placement list and look at the worst decile. A domain whose ads consume several times the CPU of its peers is telling you something about the quality of its stack, and, by extension, about how much of your paid impression renders before the visitor scrolls away.

The placement audit, step by step

This takes an afternoon the first time and about twenty minutes a month after that.

1. Export where your money went. In Google Ads, pull the placement report for Display, Demand Gen and Performance Max over the last 30 to 90 days. Sort by cost, not by impressions. Take the top 50 domains — in most accounts that is well over half of spend.
2. Look each origin up in CrUX. One request per origin against the CrUX API, asking for the ad metrics alongside the Core Web Vitals you may already be pulling. The request shape is the standard one:

   POST https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY
   {
     "origin": "https://example.com",
     "formFactor": "PHONE",
     "metrics": ["...ad metric names from Chrome's docs..."]
   }

   Query PHONE separately from DESKTOP. Ad layouts diverge sharply by form factor, and the mobile picture is the one that usually decides the call.
3. Band each domain against the table above, and mark any origin CrUX has no data for. Low-traffic domains are absent from the dataset entirely, and a long tail of unmeasurable, low-traffic domains taking meaningful spend is itself a finding worth acting on.
4. Cross-reference with performance. Add cost, conversions and conversion rate per domain. You are looking for the intersection: saturated ad experience and below-average conversion rate and non-trivial spend. That intersection is your exclusion list, and it is a far better-evidenced one than a list built from domain names that look spammy.
5. Apply exclusions where the platform still allows it. Account-level placement exclusions remain the blunt instrument that works across campaign types. Note that the room to do this keeps narrowing — Meta removed placement exclusions in v26.0 — which is an argument for applying what control you still have on Google inventory deliberately rather than sporadically.
6. Re-run monthly and keep the history. The CrUX History API gives you trend, which is where the interesting signal lives: a domain whose ad density has climbed steadily over six months is a site monetising harder, and its performance for you will usually follow the same curve downward.

What each metric predicts, in campaign terms

The mapping from a browser metric to a media symptom is where this becomes operational.

None of these is proof on its own. Each one converts a vague suspicion into a specific hypothesis you can test by excluding one domain and watching what happens to blended performance rather than to the platform's own attributed numbers.

If your own site carries ads

Your ad load is now in the same public dataset as your Core Web Vitals. Anyone — a prospective direct advertiser, an agency, a competitor — can look it up. If you monetise with programmatic display and you have been quietly adding units, that is now visible.

The flip side is an argument you can now make with evidence. A publisher whose ad density sits in the clean band has a number to put in front of a direct buyer, and it is a number the buyer can verify independently rather than take on trust. That is a better position than it sounds, in a market where most inventory claims cannot be checked.

For everyone else — sites that carry no advertising at all — these metrics will be absent or negligible, and the lesson transfers rather than applies. Ad Weight — CPU is measuring exactly the thing that third-party chat widgets, review platforms and tag managers do to your own pages. The advertising industry now has a public number for it. Your site has the same problem and only the Core Web Vitals symptom to show for it.

The limits, stated fairly

Four constraints will decide whether this is durably useful or a one-quarter curiosity.

• Origin-level, not page-level. A publisher with a clean homepage and a saturated article template reports as an average of both. Your ads almost certainly run on the second one.
• Chrome-only, and traffic-gated. Origins without enough Chrome traffic are simply absent, which skews the dataset towards larger sites — the opposite of where questionable inventory concentrates.
• Experimental status. Definitions may change, and a metric you have built a monthly process around may be redefined under you. Keep the raw exports.
• No thresholds. Everyone working with this data is using their own bands, including us. Do not present them to a client as a standard, and do not let a vendor present theirs as one either.

Even with all four, this is the most useful free addition to open-web media quality analysis in some time, because it is public, it is measured from real users, and it applies to every site rather than to the ones that opted in to a measurement vendor.

Frequently asked questions

What are the new CrUX ad metrics?

On 15 September 2026 Chrome added four experimental ad metrics to the Chrome User Experience Report: Ad Count, the average number of ads visible in the viewport; Ad Density, the average share of the viewport occupied by ads; Ad Weight (Network Usage), the bytes consumed by advertising; and Ad Weight (CPU Usage), the processing time consumed by advertising in milliseconds. All four are drawn from real Chrome users rather than lab tests.

Where can I see the CrUX ad metrics for a website?

Through three routes at launch: the CrUX API for current data, the CrUX History API for trend data, and the Ad panel in Chrome DevTools for a live page. Google has said the metrics will be added to the CrUX BigQuery dataset later, which is the route that makes bulk analysis of a whole placement list practical.

Are the CrUX ad metrics part of Core Web Vitals?

No. All four are labelled experimental, they are not part of Core Web Vitals, and Google has not published recommended thresholds for any of them. They are not a ranking factor and there is no stated pass or fail line. Any threshold you see quoted, including ours, is someone's working judgement rather than a Google standard.

How can advertisers use ad density data?

As a screening layer on placement reports. Pull the domains taking the most spend from your Display, Demand Gen or Performance Max placement report, look up each one's ad count and ad density, and treat high values as a signal that your impression is competing with several others for attention on the same screen. It is evidence for exclusion decisions you were previously making on gut feel, not a viewability measurement of your specific ad.

Do the CrUX ad metrics identify made-for-advertising sites?

Not on their own, but they make the pattern much easier to spot. Made-for-advertising sites typically combine a high ad count, high ad density and heavy ad network and CPU weight with thin content. CrUX gives you the first four numbers for any origin with enough traffic to be reported, so a domain that is extreme on all of them deserves a manual look before it keeps your budget.

Do these metrics affect my own website?

Only if your site carries advertising. If it does, your ad load is now reported in the same public dataset as your Core Web Vitals, which means buyers and partners can look it up. If your site does not run ads, the metrics will be absent or near zero, and the relevant lesson is a different one: third-party scripts consume the same CPU budget that advertising does, and that cost already shows up in your responsiveness scores.

The takeaway

Four numbers, free, public, measured from real users, for effectively every site with meaningful traffic. They do not tell you whether your ad was seen, and they come with no official thresholds, so anyone selling them as a viewability replacement is overreaching. What they do is convert the oldest unanswerable question in open-web buying — is this a real page or an ad farm with text on it? — into something you can look up before the next invoice. Pull your top 50 placements by spend, band them, cross them against conversion rate, and the answer sits in the intersection. In most accounts that intersection is short — a handful of domains — and it rarely contains only the ones whose names already looked suspicious.