Google adds four experimental ad metrics to the Chrome User Experience Report

Google has added four experimental ad metrics to the Chrome User Experience Report: Ad Count, Ad Density, Ad Weight (Network Usage) and Ad Weight (CPU Usage). Search Engine Roundtable reported the addition on 15 September 2026. The metrics are live in the CrUX API and the CrUX History API today, and they can be viewed for sites carrying third-party ads in CrUX Vis. Because CrUX is a public dataset, these numbers are readable for any qualifying site, including sites you do not own.

Barry Pollard of Google described them on Bluesky as "a set of ad-related measurements that provide transparency into sites' ad experiences," and called them experimental for now. Alex Cone of Google wrote that Google "expects these metrics to be particularly useful for web advertisers and the services they use to place ads." Digiday covered the same launch under the heading of an ad detection tool for assessing ad experiences in Chrome.

What the four metrics actually measure

Each metric is narrow and literal, which is the useful part. None of them is a score, a grade or a composite index, so there is nothing to interpret beyond the definition.

Two of those are about how much of the page a visitor sees taken up by advertising, and two are about what the advertising costs the device to run. The split matters. A page can be visually restrained and still hand the browser a heavy ad payload, and a page can be light on bytes while filling half the screen with ad slots. Ad Count and Ad Density describe the experience a person sees. The two Ad Weight metrics describe the load a phone has to carry.

The CPU figure is the one worth dwelling on, because it is measured in milliseconds of processing rather than kilobytes transferred. On a mid-range Android handset, which is the device most Thai visitors are actually holding, CPU time is usually the bottleneck long before bandwidth is. A metric expressed in milliseconds says something about responsiveness that a byte count does not.

Where the data lives and how to get at it

Search Engine Roundtable reports three access points, all available now. The CrUX API returns the metrics for a queried origin or URL. The CrUX History API returns them over time, which is what turns a single reading into a trend. CrUX Vis is the visual front end, and the metrics show there for sites that carry third-party ads.

The history endpoint is the one that will matter in three months. A single Ad Density figure is a number without a reference point, since there is no published benchmark for what good looks like, and Google did not supply one. A trend line for the same site is self-referencing, and it answers the question a publisher actually has: did the ad experience get heavier after the last tag change, or did it not.

Because CrUX draws on real Chrome users rather than a lab test, coverage depends on a site having enough traffic to meet the dataset's reporting threshold. Smaller Thai sites that already fail to appear in CrUX for Core Web Vitals will not suddenly appear for ad metrics.

Experimental means exactly what it says

Barry Pollard called these metrics experimental, and the reporting itself was uneven on day one. Search Engine Roundtable's Barry Schwartz noted that the ad metrics were not reporting for him on select sites, and illustrated the post with a reading taken on the New York Times site instead. That is worth repeating before anyone builds a dashboard on top of the API: a site returning nothing today is not necessarily a site with no ads.

Experimental also means the definitions can move. A metric that changes how it counts an ad slot changes every historical comparison built on it. Anyone pulling this into a monthly report should record the date the series started and expect to re-baseline at least once.

What the announcement did not say

Several questions a publisher would ask are not answered in the source material, and inventing answers to them would be worse than leaving them open.

Google did not say these metrics are a ranking signal, and nothing in the reporting connects them to search rankings. They also do not appear as part of Core Web Vitals. Google published no threshold for a good or poor Ad Density, no guidance on an acceptable Ad Count, and no target for either Ad Weight figure. There is no stated timeline for the metrics leaving experimental status, no statement on whether they will be added to CrUX's regular reporting cadence, and no explanation of why some sites were not reporting data on launch day. Google also did not say how an ad is defined for counting purposes, which matters for sites running native units, sponsored content blocks or self-served house ads.

The commentary around the launch reflected that ambiguity rather than resolving it. Glenn Gabe wrote on X that "every site owner running ads (especially a lot of ads) should run this TODAY," which is advice to go and look, not a claim about consequences.

Who this is aimed at

Alex Cone's framing puts web advertisers and the ad services they use at the centre of it, which is a different audience from the one CrUX usually serves. CrUX has been an SEO and performance dataset for years. Ad metrics point it at the monetisation side of the same page.

Three groups get something concrete out of it. Publishers get a way to see what their own ad stack does to a real device, measured on real visitors rather than in a throttled lab run. Advertisers and media buyers get a public read on the environments their ads appear in, which until now has depended on whatever the seller chose to disclose. Ad technology vendors get a shared yardstick, since the same four numbers are computed the same way for everyone.

