Core/Dash Dimension: Operating System

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

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

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

プラットフォームの状況

StatCounter（2025年）によると、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の中央値のデバイスはCPUが弱いため、Androidのp75 INPは通常、iOSよりも40〜60%高くなります。

Client Capability ScoreディメンションでAndroidトラフィックをフィルタリングし、フラッグシップユーザー（iOSのようなパフォーマンス）を低価格ユーザー（より軽量なページが必要）から分離します。

iOS

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

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

Windows

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

macOS

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

LinuxおよびChromeOS

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

デバッグのワークフロー

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

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

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

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