维度:操作系统 (os)
操作系统维度按用户设备上运行的平台对性能数据进行分组:Android、iOS、Windows、macOS、Linux 或 ChromeOS。虽然浏览器维度隔离了渲染引擎的差异,但操作系统维度揭示了硬件限制、系统级资源管理以及浏览器继承的特定平台怪癖。
操作系统是代码和硬件之间的层。它控制 CPU 如何调度任务、如何分配内存以及如何确定网络请求的优先级。不同操作系统上两个完全相同的浏览器可能会产生截然不同的 Core Web Vitals。

平台概况
根据 StatCounter (2025) 的数据,Android 以 39% 的比例领跑全球网络流量,其次是 Windows (30%)、iOS (16%)、macOS (8%)、Linux (4%) 和 ChromeOS (2%)。您的具体流量分布会因行业而异。B2B SaaS 产品会看到更多的 Windows 和 macOS 流量。消费者应用则偏向于 Android 和 iOS。
特定操作系统的性能特征
Android
Android 是最具多样性的平台。它运行在从 80 美元的廉价手机到 1500 美元的旗舰机等各种设备上。这意味着您的 Android 细分市场同时包含最快和最慢的用户。关键洞察:Android 的平均性能被预算硬件的长尾所拖累。在 CoreDash 数据中,Android 的 p75 INP 通常比 iOS 高出 40-60%,因为中位 Android 设备的 CPU 性能较弱。
通过客户端能力得分 (Client Capability Score) 维度过滤 Android 流量,将旗舰用户(性能类似 iOS)与预算用户(需要更轻量的页面)区分开来。
iOS
Apple 控制着硬件和软件堆栈,这带来了非常一致的性能。设备范围很窄(iPhone 12 到 iPhone 16),并且无论“浏览器”标签是什么,每台设备都运行 Safari 的 WebKit 引擎。CoreDash 中的 iOS 流量通常显示出比 Android 好 15-25% 的 LCP 和好 30-40% 的 INP。
陷阱:如果您只在 iOS 上测试,您的网站会感觉很快。但您的 Android 用户(全球数量是 iOS 用户的 2.5 倍)正经历着截然不同的体验。
Windows
Windows 主导着桌面流量。这里的性能通常很强,因为桌面硬件很强大。然而,企业级 Windows 环境引入了独特的问题:企业代理服务器会增加 TTFB,强制性的浏览器扩展会注入降低 INP 的脚本,而 IT 政策可能会强制使用较旧的浏览器版本。
macOS
macOS 流量来自相对高端的硬件基础。性能通常非常出色。如果 macOS 用户显示出较差的指标,问题几乎可以肯定出在您的代码中(繁重的 JavaScript,未优化的图像),而不是平台。
Linux 和 ChromeOS
这些代表了较小的流量份额,但用户画像非常鲜明。Linux 用户往往是拥有快速硬件的开发人员。ChromeOS 用户通常使用 RAM 和存储空间有限的 Chromebook。如果 ChromeOS 显示出较差的 INP,请检查您的 JavaScript 内存占用是否超出了设备的限制。
调试工作流
- 首先比较 Android 与 iOS:这揭示了移动硬件的差距。如果 Android INP 为 250ms,而 iOS 为 90ms,则说明您存在一个仅在较弱 CPU 上才会显现的 JavaScript 复杂性问题。修复方法是减少主线程工作,而不是购买更快的服务器。
- 检查 Windows 的企业级异常:如果 Windows TTFB 比 macOS 高 200ms,请调查企业代理和 VPN。这些是用户端的底层架构问题,但了解它们可以防止您去追查虚幻的服务器问题。
- 结合操作系统 + 浏览器以获得精确度:“iOS 上的 Safari”与“Android 上的 Chrome”截然不同。过滤 操作系统 + 浏览器 来识别性能退化是全平台范围的,还是特定于某一种浏览器与操作系统的组合。
工程经验法则
- Android INP 保持在 200ms 以下:如果您的 iOS INP 通过但 Android 失败,请减少 JavaScript 执行时间。预算级 Android CPU 才是您真正的性能预算。
- 任何操作系统都不应比另一个差两倍:50% 的差距是正常的(硬件差异)。100% 以上的差距则标志着特定平台的错误或未优化的代码路径。
- 在真实的 Android 设备上进行测试:Chrome DevTools CPU 节流可以模拟缓慢的硬件,但真实设备测试可以捕获模拟所遗漏的操作系统级调度问题。
操作系统维度揭示了您的性能问题是普遍存在的还是特定于平台的。这种区分决定了您是应该修复代码还是修复交付策略。