Google Is Now Publishing Your Ad Density For Anyone To See: CrUX Added 4 Ad Experience Metrics

Hi everyone, this is Neo.

On September 15, the Chrome team did something that will quietly rattle both SEO and adtech circles: it shipped four brand-new ad experience metrics inside CrUX, the Chrome User Experience Report.

If you run an independent site, you already know CrUX — it’s the source of the “field data” in PageSpeed Insights, and the dataset Google uses to evaluate Core Web Vitals. Now that same dataset has a new dimension: ads.

Neo’s position up front: this will not affect your rankings in the short term, and Google has explicitly said it’s not part of Core Web Vitals. But this may be the first time ad experience has a global, browser-native, publicly queryable measurement standard. The long-term consequences are much bigger than the launch suggests.

Let me break it down.

What Google actually added

Four metrics, all labeled experimental:

Metric Official definition Plain language
Ad Count Average number of ads in the viewport How many ads a visitor sees at once
Ad Density Average fraction of viewport area occupied by ads How much of the screen ads take up
Ad Weight: CPU Cumulative CPU execution time of ad frames and workers (ms) How much computing power ads consume
Ad Weight: Network Cumulative compressed bytes transferred by ad frames and resources (KB) How much bandwidth ads consume

Together they cover three different things: quantity, visual footprint, and resource cost.

Eight details you have to get right, or you’ll misread the data

This part matters more than the news itself, because misread the methodology and you’ll draw the opposite conclusion.

1. Everything is reported at P75, not the average

Chrome reports the 75th percentile. That means: 75% of user sessions experienced that value or better.

The official example is clear. If a site’s Ad Density p75 is 23%, then 75% of visits had ads occupying 23% or less of the viewport, while the remaining 25% were higher.

Why not an average? Because averages get dragged around by outliers — one user on a slow train connection can wreck a mean. P75 describes a distribution, not a typical experience.

2. Ad Weight: CPU covers ad frames only — not main-frame ad scripts

This is the easiest trap to fall into. The documentation is explicit: CPU time is measured for ad frames only and excludes CPU time for main frame ad scripts.

So if you’ve injected an ad, affiliate, or recommendation script directly into your main document, that cost may not show up in ad_cpu at all. A low number there doesn’t mean you’re clean.

3. The viewport is sampled once per second

For Ad Count and Ad Density, Chrome samples the viewport once per second and takes a snapshot. An ad counts as visible if any single pixel of it sits inside the viewport at that sample point.

  • Overlapping ads: for Density, the overlapping area is counted once, using the union of ad areas. For Count, each ad counts separately;
  • Partial visibility: Density measures only the portion physically inside the viewport. Count includes an ad if at least one pixel is in view;
  • Non-rendering ads (think display: none) are excluded from Count and Density — but their CPU and network weight is still measured.

That last one is worth memorizing: hiding an ad slot isn’t optimization. The resources get spent either way.

4. SPA soft navigations don’t reset the measurement window

If your site is a single-page app, client-side route changes do not reset collection. Every soft-navigated view gets averaged into one cumulative session score until a hard navigation or tab closure.

5. Background tabs pause collection

Switching tabs or locking the screen pauses telemetry, and it resumes when the tab returns to the foreground. Picture-in-picture video is ignored so background runtime doesn’t skew the numbers.

6. A 28-day rolling window, updated daily

CrUX uses a 28-day rolling average, capturing how real users experience the site across devices and network conditions. The API updates daily; the History API publishes weekly on Mondays and returns the last 40 rolling 28-day periods — roughly six months of time series.

7. Which platforms feed the data

Chrome on Windows, macOS, Android, ChromeOS, and Linux. Chrome on iOS is excluded, along with Android WebView embedded apps and other Chromium-based browsers.

This matters for your judgment: if most of your traffic is iOS, this data is not telling your story.

8. Only sites with a compliant ads.txt get published (the big one)

CrUX ad metrics are only reported publicly for eligible origins: sites that have an ads.txt file containing at least one authorized seller record.

