Chrome today added four experimental advertising measurements to the Chrome User Experience Report, a public dataset built from real browsing sessions, making the number of ads on screen, the share of the screen they cover, and the processing time and data they consume visible for eligible websites that declare an authorized seller.

In Short

Google's Chrome browser now publishes four numbers about the ads on websites: how many are on screen, how much of the screen they fill, and how much computing power and data they use. Anyone buying or selling ads can look these numbers up for a site, so a heavy ad experience is no longer something you only notice while reading a page. Google calls the numbers experimental and attaches no pass or fail score to them, which means for now they describe sites rather than grade them.

Four numbers from the browser

The release arrived through a Chrome for Developers blog post by Alex Cone and a new set of documentation pages written by Kevin K. Lee, all carrying today's publication stamp. According to the blog post, the metrics are designed to describe the ad load of websites as real users encounter it. The post opens with a concession rather than a claim: "We've all encountered overwhelming ad experiences on the web. We know them when we see them, but they're hard to quantify."

Four dimensions are covered. Ad Count is the average number of ads in the viewport. Ad Density is the average fraction of the viewport occupied by ads. Ad Weight: Network records the bytes consumed by ad resources, and Ad Weight: CPU records the milliseconds of processing they consume. Each documentation page carries a banner describing the set as experimental metrics that "may evolve based on user feedback."

Barry Pollard, a Web Performance Developer Advocate on Google Chrome, summarised the release in a LinkedIn post. His description of the network metric is slightly narrower than the documentation's, referring to kilobytes fetched "by ad scripts and frames." He also set out why Chrome, rather than a third party, is publishing the data: "It's difficult to measure these types of metrics given technical constrains (sic) on the web platform, so CrUX is in a unique position to publish this data."

That position matters. CrUX, according to Chrome's overview documentation, is a dataset reflecting how real-world Chrome users experience popular destinations on the web, and it already feeds Google Search's page experience ranking factor. Adding advertising to the same pipeline turns something previously measured by vendors, auditors and individual publishers into a browser-sourced public record.

How each metric is calculated

The four documentation pages share a structure, and the formulas are published in full.

Ad Count

Ad Count relies on viewport sampling across the life of a page visit. According to the documentation, Chrome counts ads once per second, averages the number of distinct elements visible in the viewport, "for example, frames or images," and reports the figure when the user navigates away. The value carries two decimal places and is formatted as a string in the CrUX API. The worked example is simple. A page showing 2 ads for 5 seconds, followed by 5 seconds with no ads after the user scrolls, produces a session value of 1.00.

That averaging has a consequence worth noting. Seconds spent reading ad-free sections pull the figure down, so a page that stacks several units at the top and none further down can report a modest count even if its opening screen is crowded.

Ad Density

Ad Density is also sampled each second. Chrome divides the total bounding box area of visible ads by the total viewport area and averages those ratios across the session. The result is an integer percentage, where 50 represents 50%, and like Ad Count it arrives as a string in the API. The documentation's example mirrors the Ad Count case: 50% of the viewport showing ads for 5 seconds, then 0% for 5 seconds, yields a session density of 25.

The two measurements are related but not interchangeable. A single large unit can raise density without moving the count, while several small units can do the opposite.

Ad Weight: CPU

Ad Weight: CPU sums all JavaScript CPU thread execution time, in milliseconds, consumed by ad frames and their subresources over the page visit. It is reported as an integer. A highlighted note in the documentation limits the scope: "The CPU time is measured for ad frames only and excludes CPU time for main frame ad scripts."

The exclusion is significant. Code running in the publisher's own top-level document sits outside the figure, and on many sites that document hosts the header bidding wrapper and the ad server library that decide which ad appears. The metric therefore captures what happens inside the ad containers, not the full processing cost of monetisation on a page.

Ad Weight: Network

Ad Weight: Network totals the compressed wire bytes transferred to load all ad-related resources, "such as scripts, images, and stylesheets," according to the documentation. It is reported in kilobytes as an integer rounded to the nearest kilobyte. The blog post describes the same metric as resources "measured in bytes," which is consistent with the calculation but not with the reporting unit, and anyone reading the two side by side will find both. Unlike the CPU page, the network page contains no exclusion for main frame resources.

The network page also carries a template error. Its section on browser-side collection is headed "Collecting Ad Density through JavaScript," although the text below concerns the network metric. None of the four pages supplied for this article explains how Chrome decides which resources and frames count as ads; the documentation navigation lists separate Detection and Methodology pages that were not part of the material reviewed.

The ads.txt gate and the 75th percentile

Eligibility is narrower than for the rest of CrUX. According to all four metric pages, only pages with ads are considered, and "Pages and origins without at least one authorized seller defined in ads.txt file won't have ad metrics data in CrUX." The data is available at URL and origin level, subject to the standard CrUX eligibility criteria, which according to the overview documentation require that pages be publicly discoverable and draw enough visitors to produce a statistically significant dataset. Pollard's post frames the population as sites with third-party ads.

