Core/Dash ディメンション： オペレーティングシステム

ディメンション：オペレーティングシステム (os)

Operating Systemディメンションは、ユーザーのデバイスで実行されているプラットフォーム（Android、iOS、Windows、macOS、Linux、またはChromeOS）ごとにパフォーマンスデータをグループ化します。Browserディメンションがレンダリングエンジンの違いを分離するのに対し、OSディメンションは、ハードウェアの制約、システムレベルのリソース管理、およびブラウザが継承するプラットフォーム固有の癖を明らかにします。

OSは、コードとハードウェアの間のレイヤーです。CPUがタスクをスケジュールする方法、メモリを割り当てる方法、およびネットワークリクエストを優先する方法を制御します。異なるオペレーティングシステム上の2つの同一のブラウザは、まったく異なるCore Web Vitalsを生成する可能性があります。

プラットフォームの状況

StatCounter (2025)によると、世界のWebトラフィックはAndroidが39%でトップであり、Windowsが30%、iOSが16%、macOSが8%、Linuxが4%、ChromeOSが2%と続きます。特定のトラフィックの割合は業界によって異なります。B2B SaaS製品では、WindowsとmacOSのトラフィックが多くなります。消費者向けアプリはAndroidとiOSに偏っています。

OS固有のパフォーマンス特性

Android

Androidは最も多様なプラットフォームです。80ドルの低予算のスマートフォンから1,500ドルのフラッグシップまで、さまざまなデバイスで動作します。これは、Androidセグメントに最速のユーザーと最も遅いユーザーの両方が含まれていることを意味します。重要な洞察：Androidの平均パフォーマンスは、低予算のハードウェアのロングテールによって引き下げられます。CoreDashデータでは、Androidのp75 INPは通常、iOSよりも40〜60%高くなります。これは、Androidデバイスの中央値のCPUが弱いためです。

AndroidトラフィックをClient Capability Scoreディメンションでフィルタリングして、フラッグシップユーザー（iOSのように実行するユーザー）と低予算のユーザー（より軽いページを必要とするユーザー）を分離します。

iOS

Appleはハードウェアとソフトウェアスタックを制御しているため、非常に一貫したパフォーマンスが得られます。デバイスの範囲は狭く（iPhone 12からiPhone 16まで）、すべてのデバイスは「ブラウザ」のラベルに関係なくSafariのWebKitエンジンを実行します。CoreDashのiOSトラフィックは通常、AndroidよりもLCPが15〜25%良く、INPが30〜40%優れています。

落とし穴：iOSでのみテストした場合、サイトは高速に感じられます。しかし、世界中でiOSユーザーを2.5対1で上回るAndroidユーザーは、異なる体験をしています。

Windows

Windowsはデスクトップトラフィックを支配しています。デスクトップハードウェアは強力であるため、ここのパフォーマンスは一般的に強力です。ただし、エンタープライズWindows環境には独自の問題があります。企業のプロキシサーバーによってTTFBが肥大化したり、必須のブラウザ拡張機能によってINPを低下させるスクリプトが挿入されたり、ITポリシーによって古いブラウザバージョンが強制される可能性があります。

macOS

macOSトラフィックは、比較的プレミアムなハードウェアベースから発生します。パフォーマンスは通常優れています。macOSユーザーの指標が悪い場合、問題はプラットフォームではなく、ほぼ確実にコード（重いJavaScript、最適化されていない画像）にあります。

LinuxおよびChromeOS

これらはトラフィックのシェアは小さいものの、ユーザープロファイルが異なります。Linuxユーザーは、高速なハードウェアを使用する開発者である傾向があります。ChromeOSユーザーは、RAMとストレージが限られたChromebookを使用していることがよくあります。ChromeOSでINPが低い場合は、JavaScriptのメモリフットプリントがデバイスの制約を超えていないか確認してください。

デバッグワークフロー

1. 最初にAndroidとiOSを比較する： これにより、モバイルハードウェアのギャップが明らかになります。AndroidのINPが250ミリ秒で、iOSが90ミリ秒の場合、弱いCPUでのみ現れるJavaScriptの複雑さの問題があります。解決策は、高速なサーバーを購入することではなく、メインスレッドの作業を減らすことです。
2. Windowsのエンタープライズの異常を確認する： WindowsのTTFBがmacOSよりも200ミリ秒高い場合は、企業のプロキシとVPNを調査してください。これらはユーザー側のインフラストラクチャの問題ですが、これらを理解することで、幻のサーバーの問題を追いかけるのを防ぐことができます。
3. 精度を高めるためにOS + Browserを組み合わせる： 「iOS上のSafari」は「Android上のChrome」とはまったく異なります。OS + Browserをフィルタリングして、パフォーマンスの低下がプラットフォーム全体に及んでいるのか、それとも特定のブラウザとOSの組み合わせに固有のものなのかを特定します。

エンジニアリングの経験則

• AndroidのINPを200ミリ秒未満にする： iOSのINPは合格でもAndroidで失敗する場合は、JavaScriptの実行時間を短縮してください。予算の限られたAndroidのCPUが、実際のパフォーマンスバジェットとなります。
• どのOSも別のOSの2倍悪くなってはいけない： 50%のギャップは正常です（ハードウェアの違い）。100%以上のギャップは、プラットフォーム固有のバグ、または最適化されていないコードパスを示しています。
• 実際のAndroidデバイスでテストする： Chrome DevToolsのCPUスロットリングは低速なハードウェアを近似しますが、実際のデバイスでのテストでは、エミュレーションでは見逃されるOSレベルのスケジューリングの問題を捕捉できます。

Operating Systemディメンションは、パフォーマンスの問題が普遍的なものか、プラットフォーム固有のものかを明らかにします。この区別により、コードを修正するのか、配信戦略を修正するのかが決まります。