The public nature of CrUX is the part most teams will underrate. You can query a competitor's origin. If a rival publisher in your category runs four ad units above the fold and you run two, that gap is now a number either of you can cite in a conversation about rate cards or user experience.

What to check in your own reporting

None of this changes a ranking or a bid, so the work here is measurement rather than remediation.

• Query your own origin through the CrUX API and record the four values with today's date. That first reading is the baseline everything later is compared against.
• Open CrUX Vis for the same origin and confirm the metrics render. If they return nothing, note it and try again in a few weeks rather than concluding your ad load is zero.
• Pull the same four metrics through the CrUX History API for the longest window it returns, so you can see whether recent tag or layout changes moved anything.
• Run the query against two or three competitors in your category. Comparative context is the only benchmark available, because Google published none.
• Look at Ad Weight (CPU Usage) next to your existing Interaction to Next Paint data. Both are measured in milliseconds on real users, and a page with a heavy CPU ad load and poor responsiveness is a page with a plausible explanation for the second number.
• Write down which date the series began. These are experimental metrics and the definitions may change under you.

If page experience work is already part of your organic programme, this belongs in the same review rather than a separate one. A technical SEO audit is the natural place to fold the four readings in, and teams reporting on real-user performance can line them up against the data already collected in GA4.

How this sits next to Core Web Vitals

CrUX is the dataset behind Core Web Vitals, so it is easy to assume anything added to CrUX is a ranking input. That assumption is not supported by anything in the reporting. Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint are Core Web Vitals. Ad Count, Ad Density and the two Ad Weight metrics are, on the current information, diagnostic data sitting in the same dataset.

The honest connection is indirect. Ads have always been one of the most common causes of poor Core Web Vitals scores, through late-loading slots that shift layout and through scripts that occupy the main thread. What these metrics add is the ability to quantify the ad side directly instead of inferring it from a poor Cumulative Layout Shift figure and a hunch about which script caused it.

What this means for Thai marketers

Thai publisher sites tend to run heavy ad stacks, and the audience reading them is overwhelmingly on mobile. That combination is exactly what Ad Weight (CPU Usage) is built to expose, because the cost of a bloated ad stack on a mid-range Android phone in Bangkok does not show up in a desktop lab test at all.

For brands buying display or programmatic placements in Thailand, the useful shift is that the environment is now partly measurable from the outside. Before this, judging whether a Thai news site was a reasonable place for a brand's ads meant relying on the publisher's own deck. Four public numbers do not replace a media quality vendor, but they are four numbers nobody has to be given permission to see.

For e-commerce and lead-generation sites that run their own retargeting and analytics tags, the CPU metric doubles as a tag-bloat check. It counts ad resources rather than all third-party scripts, so it is not a complete picture, though on most Thai commercial sites the ad and marketing stacks overlap heavily. Teams working on SEO in Thailand already fighting mobile performance problems now have one more real-user number to put in the report.

Frequently asked questions

Are these ad metrics a Google ranking factor?

Nothing in the reporting says they are. Google described them as experimental measurements that give transparency into sites' ad experiences, and Alex Cone framed them as useful to advertisers and ad services. They are not part of Core Web Vitals and no ranking effect was stated.

Where can I see the new metrics right now?

They are available in the CrUX API and the CrUX History API today, and they can be viewed in CrUX Vis for sites that carry third-party ads. CrUX is a public dataset, so the metrics can be queried for sites you do not own.

What is a good Ad Density score?

Google has not published a threshold, so there is no official answer. Ad Density is reported as the average fraction of the viewport area occupied by ads, and the only reference points available are your own trend over time and readings taken from comparable sites.

Why is my site returning no ad metrics?

The metrics are experimental and reporting was incomplete at launch. Search Engine Roundtable noted the data was not appearing for select sites on the day of the announcement. CrUX also requires a site to have enough real Chrome traffic to meet its reporting threshold, so low-traffic sites may not appear at all.

Do these metrics cover ads I serve myself?

The source specifies that the metrics can be viewed in CrUX Vis for sites with third-party ads, and Google did not publish a definition of what counts as an ad for these measurements. Until that definition is published, treat coverage of native units, sponsored blocks and self-served house ads as unknown.

The short version for site owners

Four new numbers, public, free, updated on real Chrome users, with no benchmark attached and no stated effect on rankings. The value today is diagnostic: you can finally put a figure on how much of your viewport is advertising and how many milliseconds of phone CPU that advertising costs, for your own site and for anyone else's. Take a reading now so the trend line starts somewhere, and treat the definitions as provisional until Google moves them out of experimental status. Teams that want the ad-experience numbers read alongside their organic performance can talk to our SEO team.