Two consequences:

  1. No ads.txt, or a placeholder-only ads.txt, means you don’t appear in the public CrUX ad data. Expect a wave of people searching their own domain on CrUX Vis this week and finding nothing — this is almost certainly why;
  2. The DevTools Ad panel will still show local measurements for your own pages even if you’re not eligible for public aggregates.

How to check your own numbers

Three channels, and I’d start with the easiest.

Step one: local, zero setup. Open Chrome DevTools and find the Ad panel. You’ll immediately see measurements for the current page. Use this to confirm exactly what Chrome is classifying as an ad.

Step two: CrUX Vis for trends. The official dashboard needs no code at all. It plots the last 40 weeks of rolling trends, supports origin-level and URL-level switching, filters by device, and updates every Monday. This is the painless option for anyone non-technical.

Step three: the CrUX API. If you want ad metrics in monitoring or alerting, the queryRecord endpoint returns all four p75 values in a single request:

curl -s -X POST \
  --header "Content-Type: application/json" \
  --data '{
    "origin": "https://example.com",
    "metrics": [
      "experimental_ad_density",
      "experimental_ad_count",
      "experimental_ad_cpu",
      "experimental_ad_kilobytes"
    ]
  }' \
  "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=[YOUR_API_KEY]"

The response looks like this (Google’s own example):

{
  "record": {
    "key": { "origin": "https://example.com" },
    "metrics": {
      "experimental_ad_count": { "percentiles": { "p75": "3.00" } },
      "experimental_ad_density": { "percentiles": { "p75": 23 } },
      "experimental_ad_cpu": { "percentiles": { "p75": 1093 } },
      "experimental_ad_kilobytes": { "percentiles": { "p75": 33 } }
    }
  }
}

Translated: in 75% of sessions, no more than 3 ads in the viewport, ads covering no more than 23% of the screen, no more than 1,093 ms of ad CPU time, and no more than 33 KB of ad network transfer.

To query page-level instead of origin-level, swap the origin field for url. Leave metrics empty and the API returns everything.

Google also says it’s working on adding these to the CrUX dataset on BigQuery, which would enable SQL analysis at scale. Once that lands, expect third-party tools to pile in — the same thing happened with Core Web Vitals.

What Google said, and what it carefully didn’t say

This part reveals the posture, so it’s worth reading closely.

What Google said:

  • The four metrics share CrUX’s pipeline and eligibility criteria, but they are not part of Core Web Vitals;
  • There is no “Good / Needs improvement / Poor” grading and no suggested thresholds. Chrome group product manager Alex Cone told reporters there are “no plans” to set benchmarks;
  • Everything is labeled experimental, with an open call for feedback and possible changes to the definitions;
  • Google’s DV360 supports the initiative, but DV360 and Google Ads will not get preferential access to the CrUX data;
  • Early ecosystem supporters include The Guardian, Mediavine, Index Exchange, and Adelaide.

What Google didn’t say but you should notice:

  • Will ecosystem players actually use this data in media buying decisions? Google declined to speak for partners, saying only that early conversations showed appetite;
  • Could this become a search quality signal? Google didn’t say yes. It also didn’t say no.

Alex Cone’s framing was refreshingly honest: the metrics are there so Google can “better understand if they are valuable for making decisions,” and it looks forward to ecosystem feedback.

Neo’s take: translated, that reads as — we’ve built the ruler, we haven’t decided how to use it. Which is exactly the part to watch. A public ruler eventually gets used to measure people.

Neo’s take: why this isn’t just about rankings

If all you care about is rankings, you can shelve this until next year. I think three angles matter more.

Angle one: the line between search quality and ad quality is thinning

CrUX started life as a performance dataset and is the foundation of Core Web Vitals. Now ad experience lives inside the same dataset. That doesn’t mean ad metrics become a ranking factor tomorrow. It means Google is using one real-user measurement pipeline to measure the broader idea of “page quality.”

