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).
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.
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.
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.
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.
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.