CrUX Ad Metrics: Chrome’s Four New Ad Load Values

On 19 September I entered focus.de into CrUX Vis and clicked the new “Ad metrics” tab. For phones, it showed ad data of 6,241 KB per page visit at the 75th percentile. Right after that I entered seo-kreativ.de. All four charts said “unavailable”.

The difference explains a lot about the new metrics. Chrome does not capture every form of advertising with them. What is captured are ads that are recognized as advertising under the documented method. And only on sites that list sellers for their ad inventory in their ads.txt.

My news radar had listed the story on 18 September with two trade outlets. A day later it was in more than a dozen, including t3n and OnlineMarketing.de. None of the articles I read gave values for specific sites. So I retrieved the four metrics for ten German news sites, for phone and desktop. I checked every value against the raw data from Google’s API.

Here are the numbers, what they measure, where they can mislead and how you look them up for your own site. At the end comes the question the SEO world asked first: is this a ranking factor?

On 15 September 2026 the Chrome team announced four new metrics for the Chrome User Experience Report, CrUX for short, on the Chrome Developers blog. This is the same dataset the field data for Core Web Vitals comes from. The new metrics are called Ad Count, Ad Density, Ad Weight: CPU and Ad Weight: Network.

All four are labeled “experimental”. Chrome writes that it is open to feedback and may evolve the metrics. The announcement explicitly names advertisers and the services they use to place ads as the audience. It adds quotes from the ad industry, among others from WPP, The Guardian, Mediavine, Index Exchange and Google’s Display & Video 360.

One sentence from the announcement matters to anyone working with Core Web Vitals:

“CrUX ad metrics are not part of Core Web Vitals and don’t have suggested targets or thresholds.”

So there is no “good” and no “poor”. The metrics are measurements without a rating. Barry Pollard from the Chrome team introduced the launch on the same day in a thread on Bluesky. There he also writes that these values are hard to measure and that CrUX is therefore in a unique position to publish them.

The definitions are in the Chrome documentation on the ad metrics. In short:

Chrome measures count and area once per second in the visible area and averages them over the visit. For the count, one visible pixel is enough. Each ad counts on its own, even when another one covers it. For the area, an overlap counts only once. CPU and data are summed up. The measurement starts with the first byte of the HTML document and ends when the page is left, the tab is closed or the browser is terminated. On Android it also ends when the browser goes into the background. On sites that navigate without a reload, it keeps running until the tab is closed. This is described on the methodology page.

Each metric is reported at the 75th percentile over a rolling 28-day window, per origin and per URL. Chrome explains this with an example: a p75 of 23 percent for Ad Density means that 75 percent of all visits had an ad area of 23 percent or less. For the remaining 25 percent it was higher.

What is interesting is how Chrome recognizes an ad in the first place. According to the page on ad detection, the browser matches requests against a condensed version of EasyList, an open filter list against ads. It also checks whether a request was triggered by an already identified ad script. An iframe that has once been classified as an ad stays one, even if it later loads something else. The main document itself is never an ad frame.

According to the documentation on ad detection, Chrome also uses the same detection for interventions in the browser, for example to unload ads that consume excessive CPU or data.

How the ten sites were selected: The starting point was general news sites. Of these, I took the ten with the highest estimated organic Google traffic in Germany for which CrUX reports ad values. The estimate comes from my own query in the SEO tool DataForSEO on 19 September 2026. It is a third-party estimate, not an official Google figure. tagesschau.de, zdf.de, ndr.de and br.de rank far ahead there but have no ads.txt with authorized sellers and therefore no ad values. web.de also ranks ahead of some of the ten but is an email and web portal, not a general news site.

Phone

Desktop

Three things stand out. First, the range in data volume on phones. bild.de at 454 KB and focus.de at 6,241 KB are almost a factor of fourteen apart. Seven of the ten sites were between 1,900 and 2,900 KB.

Second, the desktop. There, all ten sites showed more ads at the same time than on phones. The ads also took up more area. A larger visible area can contribute to that. The cause cannot be determined from the data alone. The highest ad CPU time in this selection was focus.de with 13,745 ms per page visit on desktop.

Third, the area. On mobile, the p75 values were between 8 and 16 percent of the visible area, on desktop between 13 and 26 percent.

While comparing against the raw data, I noticed something that was not in any report I had read. The Ad Count values are not arbitrary. The 20 values in the two tables contain only eleven different numbers. Where two of them are neighbors, the gap is around 15 percent: 1.54 · 1.77 · 2.03 · 2.33 · 2.68.

In practice this means: two sites at 2.03 are not necessarily the same. And a site at 2.33 is one step above one at 2.03, nothing more can be read from that. The documentation pages on the ad metrics do not explain why the values come in steps. I therefore do not read small differences in Ad Count as a difference.

The second point concerns CPU and data. Both are summed over the whole page visit. A page where users stay long and ads reload ends up with higher values than an equally heavy page that people leave after ten seconds. A high value can therefore also come from long visits.

The third point is in the documentation on the CPU metric:

“The CPU time is measured for ad frames only and excludes CPU time for main frame ad scripts.”

