--- title: "Blog" description: "Read about the background of our monitoring solution, new features and case studies" canonical: "https://www.rumvision.com/blog/google-launches-crux-ad-metrics-already-live-in-rumvision/" --- Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > Blog # Google launches CrUX ad metrics: already live in RUMvision Google launches four brand-new experimental ad metrics in CrUX. How long does it take before they show up in RUMvision? Well... not that long 😉 The new data is available through Google's CrUX APIs, and we added support to both our free CrUX tooling and competitor comparison pretty much straight away. ## What are CrUX ad metrics? The Chrome User Experience Report, better known as CrUX, has traditionally been associated with metrics such as [Largest Contentful Paint](https://www.rumvision.com/blog/how-to-fix-largest-contentful-paint/?format=md), [Interaction to Next Paint](https://www.rumvision.com/blog/interaction-to-next-paint/?format=md) and C[umulative Layout Shift](https://www.rumvision.com/blog/cumulative-layout-shift/?format=md). Google has now expanded that dataset with measurements [focused specifically on advertising](https://developer.chrome.com/blog/crux-ad-metrics). That means CrUX can provide public, aggregated field data not only about loading speed, responsiveness and visual stability, but also about the advertising experience on eligible websites. ### The four new ad metrics The first release contains four experimental measurements: - **Ad Count** the number of distinct ad units visible in the user's viewport while the page is in the foreground. - **Ad Density** the percentage of the user's viewport occupied by ad content while the page is in the foreground. - **Ad Weight: Network** the amount of network data fetched for ad-related resources. - **Ad Weight: CPU** the amount of CPU time consumed by ad frames. For publishers in particular, that adds a completely new type of public field data. Instead of inspecting one page load and counting ads manually, you can start putting a site's ad footprint into a much broader real-world context. ### Real-user data from Chrome This is where CrUX makes the new metrics especially interesting. This isn't a one-off Lighthouse run from one computer, on one connection, at one moment in time. CrUX is based on aggregated experiences from real Chrome users. And measuring advertising consistently across the web isn't exactly easy. Ads can be loaded dynamically, live inside third-party iframes, refresh during a visit, execute their own JavaScript and fetch additional resources long after the initial page load. Chrome is in a particularly interesting position here. The browser itself can observe activity that regular JavaScript running inside a webpage cannot necessarily inspect. There is one important limitation though. These metrics are not intended to identify every possible advertisement on the internet. The current implementation focuses on eligible sites using third-party advertising, rather than trying to classify every possible first-party promotion as an ad. #### How to interpret the 75th percentile Just like many other CrUX metrics, the new ad metrics are reported at the [75th percentile](https://www.rumvision.com/help-center/glossary/dashboarding/75th-percentile/?format=md). That means the reported value isn't an average across all page views. If Ad Density is reported as 21%, for example, the 75th percentile sits at 21%. In practical terms, roughly three quarters of the qualifying page views had an ad density at or below 21%, while the most ad-heavy quarter was around 21% or higher. In other words, P75 gives you a useful view of the heavier end of the ad experience: not the worst individual page view, but a value that a meaningful share of real users experienced. ### What about visitors using an ad blocker? This question came up almost immediately after Google's announcement. If a page view doesn't contain ads, for example because a visitor is using an ad blocker, that page view isn't included in the reported ad measurements. So imagine that 75% of visitors to a very technical website use an ad blocker. Those users may see zero ads, but that doesn't mean the reported Ad Count or Ad Density automatically becomes extremely low. Instead, the CrUX ad metrics describe the qualifying page views where ads were actually present. That's an important distinction when interpreting the data. ## Why this data is different One of the most interesting aspects of the new CrUX ad metrics is that some of this information simply isn't available to normal Real User Monitoring implementations. That makes this more than just four additional numbers in an API response. ### What Chrome can measure that RUM cannot Traditional RUM tooling runs JavaScript inside the webpage. That means it can only observe information that browsers deliberately expose through web APIs. Chrome itself operates at a much lower level. It knows about frames, resource loading, execution inside the browser and which elements have been classified as advertising. **Ad Weight: CPU is a particularly good example.** Chrome can observe how much CPU time is being consumed by ad frames and aggregate those measurements into CrUX. A regular RUM script cannot currently ask the browser: > "How much CPU time did this specific advertisement, script or cross-origin frame consume?" There simply isn't a standard browser API today that gives in-page JavaScript the same level of CPU attribution that Chrome can use internally. So while RUMvision can retrieve and visualize the resulting CrUX metric, this isn't something we, or another regular RUM vendor, could independently reproduce with a few lines of client-side JavaScript. ### Why CPU attribution is difficult Could browsers expose more CPU attribution in the future? Potentially. A future browser API could perhaps expose more coarse-grained information, for example CPU usage associated with a browsing context or iframe. But detailed attribution becomes complicated very quickly. Imagine if JavaScript on one website could accurately inspect how much CPU time a cross-origin script or iframe was consuming. Information like that could potentially reveal things about activity happening across security boundaries. That means privacy and security considerations are likely to limit how detailed such an API could ever become. For now, browser-level datasets such as CrUX are therefore in a unique position to expose aggregated measurements like Ad Weight: CPU without having to expose the same low-level information directly to every webpage. ### These are not Core Web Vitals Another important distinction: these are **experimental ad metrics**. They are not new Core Web Vitals and Google hasn't published "good", "moderate" or "poor" thresholds for them. So an Ad Density of X% or an Ad Weight: CPU value of Y milliseconds isn't automatically good or bad. For now, the data is much more useful for understanding your own ad footprint, observing changes and comparing those values with other websites. ## How to use CrUX ad metrics New data is fun. New data that you can actually put into context is considerably more useful. ### Compare ad usage across websites And obviously, once Google makes public data like this available, we can't resist putting it to use. Our competitor comparison now includes an **Ad usage** view alongside the existing UX score and Core Web Vitals metrics. You can compare multiple websites side by side using the same four CrUX ad measurements: - How many ads are visible? - How much of the viewport is occupied by ads? - How much network traffic is associated with advertising? - How much CPU time is consumed by ad frames? For publishers, that provides useful external context. Instead of only knowing how advertising is implemented on your own website, you can compare your ad footprint with other publishers or competitors in the same space. Curious how different types of websites compare? We’ve lined up a few examples from different niches [in our free competitor comparison tool](https://www.rumvision.com/tools/core-web-vitals-compare-competitors/www.forbes.com/?path=%2F&sort=ad_usage&domains=www.ebay.com%2Cwww.forbes.com%2Cwww.espn.com%2Cwww.imdb.com%2Cweather.com). ### What the data can and cannot tell you There is an important caveat here. CrUX doesn't publish a direct correlation between its ad metrics and Core Web Vitals. If one website has a high Ad Weight: CPU value and a poor INP, you cannot automatically conclude from CrUX that advertising caused that INP result. Likewise, a website with high Ad Density might still have excellent Core Web Vitals. At the time of writing, [Forbes.com is a good example](https://www.rumvision.com/tools/core-web-vitals-history/www.forbes.com/?path=%2F). The datasets give you additional context, not proof of causality. That still makes comparisons useful. If one publisher's ad footprint looks very different from others in the same market, that's something worth investigating. But the CrUX ad metrics themselves shouldn't be treated as a root-cause analysis. ### Where to find the metrics Google has made the experimental ad metrics available through [both the CrUX API and the CrUX History API](https://developer.chrome.com/docs/ads/tooling). as well as their own CrUX visualization tool. In RUMvision, you don't need to enable anything. When CrUX reports ad data for the website you're checking, an **Ad usage** section automatically appears in the report. We also include a viewport illustration based on **Ad Count** and **Ad Density**, so you can quickly see what that level of ad coverage could look like in practice. [![crux-history-api-ad-usage-data.png](https://www.rumvision.com/file/upload/img/blog/crux-history-api-ad-usage-data.png)](https://www.rumvision.com/file/upload/img/blog/crux-history-api-ad-usage-data.png)When using our competitor comparison, you can switch from UX score to Ad usage and compare those same metrics across multiple websites. [Check CrUX ad metrics for a website ](https://www.rumvision.com/tools/core-web-vitals-history/?format=md) ## RUMvision support from day one This part feels a little familiar. When Google launched the CrUX History API, [we had historic CrUX data running in our free tooling almost immediately](https://www.rumvision.com/blog/proud-announcement-a-new-free-tool-for-visualize-historic-data-your-website-performance/?format=md "Throwback to Proud announcement: a new free tool to visualize historic website performance"). Back then we joked about the API being roughly 34 hours old before it was already available in RUMvision. This time we may have beaten ourselves. ### First third-party support We started implementing the new CrUX ad metrics as soon as Google made them available. Pretty much straight away. Barry Pollard from the Chrome team even commented publicly on our announcement: > "I think you guys won as the first third-party tool to support! 👏" > > Barry Pollard on LinkedIn So yes, being an early adopter is something we're pretty proud of. Especially when it means useful new Chrome data becomes accessible to website owners without them having to start writing CrUX API queries themselves. ### Why we adopt CrUX changes early For us, implementing new CrUX data quickly isn't really about winning a race. Well, maybe a little bit. But it's mostly useful because field data can answer questions that previously required assumptions, manual investigation or custom testing. And CrUX keeps becoming more than just a Core Web Vitals dataset. Over time we've gained information about device distributions, navigation types, network characteristics, LCP resources and other aspects of real-world browsing. Advertising is now another layer. Our job is to turn that raw browser data into something understandable and actionable. If Google ships useful field data today, we'd rather start exploring what people can do with it today than wait six months before adding another chart. After all, we do the same with [new APIs and Origin Trials](https://www.rumvision.com/blog/how-rumvision-leads-the-way-in-real-user-monitoring/?format=md). ### Conclusion Google's new CrUX ad metrics add a very different perspective to public real-user data. Publishers can now use CrUX to inspect and compare ad count, viewport density, network usage and CPU usage using aggregated Chrome field data. They're experimental. There are no recommended thresholds. They're not Core Web Vitals. And they don't prove that advertising caused a particular performance result. But they do provide a type of insight that is technically difficult, and in some cases currently impossible, for normal RUM JavaScript to collect independently. That alone makes this a very interesting addition to CrUX. And yes: they're already live in RUMvision. [Check out the new CrUX ad metrics ](https://www.rumvision.com/tools/core-web-vitals-history/?format=md)