Chrome reports four CrUX ad metrics: count, density, network weight and CPU weight. See what each measures, where to read yours and which ones you control.

Chrome now publishes four experimental CrUX ad metrics that describe how heavy a site’s ads feel to real visitors: Ad Count, Ad Density, Ad Weight (Network) and Ad Weight (CPU). They come from the Chrome User Experience Report, the same dataset behind Core Web Vitals. If you run ads on a WordPress site, two of the four are largely in your hands, and the other two depend mostly on what your ad partners send.

This post sticks to what Chrome has said about the metrics, links the source for each fact, and then separates what a publisher can change from what they can’t. It doesn’t promise any score, because nobody can.

What the CrUX ad metrics measure

Chrome describes the set in its announcement of the new ad metrics. The four dimensions are:

Ad Count: the average number of ads in the viewport.
Ad Density: the average fraction of the viewport area occupied by ads.
Ad Weight (Network Usage): the resources consumed by ads, measured in bytes.
Ad Weight (CPU Usage): the resources consumed by ads, measured in milliseconds.

The first two are about what a reader sees on screen. The second two are about what the ads cost the device to load and run.

Chrome’s documentation fills in the mechanics. Count and Density are sampled from the viewport once per second while the page is open, then averaged over the visit, so a page with two ads at the top that the reader scrolls past scores lower than a page that keeps ads on screen the whole way down (Ad Count, Ad Density). Network weight is the compressed bytes transferred for ad-related resources (Ad Weight: Network). CPU weight is the JavaScript execution time in ad frames, and Chrome notes it excludes main-frame ad scripts (Ad Weight: CPU).

How to read the four numbers together

The metrics make more sense in pairs than alone. Ad Count and Ad Density both describe what is on screen, so they tend to move together. Ad Weight (Network) and Ad Weight (CPU) both describe cost to the device, so they tend to move together too.

The interesting cases are the mixed ones. A page with a single large ad can have a low count and a high density. A page with several small, light units can have a higher count and a lower density. A page with one video-heavy creative can look calm on screen and heavy in network weight. Looking at all four tells you which kind of problem you have.

Where to see your own numbers

Chrome lists the places the data shows up: CrUX Vis, the CrUX API, the CrUX History API and the DevTools Ad panel, with a pointer to the Chrome ad measurements documentation for how to retrieve it. CrUX Vis is the quickest way to look: you enter a URL or origin and read the ad view.

Two eligibility points from the same docs are worth knowing before you go looking. The numbers are a 75th percentile across eligible Chrome page views, and they’re available at origin and URL level subject to the usual CrUX eligibility rules, so a small site may simply have no data. Chrome also says only pages with ads count, and that pages and origins without at least one authorized seller in an ads.txt file won’t have ad metrics. The ads.txt file is something you publish on your own domain; this plugin doesn’t manage it.

Placements that stay in view deserve special attention. Chrome samples the viewport once a second and averages over the visit, as described above. A sticky unit remains in the viewport for the whole visit, so it is present at every sample. A unit in the middle of an article is present only while the reader is passing it.

WB Ad Manager has sticky and popup placements, and so do many other tools. Those are legitimate, and they can earn well, but they weigh more in a density average than a unit that scrolls away. If you use one, keep it small and make sure there is a clear way to dismiss it, then compare the page against a version without it.

Why it matters before anyone sets a threshold

Chrome’s announcement is clear that these metrics are inspired by Core Web Vitals but are not part of them, and that they don’t have suggested targets or thresholds. Each of the four is labeled experimental, and Chrome says it’s open to feedback and to evolving them. Check the current documentation before you build a process around any single number.

So why care now? Because the announcement is equally clear about who’s expected to use the data: advertisers and the services that place ads, who told Chrome the metrics could change how they value ad opportunities. A publisher doesn’t have to act on that today, but it’s cheaper to know your own numbers first than to be surprised by someone else’s reading of them.

Common causes of a heavy ad page

When a page scores poorly on any of the four, the cause is usually one of a short list.

Too many units. The simplest cause and the simplest fix.
Auto ads on top of manual units. Google places units around the ones you chose, and the plugin’s cap does not count them.
Large creatives. A 970 x 250 unit or a half-page takes much more of the viewport than a 300 x 250.
Several partners on one slot. Each bidder adds its own scripts.
Units clustered together. Three ads within one screen’s height look dense even when the count is modest.
Ads on pages that earn little. A page nobody lands on from search can still be loaded by a lot of repeat visitors.

What a publisher controls on a WordPress page

Sort the four metrics by who holds the lever.

