No, and this is a meaningful distinction, not a pedantic one. The Chrome UX Report (CrUX) is, by its own documented methodology, a Chrome-only dataset. It collects real-user performance data exclusively from people using the Chrome browser who have opted into usage statistics reporting and meet Google’s specific inclusion criteria. Safari users, Firefox users, and every other non-Chrome browser are entirely absent from the dataset, regardless of how much mobile traffic those browsers represent in a given market. Calling CrUX “all mobile users” data overstates what it actually measures.
The mechanism: how CrUX’s Chrome-only sample is built
Google’s official CrUX documentation is explicit about the collection methodology: data comes from Chrome users who have opted into the “Usage Statistics” setting (or the equivalent sync/reporting setting depending on Chrome version and platform) and who meet a set of eligibility conditions designed to protect user privacy and ensure representative sampling. Sessions in Incognito mode are excluded. Users without sync or usage-statistics reporting enabled are excluded. The dataset is also anonymized and aggregated with privacy thresholds in mind, meaning even within the Chrome-using population, very-low-traffic URLs may not have sufficient samples to appear in CrUX at all.
None of that methodology touches non-Chrome browsers at any point, because there’s no mechanism for it to. CrUX isn’t a general web-analytics crawl of “all mobile traffic” from every source; it’s specifically Chrome’s own built-in telemetry, made available as a public dataset. A Safari user on an iPhone, no matter how many times they visit a given site, contributes zero data points to that site’s CrUX record, because Safari has no participation in Chrome’s usage-statistics reporting pipeline. The same is true for Firefox, Samsung Internet users not running on Chromium with reporting enabled, and any other non-Chrome mobile browsing.
Why this is still broadly useful despite the gap
Google uses CrUX as a core input for Core Web Vitals field data, which factors into page experience assessment for ranking purposes. This makes sense as a practical choice given that Chrome represents the largest single browser by usage share in most global markets and across most device categories, meaning CrUX’s sample, while not literally universal, is broadly representative of general web traffic patterns for the majority of sites operating in markets and audiences where Chrome dominates. Since exact market-share figures fluctuate by region, device type, and time period, and shift enough that any specific percentage cited here would likely be stale by the time it’s read, the honest framing is qualitative: Chrome holds a majority share in most markets, which is why CrUX functions as a reasonably representative proxy for “typical” web performance experience in aggregate, even though it is not, and does not claim to be, comprehensive of every browser.
Where the gap actually matters: non-Chrome-dominant audiences
The blind spot becomes practically significant for sites whose actual audience skews heavily away from Chrome. The clearest example is any property with a strongly iOS-dominant user base in markets or demographics where iPhone users disproportionately stick with Safari as their default browser rather than installing Chrome. For such a site, CrUX field data, and by extension the Core Web Vitals assessment Google’s ranking systems draw from that data, may not reflect what a large share of the site’s actual real-world visitors are experiencing at all, since those Safari sessions were never counted.
This has a direct practical consequence: a site optimizing purely by watching its CrUX/Core Web Vitals dashboard could believe its mobile performance is solid while a substantial, uncounted portion of its actual mobile audience (Safari users) is having a meaningfully different, possibly worse, experience that never shows up anywhere in that data.
The opt-in layer adds a second, subtler gap
Beyond the browser restriction, it’s worth understanding that CrUX isn’t even capturing every Chrome session, it’s specifically capturing Chrome sessions from users who have the relevant usage-statistics/sync reporting setting enabled, and who aren’t browsing in a mode (like Incognito) explicitly excluded from data collection. This means the dataset isn’t just “Chrome users” but “Chrome users who opted into telemetry sharing and are in a standard, non-private browsing session,” a narrower slice still. There’s no strong reason to believe this opted-in population behaves systematically differently from the broader Chrome population in terms of page-load performance specifically, but it’s a second, compounding layer of sampling worth being aware of when treating CrUX as representative of “Chrome users” as a whole, let alone all mobile users.
Why this matters more for some industries than others
The size of the practical gap between CrUX’s Chrome-only sample and a site’s actual full audience varies enormously by vertical and region. A site whose analytics show a roughly even split between Chrome and Safari mobile traffic has a materially different CrUX-representativeness situation than a site whose mobile audience is overwhelmingly Android/Chrome to begin with, common in some regions and demographics where Chrome’s mobile share is dominant enough that the non-Chrome gap is a rounding error rather than a meaningful blind spot. E-commerce, media, and consumer-facing sites with a heavily iOS-skewing user base (certain premium or design-conscious verticals, for instance, anecdotally trend iOS-heavy, though this varies by specific audience and shouldn’t be assumed without checking) are the category most likely to have their CrUX data meaningfully understate whatever performance problems exist for the Safari-using share of their actual visitors.
Practical implication
Don’t treat CrUX or Core Web Vitals field data as a complete performance picture, especially for sites with known non-Chrome-heavy audiences. Supplement it with real-user monitoring (RUM) tooling that captures performance data across all browsers actually used by the site’s visitors, not just Chrome, and cross-reference analytics browser-share data for the specific site to gauge how large the CrUX blind spot actually is for that particular audience. For a site whose analytics show Safari as a dominant browser, CrUX-based Core Web Vitals data should be treated as a partial, Chrome-specific signal, useful and ranking-relevant, but not a substitute for browser-agnostic performance monitoring of the site’s actual full user base. Where RUM tooling isn’t feasible, even a periodic manual check of load performance in Safari on actual iOS hardware, rather than relying solely on Chrome DevTools device emulation, closes part of the gap qualitatively even without a full quantitative monitoring solution in place.