Only what runs in ad frames is counted. Ad scripts that work directly in the main document are missing from Ad Weight: CPU. Harry Roberts points out in his column on CSS Wizardry that this share can be substantial. Namely on sites whose ad tags run early in the document and create the ad frames later. A site that controls its ads more from the main document can therefore show lower CPU time than a comparable site with more ad frames.

Then there are the limits of detection. Whatever is not on the filter list and does not come from a recognized ad script is not captured as an ad. And Chrome on iOS is missing altogether. For a site with many iPhone readers, the values describe only part of the audience.

The rule is on the methodology page. CrUX reports the ad metrics only for sites whose ads.txt lists at least one authorized seller. If the file is missing or contains only a placeholder, the site stays out. The general inclusion criteria of the Chrome UX Report also apply, such as a minimum number of visitors. The ads.txt is the file publishers use to publicly declare who is allowed to sell their ad inventory.

On seo-kreativ.de, /ads.txt returns a 404. The pages also load no ad scripts from Google or other networks. I checked this in the source code of the homepage and two articles on 19 September 2026.

There is advertising here anyway. Since August, five English articles have contained paid placements, labeled “Paid placement”. They are text blocks directly in the article, without an iframe and without an ad script. Under the documented detection method, they would probably not be captured as ads even with an ads.txt, because the main document is never an ad frame.

That is the limit of the new metrics. They mainly describe ads delivered through ad networks and their technology. Directly sold placements in the text, affiliate links or advertorials are advertising, but under the documented rules they are probably not captured by these metrics. Individual resources in the main document can still be classified as ad-related by Chrome.

According to Chrome’s tooling page there are three ways. BigQuery is to follow later. For this article I used CrUX Vis, because it runs in the browser without any setup.

1. CrUX Vis: Open cruxvis.withgoogle.com, enter your origin and choose “Ad metrics” on the left. At the top you can switch between phone and desktop. Each metric is its own chart with the trend over the last weeks. For the sites in my selection, the data goes back to the window 5 July to 1 August 2026, before the announcement. For the numbers in this article, go back to the window 16 August to 12 September 2026 in the chart. Because the window rolls on, the current state shows different values.
2. CrUX API and CrUX History API: The metric keys are experimental_ad_count, experimental_ad_density, experimental_ad_cpu and experimental_ad_kilobytes. You need an API key from the Google Cloud Console.
3. DevTools: The Ads panel measures locally on your machine. According to the methodology page, it shows the values even on pages without an ads.txt. These measurements only end up in CrUX if the ads.txt lists authorized sellers.

How to use DevTools for a complete audit as well is described in my article on the Lighthouse audit with Chrome DevTools MCP.

The first question in the SEO world was predictable: does a page with fewer ads rank better? The announcement, the related methodology and Barry Pollard’s thread do not describe any use of these four metrics as a Google Search signal. Chrome talks about transparency for advertisers and publishers. In my view, the metrics should therefore not be treated as a ranking factor as long as Google says nothing else.

What Google says about Search is elsewhere. The Search Central page on page experience contains a list of self-assessment questions. One of them reads:

“Does your content avoid using an excessive amount of ads that distract from or interfere with the main content?”

On the same page Google writes: “Core Web Vitals are used by our ranking systems.” The ad metrics are not mentioned there. The question about too many ads is a self-assessment without a measured value.

The indirect route is still real. Ad scripts need CPU time and data. Chrome itself writes that this can affect a page’s performance. Whether that shows up in your INP or LCP is something you see in Core Web Vitals, not in the ad metrics. How to measure and improve the three metrics is in my guide to Core Web Vitals. Why third-party scripts can slow down rendering is explained in my article on JavaScript SEO and rendering.

For publishers there is a second reason to keep an eye on the values. They are public. Ad buyers can look them up for every covered site. Chrome writes that this is exactly what they are meant for. What that means for prices and bookings cannot be said today.

Which signals actually feed into ranking as of today and which are only assumed is summarized in my article on Google ranking factors.

For ten large German news sites the values are now out in the open. On phones, the ad data per page visit ranged from 454 KB to 6,241 KB.

In my view, the metrics are above all a tool for publishers and ad buyers. For SEO they are a hint where a look at Core Web Vitals is worthwhile. Nothing more. Anyone using them for comparisons should know the steps in Ad Count and keep in mind that CPU and data are summed over the whole visit. Visits with Chrome on iOS are missing entirely.

Sources

Chrome for Developers: New ad metrics in Chrome User Experience Report of 15 September 2026 (announcement, own statement by Chrome) · CrUX ad metrics overview · Methodology · Ad detection · Ad Weight: CPU · Tooling · CrUX methodology and license, all retrieved on 19 September 2026.

Barry Pollard (Chrome team): thread on Bluesky of 15 September 2026. Google Search Central: Understanding page experience in Google Search results, last updated 10 December 2025. Harry Roberts: Web-Perf Wednesday 009 of 16 September 2026.

Data source: Google Chrome User Experience Report (CrUX), experimental ad metrics, retrieved via CrUX Vis on 19 September 2026, origin level, 75th percentile, window 16 August to 12 September 2026. CrUX datasets by Google are licensed under CC BY 4.0. Selection of origins and presentation: Christian Ott. Selection criterion: estimated organic Google traffic in Germany according to DataForSEO, retrieved on 19 September 2026.