Introduction
On September 15, 2026, Chrome's team quietly added four new numbers to a dataset that already shapes how millions of websites think about speed. The Chrome for Developers announcement introduced four experimental ad-load metrics to the Chrome User Experience Report — better known as CrUX. For the first time, there's a public, field-collected way to measure how ad-heavy a web page actually feels to real visitors.
Here's the part that matters for anyone running a business website: CrUX is public data. Because it reports on real Chrome traffic, these ad metrics are queryable for sites you don't own — which means you can benchmark how cluttered and resource-hungry a competitor's site is, not just your own. That's genuinely new.
But there's a lot of hype waiting to attach itself to this, so we're going to be careful. These metrics are not a ranking factor, they are not part of Core Web Vitals, and Google has published no targets or thresholds. This is a diagnostic and transparency tool, not a scorecard you'll be graded on. Let's walk through exactly what changed, how to read it, and what a small business should actually do with it.
Key Takeaways
- Chrome added four experimental ad metrics to CrUX on September 15, 2026: Ad Count, Ad Density, Ad Weight (Network), and Ad Weight (CPU).
- The data is reported at the 75th percentile of page views — the same statistic used for Largest Contentful Paint, INP, and CLS.
- These are not ranking signals and not Core Web Vitals; Chrome says there are no plans to set performance thresholds.
- Because CrUX is public, you can query the ad load of any eligible site — including competitors — through the CrUX API and Chrome DevTools.
- Eligibility is tied to declaring at least one authorized seller in an ads.txt file, so many small-business sites won't appear at all.
- Site owners can't fully replicate the numbers themselves, which makes Chrome's figure the reference point.
What Chrome Added to CrUX
CrUX is Google's record of real-world performance data, collected anonymously from Chrome users who opt in. It's the same field dataset behind the Core Web Vitals you see in Search Console and PageSpeed Insights. Until now, it measured loading, responsiveness, and visual stability. The September update adds a new category: how ads affect the experience.
There are four metrics, and Chrome's documentation defines them plainly:
| Metric | What it measures | Unit |
|---|---|---|
| Ad Count | The average number of ads in the viewport | Count (two decimals) |
| Ad Density | The average fraction of the viewport area occupied by ads | Percentage |
| Ad Weight: Network | The resources consumed by ads | Kilobytes |
| Ad Weight: CPU | The processing time consumed by ads | Milliseconds |
A couple of technical details are worth knowing before you read too much into any single figure. According to PPC Land's breakdown, Ad Count and Ad Density are sampled roughly once per second across a page visit and then averaged, so a sticky sidebar unit counts differently than an ad that flashes by during a fast scroll. The CPU figure captures JavaScript thread time for ad frames and their subresources — but it specifically excludes CPU time spent by ad scripts running in the main frame, which means the true processing cost of ads is likely higher than the number suggests.
Chrome describes these metrics as reported “on the same dimensions and following the same eligibility criteria as our existing Web Vitals.” In practice that means they show up alongside the loading and stability metrics you may already track when you audit a site's Core Web Vitals and page speed.
Why It Matters If It's Not a Ranking Factor
This is the question that separates a useful read of the news from a panicked one. So let's be direct about the limits.
Chrome's documentation states that “CrUX ad metrics are not part of Core Web Vitals and don't have suggested targets or thresholds.” In its coverage, AdExchanger reported that Alex Cone, a group product manager at Chrome, confirmed the metrics are experimental, that Chrome is gathering community input through a Google Group, and that there are currently “no plans” to establish performance benchmarks the way Core Web Vitals has clear pass/fail targets. Cone also said the metrics rely on Chrome's existing measurement methodology rather than any new data collection.
So what is the point? Three things.
First, transparency. Ad-cluttered pages are a known frustration for users, but until now there was no objective, field-based way to quantify how heavy a page's ad load really is. These metrics give publishers, advertisers, and the wider industry a shared vocabulary. AdExchanger noted that organizations including WPP, The Guardian, Mediavine, Index Exchange, and Adelaide were cited favorably in Chrome's announcement.
Second, diagnostics. If your site monetizes with display ads, you now have a way to see the aggregate cost your visitors are paying — in screen space, bandwidth, and processor time — that you couldn't easily measure before. That connects directly to the rendering and script-weight problems we've written about in our guide to how JavaScript-heavy sites lose rankings, where third-party code is often the hidden culprit.
Third — and this is the one that carries some weight for competitive strategy — neutrality signaling. Cone told AdExchanger that Google's own demand-side platform, DV360, and Google Ads “won't have preferential access” to the data. As Shopifreaks summarized from Digiday's reporting, outside ad platforms will get the data when Google's own ad businesses do. That framing lands in the middle of Google's ongoing ad-tech antitrust proceedings, which is part of why the “no preferential access” language is being watched closely.
The honest takeaway: don't restructure your site over these numbers, and don't let anyone sell you an “ad-load optimization” package promising ranking gains. There's no ranking mechanism here today. What you have is a new lens — a good one — for understanding user experience.
How to Check Any Site's Ad Load — Including a Competitor's
This is where CrUX ad metrics get genuinely interesting for a small business doing a competitive audit. Because CrUX is public field data, you're not limited to your own properties.
The CrUX API gives programmatic access to real-user experience data at both the page and origin level. You send a JSON request with either an origin (which aggregates every page under a domain) or a specific url, optionally filtered by device type, and it returns the metrics as histograms and 75th-percentile values. It runs on a free Google Cloud API key and a 28-day rolling average. There's no ownership check — if a site is publicly discoverable and gets enough Chrome traffic, its field data is queryable. That's the same mechanism that makes CrUX useful for the kind of rival-by-rival teardown we described in our Fort Wayne AI competitor analysis playbook.
PPC Land notes the ad metrics are currently available through the CrUX API, the CrUX History API, and a dedicated Ad panel in Chrome DevTools, with BigQuery access planned but not yet dated. If you're not comfortable writing API requests, the DevTools panel is the friendliest starting point.
Two important eligibility and accuracy caveats, though:
- The ads.txt gate. PPC Land reports that “pages and origins without at least one authorized seller defined in [an] ads.txt file won't have ad metrics data in CrUX.” Most small-business brochure and service sites don't run programmatic display inventory and don't publish an ads.txt file, so they simply won't have ad-metric data. This tool is aimed at monetized publishers, not every website.
- The measurement asymmetry. Because ads load inside cross-origin iframes, site owners can't fully reproduce these figures themselves — PPC Land points out there's “no JavaScript API to allow similar detection for Real User Monitoring (RUM) tooling.” That's a meaningful shift: the browser's number becomes the authoritative reference, and you can't easily argue with it using your own analytics. If you already wrestle with the gaps between platforms, our look at privacy-first analytics and GA4 alternatives covers why field data and your own measurement rarely line up perfectly.
What the Early Numbers Tell Us
It's tempting to want a “good” and “bad” number for each metric. There isn't one — Chrome hasn't published thresholds, and we're not going to invent them.
What we do have is one illustrative reading. PPC Land tracked the metrics across seven collection periods ending between August 16 and September 12, 2026, and reported approximate values it read directly from CrUX charts (its own caveat: these are “read from charts rather than exported values, so they are approximate”). Over that window:
| Metric | Early reading | Later reading |
|---|---|---|
| Ad Count | ~0.29 | ~0.43 |
| Ad Density | ~20% | ~22% |
| Ad Weight: CPU | ~760 ms | ~1,370 ms |
| Ad Weight: Network | ~820 KB | ~2,010 KB |
Treat those as a single publication's snapshot, not a benchmark. The network figure roughly doubling and the CPU figure climbing toward 1,370 ms is an interesting directional data point about where ad weight was trending on the sites PPC Land observed — nothing more. It is not a Google-published target, and it does not mean your site should aim for any of those figures.
One structural caveat that affects how you read every number: CrUX reports at the 75th percentile of page views, the same statistic Google uses to assess Core Web Vitals like LCP, INP, and CLS. A 75th-percentile figure tells you what a bad-but-not-worst-case visit looks like; it can mask real variation between a lightweight article page and an ad-saturated one on the same domain. Aggregate origin-level data smooths over exactly the pages you might most want to fix.
What You Should Actually Do
For most small businesses, the answer is refreshingly modest. Here's a practical, honest playbook.
If you don't run display ads: you're largely a spectator here, and that's fine. The metric that still matters to you is total page weight and third-party script cost — ad scripts, chat widgets, tag managers, and tracking pixels all add up. Those show up in your Core Web Vitals whether or not you have an ads.txt file. Auditing them is the same page-performance discipline worth practicing regardless of what Chrome measures.
If you do run display ads (a news site, a recipe or how-to blog, a directory, a high-traffic content property): pull your own CrUX ad metrics through DevTools or the API and watch the trend over time, not the absolute value. A rising Ad Weight: CPU figure is a signal that your monetization is quietly taxing your visitors' devices — which can undercut the very page-experience goals that keep people (and revenue) coming back.
If you're doing competitive research: this is the highest-leverage use. Query a competitor's origin and you get a rough, field-based read on how ad-heavy and resource-hungry their site is. Pair that with a broader technical audit — the kind of diagnostic work we outline in our soft 404s and traffic-collapse playbook — and you have real evidence about where a rival's user experience is weak.
In all cases: don't manufacture urgency. There's no penalty, no deadline, and no threshold to hit. And remember that a clean, fast, accessible experience is the actual goal — the same standard we hold ourselves to in our work on ADA website compliance. Ad metrics are one more instrument on the dashboard, not the destination.
What This Means for Fort Wayne and Northeast Indiana Businesses
Most Auburn, Fort Wayne, and Allen County small businesses run lean, service-focused sites with no display advertising — a plumber, a dental practice, a boutique retailer. If that's you, these ad metrics won't even register for your domain, because you likely don't publish an ads.txt file. That's not a gap to fix; it's a sign your site isn't carrying the ad-clutter tax that heavier sites are.
Two local scenarios are worth flagging, though. First, Northeast Indiana content publishers — regional news sites, DeKalb County event calendars, recipe and how-to blogs, and local directories that monetize with display ads — now have a free way to sanity-check their ad load against the page-experience goals they already care about. If your ad partner keeps adding units, the CrUX ad metrics give you an independent read on what that's costing your readers in load time and device strain.
Second, any Fort Wayne business weighing a display-ad partnership — say, a home-services company being pitched on sponsoring a local content site — can use the CrUX API to check how ad-heavy that publisher's pages already are before committing budget. And for straightforward competitive research, a DeKalb or Allen County business can benchmark a rival's site clutter as one input in a UX audit. Just keep the honest framing: these are diagnostic signals, not a scoreboard, and there are no local benchmarks to chase.
Work With a Team That Reads the Field Data Honestly
New Chrome measurements arrive constantly, and most of them get oversold within a week. At Button Block, we help Northeast Indiana businesses separate the genuinely actionable from the noise — and build sites that are fast, clean, and easy for both people and AI to use. If you want a straight answer on whether your site's performance or ad load is actually holding you back, our web development team can run a field-data-grounded audit and tell you plainly what's worth fixing and what isn't.
Frequently Asked Questions
- Are Chrome's new CrUX ad metrics a Google ranking factor?
- No. Chrome’s documentation explicitly states the ad metrics are not part of Core Web Vitals and have no suggested targets or thresholds. A Chrome product manager confirmed to AdExchanger there are currently no plans to set performance benchmarks. They are experimental, diagnostic signals — not a ranking mechanism.
- What are the four CrUX ad metrics?
- They are Ad Count (the average number of ads in the viewport), Ad Density (the average fraction of the viewport occupied by ads), Ad Weight: Network (the kilobytes of resources ads consume), and Ad Weight: CPU (the milliseconds of processing time ads consume). Chrome added them to the Chrome User Experience Report on September 15, 2026.
- Can I check a competitor's ad load with these metrics?
- Yes, if the competitor’s site is eligible. Because CrUX is public field data, the CrUX API and Chrome DevTools let you query any publicly discoverable origin or URL with enough Chrome traffic — no ownership required. The site must declare at least one authorized seller in an ads.txt file to have ad-metric data, so many small-business sites won’t appear.
- Why doesn't my website show any ad-metric data?
- Eligibility is tied to ads.txt. PPC Land reports that pages and origins without at least one authorized seller defined in an ads.txt file won’t have ad metrics in CrUX. Most brochure and service sites don’t run programmatic display inventory, so they simply have no ad-metric data — which is normal, not a problem.
- What percentile does CrUX report ad metrics at?
- CrUX reports ad metrics at the 75th percentile of page views, the same statistic used for Core Web Vitals like Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Because it’s an aggregate, it can mask variation between lightweight and ad-heavy pages on the same domain.
- Can I measure these numbers myself with my own analytics?
- Not fully. Ads load inside cross-origin iframes, and PPC Land notes there’s no JavaScript API that lets real-user-monitoring tools capture the same data. That measurement asymmetry means Chrome’s field figure becomes the reference point, and you generally can’t reproduce it independently with your own tracking.
- Do CrUX ad metrics matter for a Fort Wayne small business?
- For most Fort Wayne, Auburn, and Allen County businesses running lean service or brochure sites, the ad metrics won’t appear at all, because those sites don’t publish an ads.txt file — and that’s normal, not a problem. They matter most for two local cases: Northeast Indiana content publishers that monetize with display ads and want to sanity-check their ad load, and any local business using the CrUX API to benchmark a competitor’s site clutter as part of a UX audit.
Sources & Further Reading
- Chrome for Developers: developer.chrome.com/blog/crux-ad-metrics — New ad metrics in Chrome User Experience Report
- PPC Land: ppc.land/chrome-puts-publishers-ad-loads-on-public-record-with-4-new-metrics — Chrome puts publishers' ad loads on public record with 4 new metrics
- AdExchanger: adexchanger.com/publishers/chrome-has-a-new-way-to-measure-ad-overload-on-the-web — Chrome Has A New Way To Measure Ad Overload On The Web
- Shopifreaks: shopifreaks.com/google-adds-experimental-ad-load-metrics-to-chromes-crux-report — Google adds experimental ad-load metrics to Chrome's CrUX report
- Chrome for Developers: developer.chrome.com/docs/crux/api — Chrome UX Report API overview
- web.dev: web.dev/articles/vitals — Web Vitals