Tying inclusion to ads.txt is a practical choice. The file, published at the root of a domain, lists the companies permitted to sell its inventory. A site that sells ads only through direct deals, without declaring any seller, would fall outside the dataset. The standard itself is under pressure: PPC Land reported in April 2026 that Brian O'Kelley argued ads.txt lacks the vocabulary to describe modern selling relationships, proposing adagents.json as a replacement. Chrome has, for now, anchored its measurement to the older file.

CrUX aggregates the session values across eligible Chrome users and publishes the 75th percentile. For metrics where a higher value means more advertising, that figure marks the point at or below which three quarters of measured page views fall. It is the same statistic CrUX uses for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, and according to the blog post the ad metrics are reported on the same dimensions and follow the same eligibility criteria as the existing Web Vitals.

Not Core Web Vitals, and no thresholds

Chrome drew a firm boundary around how the numbers are to be read. According to the blog post, "CrUX ad metrics are not part of Core Web Vitals and don't have suggested targets or thresholds." There is no good, needs improvement or poor band of the kind CrUX Vis displays for loading, interactivity and visual stability.

The documents are silent on any link to Google Search. The CrUX overview states that CrUX data informs the page experience ranking factor, but none of the ad metric pages says whether the new fields will play any role there, and the blog post does not raise the question. Ranking use cannot be inferred from the material either way.

Thresholds already exist elsewhere, set by other bodies and enforced by Chrome itself. The Coalition for Better Adsstandards, which Chrome has enforced by filtering ads on non-compliant sites since February 2018, treat mobile ad density above 30% as an unacceptable experience. Resource consumption has its own mechanism. PPC Land's record dates the Heavy Ad Intervention to Chrome 84, with Chrome unloading heavy ads since July 14, 2020 on desktop and Android, while a July 2021 report described a project to unload ads consuming excessive resources as still under consideration; the two dates have not been reconciled in that coverage. Google also released Publisher Ads Audits, a Lighthouse plugin measuring ad speed and layout shift caused by ads. What the new metrics add is not a rule but a population view: aggregated field data instead of a pass or fail check on one site or one creative.

Why cross-origin frames forced a browser-side approach

Each metric page contains the same explanation for why site owners cannot reproduce the figures with their own scripts. Most ads are delivered through cross-origin iframes, which creates reporting difficulties, and "Therefore, there is no JavaScript API to allow similar detection for Real User Monitoring (RUM) tooling." The same barrier is familiar from viewability measurement, where cross-domain frames can prevent tools from capturing position data and leave impressions logged as not measurable.

The result is an asymmetry. A publisher can instrument its own pages for loading and responsiveness, but for ad density and ad weight the reference figure now comes from the browser vendor, with no equivalent field data collected on the publisher's side.

Access runs through three channels today, according to the documentation: the CrUX API, the CrUX History API and the Ad panel in Chrome DevTools. Chrome says it is working on adding the metrics to the CrUX dataset on BigQuery so they can be queried with SQL. The general CrUX metrics page, updated today, adds an "Ad metrics" section and notes that experimental metrics are available in BigQuery and the API, "though not all metrics are available in both," which fits the current state of the advertising fields. The blog post also states that data availability is expected to increase over the coming month, so early readings cover fewer sites and shorter histories than they eventually will.

Who the numbers are for

Chrome's stated audience is the buy side. According to the blog post, the metrics are expected to be "particularly useful for web advertisers and the services they use to place ads," and Chrome says a large cross-section of ad ecosystem stakeholders told it the data "could enhance how they value ad opportunities and make ad product decisions." The CrUX metrics page repeats the point, describing public metrics and tooling for sites "and others, like advertisers."

The blog includes an "Ecosystem support" carousel with six slides, of which only one was visible in the material reviewed. It quotes Sara Badler, Chief Advertising Officer, North America at The Guardian: "This is a great step forward for the ecosystem. As a publisher focused on independent, quality journalism, we want to be valued for the experiences we build, and these metrics provide a clear, objective ground truth to support that." The remaining five endorsements could not be read from the capture.

The commercial context explains the interest. Ad density is already a classification input for buyers trying to avoid low-quality supply. IAB Australia's 2024 guidance defined made-for-advertising sites partly by high ad density, and IAS measured a made-for-advertising rate of 2.0% on mobile web display during 2025, four times the desktop rate. IAS sells ad clutter avoidance segments built on ad-to-content ratios and refresh behaviour. Those classifications come from verification vendors with their own models; the CrUX figures come from real Chrome sessions and are free to query.

