CrUX data, which feeds Google’s page experience ranking signals, captures performance from approximately 50-65% of mobile web traffic globally — the portion using Chrome on Android and Chrome on desktop. iOS Safari, Firefox, Samsung Internet, and other browsers are excluded entirely. In markets like the United States, United Kingdom, and Japan where iOS holds 40-55% mobile market share, CrUX represents barely half of mobile users. This means Google’s page experience assessment is based on a structurally biased sample that overrepresents Android Chrome users and systematically excludes the performance experience of iOS users. Understanding this bias is essential for interpreting CrUX data and making informed optimization decisions.
What CrUX Actually Collects and From Whom
CrUX (Chrome User Experience Report) collects real-user performance metrics from Chrome browser sessions where the user is logged into a Google account and has opted into usage statistics reporting. The data sources include Chrome on Android, Chrome on Windows, Chrome on macOS, and Chrome on ChromeOS. These are the only platforms and browser configurations that contribute data to the CrUX dataset.
Chrome on iOS is subject to Apple’s requirement that all iOS browsers use the WebKit rendering engine rather than their own engines. This platform constraint limits Chrome’s ability to collect the same depth of performance data on iOS as it does on Android and desktop. As documented in Google’s CrUX methodology, mobile CrUX data comes from Android devices, not iOS.
The exclusion list extends beyond Safari. Firefox (approximately 3% global mobile share), Samsung Internet (approximately 5% global mobile share), Opera, UC Browser, and all other non-Chrome browsers contribute zero data to CrUX. Microsoft Edge on mobile, despite being Chromium-based, is also excluded because CrUX collects only from Chrome itself, not from other Chromium derivatives.
The opt-in requirement further narrows the dataset. Not all Chrome users enable usage statistics syncing. Google has not published the exact opt-in rate, but estimates from industry analysts suggest that roughly 50-70% of Chrome users have this setting enabled. This means CrUX captures a subset of Chrome users, not the full Chrome population.
The resulting dataset is a specific, defined slice of web traffic: opted-in Chrome users on Android and desktop. This slice is large enough to produce statistically meaningful performance data for most origins with moderate traffic, but it is structurally unrepresentative of the total user population on any site where non-Chrome browsers carry significant traffic share.
The iOS Blind Spot and Its Impact on Optimization Prioritization
The most consequential gap in CrUX coverage is the complete absence of iOS data. In the United States, Safari holds over 50% of mobile browser market share according to StatCounter. In the United Kingdom, Australia, Canada, and Japan, iOS market share ranges from 40-55%. For sites targeting these markets, CrUX evaluates page experience based on the minority of mobile users rather than the majority.
This blind spot has practical consequences for page experience assessment accuracy. iOS devices and Android devices differ systematically in hardware profiles, network conditions, and rendering engine behavior. The WebKit rendering engine (used by all iOS browsers) handles image decoding, JavaScript execution, font rendering, and layout calculation differently from the Blink engine (used by Chrome on Android). A page that achieves 2.0-second LCP on Chrome Android may produce 3.2-second LCP on iOS Safari due to different image decoding pipelines, different fetchpriority implementation behavior, or different JavaScript JIT compilation characteristics.
When these engine-level differences produce divergent performance outcomes, CrUX reports only the Chrome side. A site could pass all CWV thresholds in CrUX while delivering poor performance to its iOS audience. Conversely, a site optimized primarily for Safari users might fail CrUX thresholds because its Chrome Android performance was deprioritized. Neither scenario is reflected in the page experience ranking signal, which relies exclusively on CrUX data.
The iOS blind spot also affects geographic analysis. CrUX BigQuery data supports country-level segmentation, but the country-level data still reflects only Chrome users in that country. In countries with high iOS adoption, the country-level CrUX data represents a smaller and less representative fraction of the actual mobile user population, making geographic performance comparisons unreliable for understanding total user experience.
Teams that optimize exclusively for CrUX metrics are optimizing for Chrome Android users. This is a rational strategy from a ranking-signal perspective because Google uses CrUX data for page experience evaluation. But from a business perspective, ignoring the experience of iOS Safari users can be costly.
Multiple industry analyses have observed that iOS users in North American and European markets tend to have higher average order values, higher conversion rates, and longer session durations compared to Android users. These behavioral differences are attributed to demographic correlations between iOS device ownership and purchasing power rather than to any inherent platform superiority. For e-commerce sites, the revenue contribution from iOS traffic often exceeds its proportion of total traffic.
A site that achieves perfect CrUX scores by optimizing exclusively for Chrome Android while neglecting Safari-specific performance issues may protect its ranking signals but lose revenue from its highest-value audience segment. The correct approach is dual-track optimization: optimize for CrUX to secure ranking signals (Chrome-specific APIs like fetchpriority, Chrome’s preload scanner behavior, V8 JavaScript engine characteristics), and separately monitor and optimize for Safari to protect business metrics (WebKit rendering behavior, JavaScriptCore performance, Safari-specific API limitations).
The dual-track approach requires cross-browser RUM data to identify where Chrome and Safari performance diverge. Without this comparison, optimization decisions are made blind to half the user base.
How to Supplement CrUX with Cross-Browser Field Data
Real User Monitoring solutions collect performance data from all browsers and provide the cross-browser visibility that CrUX cannot. Deploying a RUM tool alongside CrUX monitoring creates the complete picture needed for informed optimization decisions.
Options for cross-browser RUM include:
- Google Analytics with Web Vitals integration: the
web-vitalsJavaScript library can send CWV data to Google Analytics as custom events, captured from any browser that supports the underlying Performance APIs. As of late 2025, Safari 26.2 supports LCP and the Event Timing API (for INP), enabling cross-browser LCP and INP collection. CLS remains unsupported in Safari. - Commercial RUM platforms: SpeedCurve, DebugBear RUM, Akamai mPulse, New Relic Browser, and Sentry Performance collect performance metrics across all browsers with automatic user-agent segmentation and dashboard comparison features.
- Custom RUM beacons: lightweight JavaScript that captures Navigation Timing API data, LCP (via
PerformanceObserver), and interaction timing, then sends it to an analytics endpoint. Custom implementations provide full control over what is measured and how it is segmented.
The diagnostic workflow compares CrUX-reported 75th percentile values against all-browser RUM 75th percentile values for the same pages and time period. Three outcomes are possible:
- CrUX and RUM align: Chrome and non-Chrome users experience similar performance. CrUX is representative, and optimization efforts benefit all users equally.
- CrUX is better than RUM: non-Chrome users (primarily Safari) experience worse performance than Chrome users. CrUX overstates the site’s performance quality relative to total traffic. Ranking signals are protected, but business metrics suffer.
- CrUX is worse than RUM: Chrome users experience worse performance than non-Chrome users. CrUX understates the site’s performance quality. This scenario indicates Chrome-specific issues (slow Android devices, unoptimized Blink rendering paths) that should be prioritized because they directly affect ranking signals.
Each outcome requires a different optimization response. The comparison is the prerequisite for making that determination.
The Limitation That Cannot Be Solved: Google Evaluates What It Measures
Even with comprehensive cross-browser RUM providing full visibility into total user experience, Google’s ranking algorithm uses CrUX data exclusively. There is no mechanism to submit non-CrUX performance data to influence page experience assessment. Google does not accept RUM data from third-party tools, and the page experience signal is derived entirely from CrUX field data at the 75th percentile.
This structural limitation has a clear implication: Chrome-specific optimization is the ranking priority. If a performance improvement benefits Chrome users but not Safari users, it still improves the ranking signal. If a performance improvement benefits Safari users but not Chrome users, it provides zero ranking signal benefit. The ranking incentive structure is misaligned with the business incentive structure for sites with significant non-Chrome traffic.
The position confidence on this limitation is confirmed. Google has stated that CrUX is the data source for the page experience ranking signal, and CrUX methodology documentation explicitly defines the Chrome-only scope. No Google representative has indicated plans to expand CrUX to include non-Chrome browsers, even as Safari and Firefox have begun implementing the underlying Web Vitals APIs.
The practical resolution is accepting the dual reality: optimize for Chrome to protect rankings, optimize for all browsers to protect revenue. Track both datasets independently, report them separately to leadership, and allocate engineering resources across both tracks proportional to their business impact. Attempting to influence a signal source that cannot be changed wastes resources; working within its constraints while separately optimizing for uncaptured audiences maximizes total outcome.
Does CrUX include data from Chrome on iOS?
No. Chrome on iOS uses Apple’s WebKit engine rather than Chromium’s Blink engine, and CrUX does not collect data from WebKit-based browsers. This means all iOS Chrome users are excluded from CrUX alongside Safari users. In markets with high iOS market share, CrUX data may represent less than half of actual mobile traffic, creating a significant sampling bias toward Android user experiences.
Can a site have no CrUX mobile data despite receiving substantial mobile traffic?
Yes, if the mobile traffic comes predominantly from browsers that CrUX does not track. A site serving a market where iOS dominates mobile browsing may have abundant mobile traffic but insufficient Chrome-on-Android sessions to meet CrUX’s minimum data thresholds. In this scenario, CrUX reports no mobile data, and Google falls back to origin-level or similar-URL aggregation for page experience evaluation.
Does Firefox contribute to CrUX data?
No. CrUX collects data exclusively from opted-in Chrome browser users across desktop, Android, and ChromeOS. Firefox, Edge, Samsung Internet, and all other browsers are excluded. Sites with significant Firefox user populations see their CrUX data skewed toward Chrome’s performance characteristics, which may differ from Firefox due to rendering engine differences between Blink and Gecko.
Sources
- https://developer.chrome.com/docs/crux/methodology
- https://web.dev/articles/crux-and-rum-differences
- https://www.debugbear.com/blog/firefox-safari-web-vitals
- https://www.erwinhofman.com/core-web-vitals-faq/data/
- https://www.searchenginejournal.com/apple-safari-update-enables-tracking-two-core-web-vitals-metrics/563465/
