Google quietly gave itself four new ways to measure ad clutter. On 22 September it folded CrUX ad metrics, ad count, ad density, and two ad weight readings, into its official Page Experience documentation. None of it touches your ranking. All of it hands you a number for something you used to have to guess at: how much a page's ad stack actually costs the person loading it.
What did Google actually change with CrUX ad metrics?#
Chrome's developer team shipped four experimental fields into the Chrome User Experience Report on 15 September 2026.
- Ad Count: average number of ads visible in the viewport
- Ad Density: average share of the viewport that ads occupy
- Ad Weight (network): ad-related data transferred, in bytes
- Ad Weight (CPU): ad-related processing time, in milliseconds
A week later, on 22 September, Google added all four to its "Understanding Page Experience" help document, in a new "Page experience resources" section. Google's John Mueller was direct about what that placement means: "We included them because they're available as metrics to help evaluate the state of your site. Not everything is a direct search ranking factor." That's about as plain as Google gets on this.
Does this affect your site?#
If you run a lean service site with no display ads and a light pixel setup, this changes nothing for you. Close the tab.
If you're sending Meta ad traffic into landing pages that also carry a retargeting pixel, a chat widget, a reviews script, and a heatmap tool stacked on top of each other, this is the first Google-native way to put a real figure on what that combination does once it hits a visitor's phone. Ad-supported publishers and marketplaces with third-party ad units are the obvious audience. D2C brands running paid traffic into busy landing pages are a less obvious one, and probably the more useful one to think about here.
The honest tradeoffs#
The upside is real. You can now separate "ad and tracking weight" from "your own page weight" using Google's own measurement, rather than eyeballing a waterfall chart and guessing which script is the culprit.
The catch is real too. These four fields are labelled experimental, with no suggested targets and no pass or fail line. I wouldn't build a client scorecard around them yet. CrUX also only reports on pages with enough real Chrome traffic behind them, so a low-traffic landing page gets no data at all. That's exactly the kind of page most likely to be overloaded with unnecessary scripts in the first place. The signal is real. The coverage isn't complete.
How we're handling it#
My first reaction, honestly, was that this was too niche to bother writing up. Four experimental fields, no thresholds, buried in a docs update. Then we actually ran it against a client landing page and it turned out to be a genuinely fast way to answer a question clients ask constantly: is the ad tech or the actual content slowing this page down.
At WebEpex we pulled the new ad-metric fields into the same CrUX queries we already run for client Core Web Vitals checks, the day this documentation update showed up in our SEO monitoring feed. DevAegis, our own SaaS dashboard running on a self-hosted Next.js 14 stack behind PM2 and Nginx, carries no third-party ad tags at all, so its numbers came back flat. Useful as a zero-baseline, though it told us nothing new.
Where it actually earns its keep is on client landing pages built to absorb paid traffic. Retargeting pixels, WhatsApp click-to-chat widgets, and review-platform scripts all sit in the same request waterfall as the real content. There's now a documented way to isolate their share of it. We've added ad count and ad weight to the same monthly ad performance reviews we already run for clients, rather than treating four experimental fields as a new metric to chase for its own sake. My read: this gets genuinely useful once Google publishes thresholds. Until then, it stays a diagnostic tool, held at arm's length from anything client-facing.
What I'd tell a client this week#
Open Chrome DevTools or whatever page-speed audit tool you already use, and count how many third-party ad or tracking scripts actually fire on your top landing page, not your homepage. Under three, and none of them a display ad network? Do nothing. This update isn't for you yet. Five or more, especially a mix of retargeting pixels and a display network? That's worth an hour of cleanup before your next ad spend review. Pulling one heavy script is usually cheaper than the drop-off it's quietly causing.
None of this is urgent. It's a once-a-quarter check, not a fire drill. If you want a second pair of eyes on what your own landing pages are actually carrying, send me the URL and I'll tell you straight. Takes two minutes, no pitch attached. cal.com/webepex/growth-review