Core/Dashディメンション： デバイス & クライアント能力

これらのディメンションが測定するもの

CoreDashは、デバイス & クライアント能力カテゴリの下で2つのディメンションを提供します。これらは異なる疑問に答えるものですが、互いに直接補完し合っています。

Device Memory（グループコード m）は、ブラウザが navigator.deviceMemory から返すRAMバケットを報告します。仕様では意図的に最も近い2の累乗に切り下げて結果をクランプしているため、正確な数値ではなく、0.25、0.5、1、2、4、または8+ GBの値が表示されます。この丸め処理は意図的なものです。フィンガープリンティングスクリプトが利用できる精度を制限しつつ、開発者には実用的なシグナルを提供します。

Client Capability Score（グループコード ccs）は、CoreDashがブラウザから公開されている3つのシグナル（デバイスメモリ、navigator.hardwareConcurrency（論理CPUコア数）、Network Information APIからの実効接続タイプ）から計算する複合スコアです。結果は次の6つのバケットのいずれかになります。

複合スコアは、単一のシグナルを個別に確認するよりも有用です。2G接続における4 GB RAMのデバイスは、Wi-Fi接続された同じデバイスとはまったく異なる挙動を示します。メモリ、コア数、および接続タイプを1つの順序尺度に統合することで、変数ごとに個別のブレイクダウンを実行することなく、パフォーマンスデータをフィルタリングして比較できます。

ブラウザのサポート状況とデータカバレッジ

navigator.deviceMemory はChromiumのみのAPIです。FirefoxとSafariはこれを公開していないため、これらのブラウザではメモリコンポーネントとして常に不明（CCS 0）が報告されます。実際には、ChromeおよびChromeベースのブラウザがAndroidトラフィックの大部分を占めており、低メモリ状態が集中するのはAndroidデバイスです。したがって、このシグナルは最も重要となる場所で最も確実に得られます。

Device Memory HTTPヘッダー（Device-Memory）は、サーバーがAccept-CHネゴシエーションによるリクエストから同じ値を読み取れるようにする別の仕組みです。CoreDashはページロード時に収集されるJavaScript APIを使用するため、サーバー側でのヘッダー設定を必要とせず、値はRUMビーコンとともに送信されます。

なぜデバイス能力がCore Web Vitalsにとって重要なのか

LCPは主にネットワークとレンダリングの問題です。対して、INPは主にCPUとメモリの問題です。この違いがあるからこそ、CCSディメンションはINPデータにおいて最も顕著に現れます。

main thread上のlong taskは、入力への反応をブロックします。1 GB RAMのデバイスでは、JavaScriptが実行される前にブラウザはすでにメモリ不足に陥っています。よりアグレッシブなガベージコレクション、頻繁なタブの破棄、JITコンパイル用の空き領域の減少は、すべてタスクの実行時間の長期化に直結します。最新のスマートフォンでは180 msでINPをクリアするサイトでも、制約ありのデバイスでは簡単に400 msに達してしまいます。

2025 Web Almanac Performanceの章がその傾向を裏付けています。モバイルのINPクリア率は全体で77%に達していますが、その数値における高性能デバイスとローエンドデバイスのギャップは大きいです。モバイルWebユーザーの約29%は、現在のフラッグシップ機の3分の1以下の処理能力のデバイスを使用しています。これらのユーザーは、大半のグローバル市場において例外的な存在ではなく、中央値の訪問者なのです。

CLSはINPほどハードウェアクラスの影響を受けません。しかし、CPUが低速なデバイスでは、フォントや遅れて読み込まれる画像がリフローを引き起こし、ブラウザがすでにフレームをコミットした後に処理が完了するため、レイアウトシフトが発生することがあります。

CoreDashでのCCSとDevice Memory ofの活用方法

最も効率的なワークフローは、まずCCSをフィルターとして使用し、その後にDevice Memoryを使って仮説を検証することです。

まず、CCS別のINPブレイクダウンを開きます。75パーセンタイルのINPが、非常に高性能（CCS 1）および高性能（CCS 2）の訪問者で良好であるのに対し、制限あり（CCS 3）以下で基準に達していない場合、ネットワークではなくCPUまたはメモリのボトルネックが発生しています。これにより、一連の対策（プレロード、接続ヒント、CDNの調整など）が除外され、JavaScriptの実行時間（long task、入力ハンドラーの重さ、インタラクションのたびに実行されるサードパーティスクリプトなど）に集中できます。

次に、Device Memoryでフィルターをかけ、どのRAMバケットが最悪の結果をもたらしているかを確認します。1 GBのデバイスが悪いINPスコアの大部分を占めている場合、閾値が特定できます。4 GBでは問題のないスクリプトであっても、そのデータのみに基づいて、遅延実行や削除の候補にできます。

グローバルなユーザーを持つサイトでは、CCSとCountryディメンションを組み合わせます。南アジア、東南アジア、サブサハラアフリカ、およびラテンアメリカの一部には、制約あり（Constrained）や非常に制限あり（Very Limited）のデバイスが高密度で存在しています。国でフィルターをかけたCCSブレイクダウンは、ギャップが最も大きい地域を示し、どの市場から優先的に対処すべきかの判断に役立ちます。

不明バケット（CCS 0）は、すべてのFirefoxとSafariのトラフィック、およびAPIが値を返さなかったセッションをカバーします。これを無視しないでください。FirefoxやSafariのシェアが大きいサイトでは、不明（Unknown）が全セッションの4分の1以上を占めることがあります。これはユーザーのデバイスが劣っていることを意味するのではなく、シグナルが得られなかっただけです。不明セグメントはベースラインに含めるのではなく、別個のセグメントとして扱ってください。

データをもとに取るべきアクション

CCS 3、4、または5の訪問者がトラフィックの15%以上を占め、かつ彼らのINPが常に200 msを超えている場合、取るべき対策は明確です。

• Chrome DevToolsを使い、スロットリングを有効にしたデバイスで最長のタスクをプロファイリングします。PerformanceパネルのTask Attributionを確認すれば、原因となっているスクリプトが特定できます。
• 重要ではないサードパーティスクリプトは、インタラクションや表示開始（スクロールなど）をトリガーにして読み込ませるようにし、初期ロード時にmain threadで競合しないようにします。
• クリティカルパスにおけるJavaScriptのバンドルサイズを削減します。低メモリデバイスではJITコンパイラがコンパイル済みコードをキャッシュする領域が少ないため、1 KBあたりのパースコストがフラッグシップデバイスよりもはるかに高くなります。
• scheduler.yield() や setTimeout(0) を使用してlong taskを分割し、処理の合間にブラウザが入力イベントを処理できるようにします。

CoreDashは、すべてのCore Web Vitals指標の隣にCCSおよびDevice Memoryディメンションを表示します。これにより、高性能デバイスでINPを改善した修正が、ベストケースのユーザーだけでなく、制約ありの訪問者の数値も改善できたかどうかを確認できます。