Core/Dash Dimension: Operating System

Isolate platform-specific performance regressions by segmenting traffic across operating systems.

Free trial

Trusted by market leaders · Client results

nestlehappyhorizonharvardmarktplaatskpnfotocasasnvdpg mediacompareperionmonarcherasmusmcaleteiamy work featured on web.devwhowhatwearebayadevintanina careworkivasaturnloopearplugsvpn

Dimension: Operating System (os)

The Operating System dimension groups performance data by the platform running on the user's device: Android, iOS, Windows, macOS, Linux, or ChromeOS. While the Browser dimension isolates rendering engine differences, the OS dimension exposes hardware constraints, system-level resource management, and platform-specific quirks that the browser inherits.

The OS is the layer between your code and the hardware. It controls how the CPU schedules tasks, how memory is allocated, and how network requests are prioritized. Two identical browsers on different operating systems can produce very different Core Web Vitals.

coredash metric table urls

The Platform Landscape

According to StatCounter (2025), Android leads global web traffic at 39%, followed by Windows at 30%, iOS at 16%, macOS at 8%, Linux at 4%, and ChromeOS at 2%. Your specific traffic split will vary by industry. B2B SaaS products see heavier Windows and macOS traffic. Consumer apps skew toward Android and iOS.

OS-Specific Performance Characteristics

Android

Android is the most diverse platform. It runs on devices ranging from $80 budget phones to $1,500 flagships. This means your Android segment contains both your fastest and slowest users. The key insight: Android's average performance is dragged down by the long tail of budget hardware. In CoreDash data, Android p75 INP is typically 40-60% higher than iOS because the median Android device has a weaker CPU.

Filter Android traffic by the Client Capability Score dimension to separate flagship users (who perform like iOS) from budget users (who need lighter pages).

iOS

Apple controls the hardware and software stack, which produces remarkably consistent performance. The device range is narrow (iPhone 12 through iPhone 16), and every device runs Safari's WebKit engine regardless of the "browser" label. iOS traffic in CoreDash typically shows 15-25% better LCP and 30-40% better INP than Android.

The trap: if you only test on iOS, your site feels fast. Your Android users (who outnumber iOS users 2.5:1 globally) are having a different experience.

Windows

Windows dominates desktop traffic. Performance here is generally strong because desktop hardware is powerful. However, enterprise Windows environments introduce unique issues: corporate proxy servers inflate TTFB, mandatory browser extensions inject scripts that degrade INP, and IT policies may force older browser versions.

macOS

macOS traffic comes from a relatively premium hardware base. Performance is typically excellent. If macOS users show poor metrics, the issue is almost certainly in your code (heavy JavaScript, unoptimized images) rather than the platform.

Linux and ChromeOS

These represent small traffic shares but distinct user profiles. Linux users tend to be developers with fast hardware. ChromeOS users are often on Chromebooks with limited RAM and storage. If ChromeOS shows poor INP, check whether your JavaScript memory footprint is exceeding the device's constraints.

Debugging Workflow

  1. Compare Android vs iOS first: This reveals the mobile hardware gap. If Android INP is 250ms and iOS is 90ms, you have a JavaScript complexity problem that only manifests on weaker CPUs. The fix is reducing main-thread work, not buying faster servers.
  2. Check Windows for enterprise anomalies: If Windows TTFB is 200ms higher than macOS, investigate corporate proxies and VPNs. These are infrastructure issues on the user's side, but understanding them prevents you from chasing phantom server problems.
  3. Combine OS + Browser for precision: "Safari on iOS" is a different animal than "Chrome on Android." Filter OS + Browser to identify whether a regression is platform-wide or specific to one browser-on-OS combination.

Engineering Rule of Thumb

  • Android INP under 200ms: If your iOS INP passes but Android fails, reduce JavaScript execution time. The budget Android CPU is your real performance budget.
  • No OS should be 2x worse than another: A 50% gap is normal (hardware differences). A 100%+ gap signals a platform-specific bug or an unoptimized code path.
  • Test on real Android devices: Chrome DevTools CPU throttling approximates slow hardware, but real device testing catches OS-level scheduling issues that emulation misses.

The Operating System dimension reveals whether your performance problems are universal or platform-specific. That distinction determines whether you fix your code or fix your delivery strategy.