Ad Count and Ad Density are mostly yours. They respond directly to how many ads you put on the page and where you put them. A page with one unit after the third paragraph and one in the sidebar will average fewer ads in view than a page with a header banner, a banner above every heading and a sticky footer unit. Size matters too. A single large unit can occupy more of the viewport than two small ones.

The two weight metrics are shared. Bytes and CPU time come mostly from the creatives and scripts your ad networks and bidders deliver. You influence them by the number of units you run and by which partners you work with, but you can’t compress someone else’s JavaScript.

Setting a per-page cap in WB Ad Manager

Here’s the part the plugin can honestly help with. WB Ad Manager has a Max ads per page setting, 10 by default, which counts ads of every type the plugin renders and stops adding more once the number is reached. Pair it with deliberate placement: the plugin ships more than sixteen placement hooks, including after a paragraph you choose, so you can decide exactly where each unit lands. Our placement guide walks through them.

Be realistic about what that does. A lower cap and calmer placements reduce the number of ads a page can show, which is the thing Ad Count and Ad Density describe. It doesn’t change how heavy any single ad is, and it can’t make an ad network’s script lighter. Ads served by Google’s own auto ads are placed by Google, so they sit outside the plugin’s cap.

If you’re setting up AdSense from scratch, the AdSense setup walkthrough covers connecting the account, choosing manual units over auto ads and reserving space against layout shift.

A worked example: two layouts for one article

This is an illustration, not a result. Take a long article and imagine two layouts.

Layout A has a header banner, a unit after every second paragraph, a sidebar unit and a sticky footer unit. As a reader scrolls, almost every screen has at least one ad, and the sticky unit is present throughout.

Layout B has one unit after the third paragraph and one in the sidebar, with Max ads per page lowered so a later edit cannot add more. Most screens have no ad, and a few have one.

Nothing here predicts a number. It only shows why Layout B should read lower on Ad Count and Ad Density, and why you should check your own revenue after you change anything. If the earnings fall by more than the readers gain in return, you have found your trade-off.

What to check in your own placements

Open your five most visited pages on a phone-sized window and scroll them the way a reader would. Count the ads in view at each screen height. Look for the screens where ads take up half the display, because those are the moments a density average gets pulled up. Then look at what loads: open the browser’s network panel, filter for your ad network’s domains and note how many requests and bytes arrive before the reader has scrolled at all.

If one page template is heavy and the rest are fine, change that template and leave the others alone. The features overview lists the placement and targeting options available for that, such as showing a unit only in the countries you pick.

Settings that keep a page calm

The free plugin has a few controls that are aimed squarely at the first two metrics.

Max ads per page. The default is 10. Lower it to a number you would be comfortable with as a reader.
Disable on Post Types. Choose the post types that should never show ads.
Display rules on each ad. Limit a unit to chosen pages, post types, categories or tags.
A session limit on each ad. It caps how often one visitor sees the same ad in a browser session.
Device targeting. An ad can be limited to chosen devices, so a heavy unit can skip phones.

None of these lightens an ad network’s script. They change how many ads reach a page and where.

A monthly routine

Keep it short so you actually do it.

Look up your origin in CrUX Vis and note the ad numbers if data exists.
Open your five most visited pages on a phone-sized window and scroll them.
Count how many ads are in view at each screen height.
Check the network panel for requests to your ad partners before any scroll.
Write down what you change, then compare next month.

Questions to ask your ad partners

You cannot compress their JavaScript, but you can ask about it.

Do you offer a lighter format for the same slot?
Do you cap the number of bidders or scripts on one page?
Is there a setting that limits how large a creative may be?
Can ads be loaded only when they come near the viewport?

Treat the answers as inputs. A partner who cannot answer any of them is telling you something too. For wider context on sponsors who pay a flat fee for a fixed spot, which sidesteps the auction scripts entirely, the direct sponsor ads use case explains the model.

If your site has no data yet

Many smaller sites will find nothing in CrUX, either because too few eligible Chrome visits are recorded or because the ads.txt condition is not met. That is not a problem to fix in a hurry. The manual routine below gives you the same kind of picture, one page at a time.

Scroll your key pages on a phone-sized window and note how much of each screen the ads fill. If you can see an ad in nearly every screen, a reader can too. That is a more honest guide than a number you cannot get, and it costs nothing.

The limits of this data

Keep your claims modest. These metrics are experimental, they cover Chrome users only, and they describe typical visits rather than your best day. A lab test on your own machine can’t reproduce a 75th percentile across real visitors, and Chrome notes there’s no JavaScript API for measuring these in your own real user monitoring, because most ads are delivered through cross-origin iframes. So the CrUX data is the source, and everything else is an approximation.

Read your numbers, trim the page where it’s plainly overloaded, and revisit them when Chrome’s documentation changes.

What Chrome's Ad Metrics Mean for Publishers