Whether that improves buyer decisions is an open matter. Work by TAG, the ANA and Fiducia found that AI-generated inventory was graded premium more than 70% of the time, outscoring clean supply on the very metrics verification reports. A density figure is a different kind of signal, harder to game by producing viewable, fraud-free impressions, though a 75th percentile at origin level can still mask how individual pages behave.

Publishers face the other side of the ledger. Google has spent 2026 reshaping how its own publisher products control density: it replaced the AdSense ad load slider with numerical settings for maximum ad count and minimum spacing, effective April 16, and in March AdSense emailed publishers promoting performance work framed around Core Web Vitals and revenue. The same company that sells the ads, runs the dominant browser and operates Ad Manager is now also publishing the measurement of how heavy those ads are. The documents make no reference to that overlap.

What the data shows for ppc.land

PPC Land sells display inventory programmatically, and CrUX Vis captures of the ppc.land origin on phones were part of the material reviewed. The figures below are read from charts rather than exported values, so they are approximate. Disclosure: this publication is the site being measured.

The ad metric series covers seven collection periods, ending with the window from August 16 to September 12, 2026, while the Core Web Vitals series on the same screens reaches back to the window from November 16 to December 13, 2025. Over those seven periods, the 75th percentile Ad Count rose from about 0.29 to about 0.43. Ad Density held between roughly 20% and 22%, ending at about 22%. Ad Weight: CPU climbed from about 760 milliseconds to roughly 1,370 milliseconds, and Ad Weight: Network from about 820 kilobytes to around 2,010 kilobytes, close to a 2.5-fold increase.

Several things follow from those readings. An Ad Count below one at the 75th percentile, alongside a density above a fifth of the screen, fits the averaging rule described above: sessions include many seconds with no ad in view, while the units that do appear occupy a meaningful share of a phone display. The density sits below the 30% mobile line used in the Better Ads Standards, though Chrome does not apply that line to the new metric.

The upward movement in both weight measures has no explanation in the supplied documents. Changes in demand, creative formats and the number of sessions captured could each contribute, and Chrome's own warning that coverage will expand over the coming month means a seven-point history is too short to separate them.

The Core Web Vitals picture on the same origin looks different. CrUX Vis summarised loading performance as good and improving, and interactivity and visual stability as good and stable, as of September 12, 2026. The latest readings sit near 1,500 milliseconds for Largest Contentful Paint, around 180 milliseconds for Interaction to Next Paint and close to 0.02 for Cumulative Layout Shift. The earliest window tells another story: layout shift near 0.5, interaction delay above 300 milliseconds and loading close to 2,900 milliseconds, during a period when the phone share of navigations jumped from around 40% to nearly 90% before falling back. The current phone share is roughly 38%, with desktop near 62%.

Taken together, good Core Web Vitals and a roughly two-megabyte ad payload at the 75th percentile coexist in one dataset. That is precisely the gap Chrome's separation of the two metric families is meant to expose.

Open questions

Several matters remain unaddressed by the published material. The detection logic that labels a frame or resource as advertising sits in documentation pages not reviewed here. There are no thresholds, and Chrome has not said whether it intends to set any. BigQuery availability has no date. The relationship between the new fields and any Google product, from Search to Ad Manager, is not described. Feedback, according to every metric page, goes to the Chrome UX Report Google Group, and the experimental label means definitions can still change.

What is settled is narrower but concrete. As of today, for any site selling through declared sellers and drawing enough Chrome traffic, the amount of screen given to ads and the bytes and processing time those ads consume are measurable by anyone with access to the CrUX API.

Timeline

Summary

Who: Google Chrome, through a blog post by Alex Cone, documentation by Kevin K. Lee and a LinkedIn post by Web Performance Developer Advocate Barry Pollard. The data concerns publishers with at least one authorized seller in ads.txt, and Chrome names advertisers and the services placing their ads as the main intended users. The Guardian's Sara Badler is quoted in support.

What: Four experimental metrics added to the Chrome User Experience Report: Ad Count, Ad Density, Ad Weight: CPU and Ad Weight: Network, each reported at the 75th percentile of page views at URL and origin level, with no thresholds and no Core Web Vitals status. CPU time excludes main frame ad scripts, and no JavaScript API exists for independent collection.

When: Today, September 15, 2026. The metrics are available now in the CrUX API, the CrUX History API and the DevTools Ad panel, with BigQuery support in progress and data coverage expected to grow over the coming month.

Where: Chrome sessions from eligible users worldwide, published through CrUX tooling including CrUX Vis, where ppc.land's own phone data shows ad weight rising to roughly 2,010 kilobytes and 1,370 milliseconds over seven collection periods.

Why: Chrome says overwhelming ad experiences are easy to recognise but hard to quantify, and that cross-origin iframes prevent site-side measurement. Publishing browser-derived figures gives buyers a free signal on ad load and resource cost, at a time when ad density already shapes made-for-advertising classifications and quality metrics have been shown to reward low-value supply.