News: On September 15, 2026, Alex Cone of the Chrome team announced on the Chrome for Developers blog that four ad metrics have been added to the Chrome UX Report: Ad Count, Ad Density, Ad Weight (Network) and Ad Weight (CPU). They are available today through the CrUX API and the CrUX History API (Chrome for Developers, September 15, 2026).
"We've all encountered overwhelming ad experiences on the web. We know them when we see them, but they're hard to quantify," Alex Cone writes in the opening line of his post. That is precisely what Chrome has just changed. Not by creating a ranking factor: by making public, site by site, a number nobody published until now.
What Chrome actually measures
The four metrics describe ad load as a real user experiences it, not as a lab tool simulates it. Chrome's documentation defines them as follows: Ad Count is the average number of ads in the viewport; Ad Density, the average fraction of that viewport's area occupied by ad frames; Ad Weight (Network), the resources consumed by ads measured in bytes; Ad Weight (CPU), those same resources measured in milliseconds of compute.
The last two matter most to anyone doing technical SEO. They isolate what ad frames consume on the user's device, separately from the rest of the page. Field tooling did not draw that line before.
What Google says, and above all what it does not
The post is unambiguous on one point: "CrUX ad metrics are not part of Core Web Vitals and don't have suggested targets or thresholds." They are inspired by them, they follow the same eligibility criteria as existing Web Vitals, but they are not folded into the LCP / INP / CLS trio. So there is, as of today, no announced good or bad score.
That silence is itself information. It means any claim along the lines of "ad density above X% hurts rankings" is invention: Google has published neither a threshold nor a link to ranking. PPC Land reported the same day that data is returned at the 75th percentile, that a Chrome DevTools Ad panel also exposes it, and that BigQuery availability is in progress with no date announced.
Do you know what Chrome already measures on your site?
We query your CrUX field data, cross-check it against your real Core Web Vitals and your visibility in AI answers, and tell you what is costing you positions.
Why this is an SEO story anyway
Three reasons, none of which is "it's a ranking factor".
The first is mechanical. Ad Weight (CPU) counts milliseconds of main-thread work consumed by third-party frames. INP, meanwhile, is a Core Web Vital, and it measures the responsiveness of that same thread. The two numbers are not linked by a Google rule; they are linked by browser physics. If your INP degrades while your own code has not changed, you now have a figure to name the culprit instead of suspecting it.
The second is strategic. This data is public and queryable by origin. Your competitors, your advertisers, your partners and any journalist can look up your ad load without asking your permission. Glenn Gabe, quoted by Search Engine Roundtable, puts the urgency bluntly: "Every site owner running ads (especially a lot of ads) should run this TODAY." Better to know your own number before a third party quotes it.
The third touches AI visibility. A page whose rendering is weighed down by third-party frames is a more expensive page for anything that visits it, engines and bots included. We are not claiming these metrics influence citations in answer engines: nothing demonstrates that. But the direction matches what we already observe about AI bot access to websites and about the real cost of automated crawling: consumed resource is becoming a variable people measure, and therefore trade off.
What to do this week
- Get your number. Query the CrUX API for your origin and record the four values. That is one request, not a project. Without a dated starting point, you will not know in three months whether things improved or got worse.
- Cross-check against your INP. If your INP is poor and your Ad Weight (CPU) is high, stop optimising your own JavaScript first: the cost sits elsewhere, and you finally have something to show whoever owns monetisation.
- Look at mobile separately. Ad Density is computed against the visible viewport. On a phone screen, a sticky banner occupies a share of the surface nothing like what it takes on desktop. That is where the gaps open up.
- Put it under watch. The CrUX History API lets you track the trend. An ad-load regression rarely lands on the day of a product release: it lands on the day somebody adds a placement without telling the engineering team.
The limits of what we know
They are real and worth stating. With no thresholds published, you will get a number without knowing whether it is good: the only useful reading today is comparative, over time or against equivalent sites. Eligibility follows that of existing Web Vitals, which implies sufficient Chrome traffic: many small-business sites will simply not appear in the dataset, and a missing figure is not a good figure. PPC Land additionally mentions an eligibility condition tied to declaring at least one authorised seller in the ads.txt file; we did not find it in the official post, so we report it as second-hand and unconfirmed by Chrome. Finally, these metrics describe advertising, not experience quality: a site light on ads can still be unpleasant for other reasons.
We checked every definition and every quote in this article against the official September 15, 2026 post and Chrome's CrUX documentation, and we flag explicitly the single item we could not find there. On a topic where the temptation to announce a new ranking factor runs high, we would rather publish what the source says, and nothing beyond it.
The Cicero take
Google threatened nobody. It did something more effective: it put a number on an irritation everyone felt without being able to name it. The history of Core Web Vitals followed exactly this path — first "purely informational" metrics, then a shared vocabulary, then a decision criterion. We are not predicting that these four will become a ranking signal, and nobody should. We simply note that a public measurement never goes back in the box: from today, your site's ad load is a verifiable fact, and ignoring it is a choice, not an excuse.
Sources
- → Chrome for Developers, September 15, 2026: primary source. Post by Alex Cone announcing the four CrUX ad metrics, their availability in the CrUX API and CrUX History API, the opening quote, and the explicit statement that these metrics "are not part of Core Web Vitals and don't have suggested targets or thresholds".
- → Chrome for Developers — CrUX methodology, metrics: official documentation. Definitions of Ad Count, Ad Density, Ad Weight (CPU) and Ad Weight (Network) quoted verbatim in this article.
- → PPC Land, September 15, 2026: independent report, used for the 75th percentile, the Chrome DevTools Ad panel, the "in progress" BigQuery availability and the
ads.txtcondition (not confirmed by the official post). - → Search Engine Roundtable, September 15, 2026: independent report, source of the Glenn Gabe quote and cross-check of the four-metric list and their availability through CrUX Vis.
Frequently asked questions
Are CrUX ad metrics a Google ranking factor?
No, and Chrome says so explicitly. The post published on September 15, 2026 states that "CrUX ad metrics are not part of Core Web Vitals and don't have suggested targets or thresholds". They are described as inspired by Core Web Vitals, not folded into them. Any claim that a high ad density directly lowers your position is, as of today, backed by no statement from Google.
How do I look these metrics up for my site?
They are exposed through the CrUX API and the CrUX History API, both named in the September 15, 2026 announcement. PPC Land reported the same day that an Ad panel in Chrome DevTools also surfaces them, and that BigQuery availability is in progress with no date given. As with every other CrUX metric, this is aggregated field data: a site without enough Chrome traffic simply will not appear in the dataset.
What exactly does Ad Density measure?
Chrome's documentation defines it as the average fraction of the visible viewport area occupied by ad frames, measured as the user scrolls. So it is not a ratio computed against the full document height, but against what the person actually sees on screen at a given moment. A sticky banner that follows the scroll therefore weighs far more than a single unit seen once.
My site runs no ads at all: does this concern me?
Directly, no: with no ad frames, there is nothing to measure. Indirectly, yes, on two counts. First, your monetised competitors become comparable to each other and to you on a public data point. Second, the logic being measured — how much of a user's device a third-party element consumes — applies to any third-party script embedded in your pages, ad network or not.
Growth and SEO & GEO content strategist, I founded Cicero to help businesses build lasting organic visibility: on Google and in AI-generated answers alike. Every piece of content we produce is designed to convert, not just to exist.
LinkedIn →