Remember how Core Web Vitals evolved: introduced in 2019, first as guidance, then as a ranking signal, then iterated (INP replacing FID). It also started as “experimental, no thresholds.”

Angle two: ad experience now has a browser-native, globally comparable standard

Until now, “this page has too many ads” was measured by each ad network’s own tooling, each exchange’s own policy, and human judgment. Now the browser computes it for you — one definition, publicly queryable, by origin and by page.

For the buy side, that’s a massive negotiating tool. For the sell side — media and content sites — it’s an audit report you may not have been ready to have published.

Angle three: the impact on independent sites splits in two, and you shouldn’t confuse them

Category one: content sites monetized with AdSense or affiliate ads.

This is the directly affected group. “Ad density” used to be a fuzzy idea. Now it’s a public p75 number. Even if Google never sets a threshold, advertisers, affiliate networks, and agencies can absolutely apply their own.

Category two: e-commerce independent sites that primarily sell products.

On the surface the exposure is small — few in-page ad slots. But watch two things:

  1. Third-party promo slots, affiliate modules, and AI recommendation widgets can also be classified as ads by Chrome’s detection logic, and they’ll be counted the same way;
  2. Ad Weight: CPU and Network are real performance costs. If your INP is being dragged down by ad or recommendation components, then even though this metric isn’t a ranking factor, its sibling Core Web Vitals is.

Four things to do now

Don’t wait for Google to define thresholds. All four of these pay off whether you do them today or next year.

1. Confirm you’re even eligible

Check the ads.txt file at your site root:

  • Does the file exist?
  • Does it contain at least one authorized seller record, rather than just a placeholder comment?

Fix it if not. This isn’t about rankings — it’s about being able to see your own numbers at all. Without it you can’t even establish a baseline.

2. Build your own baseline

Record these four numbers from the CrUX API or CrUX Vis:

What to record Why it matters
Ad Count p75 Whether you have too many slots above the fold
Ad Density p75 How ad-heavy the page feels visually
Ad Weight: CPU p75 Ad impact on interactivity
Ad Weight: Network p75 The real cost for mobile and poor connections

Always split by device. Mobile p75 and desktop p75 often differ by an order of magnitude, and most of your traffic is usually mobile.

3. Optimize for cost, not just placement

“Only one slot above the fold” is still a good habit, but it isn’t enough. The new lens is resource cost:

  • Lazy-load ad scripts — at minimum, defer them until after the first screen renders;
  • Clean up idle and duplicate slots. Especially the ones left over from A/B tests that no longer serve. Idle slots are often pure waste;
  • Cap concurrent ad requests, or stagger and consolidate auctions;
  • Audit affiliate and recommendation widgets. They’re usually heavier than standard ad slots and less under your control.

4. Put ad metrics and Core Web Vitals on the same dashboard

This is the highest-value step in my view. Chart your current CWV data next to these four ad metrics and you’ll likely see a strong correlation — ad-dense pages usually have worse INP.

Once you see that correlation, prioritization solves itself. You’re not chasing an experimental metric with no thresholds. You’re fixing the thing you already know affects rankings.

Wrapping up

I genuinely like one choice the CrUX team made here: they shipped the ruler without shipping a score.

No Good / Needs improvement / Poor categories. No thresholds. Labeled experimental, waiting on ecosystem feedback. That’s far more restrained than defining a standard on day one.

But restraint isn’t the same as irrelevance for independent site owners, because of where this data sits: the same dataset as Core Web Vitals, fed by the same real-user pipeline, with a deliberately parallel name — Ad Weight.

When a dataset’s sibling is a ranking factor, that dataset eventually gets discussed as a ranking factor.

You don’t need to panic about that. You just need to know what your ad experience looks like right now — so that if it ever does become a metric, that audit report isn’t the first time you’ve seen it.

One last thing: if you search your domain on CrUX Vis and find no ad data, don’t blame Google immediately. Go check your ads.txt first.