CoreDash ディメンション： デバイスとクライアントの能力

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

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 はこれを公開していないため、これらのブラウザはメモリコンポーネントに対して常に Unknown（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 データにおいて最も顕著に現れます。

メインスレッドでの長いタスクは、入力へのレスポンスをブロックします。1 GB RAM のデバイスでは、JavaScript が実行される前からブラウザはすでにメモリ不足の状態にあります。よりアグレッシブなガベージコレクション、より頻繁なタブの破棄、JIT コンパイル用のヘッドルームの減少は、すべてタスク期間の長期化に直結します。最新のスマートフォンでは 180 ms で INP をパスするサイトも、Constrained（制約のある）デバイスでは容易に 400 ms に達することがあります。

2025 Web Almanac のパフォーマンスチャプター はこの傾向を裏付けています。モバイルの INP パス率は全体で 77% に達しますが、その数値における高性能デバイスとローエンドデバイスの差は広大です。モバイルウェブユーザーの約 29% は、現在のフラッグシップ機の 3 分の 1 以下の性能しかないデバイスを使用しています。これらのユーザーは、ほとんどのグローバル市場において外れ値ではなく、平均的な訪問者です。

CLS は INP ほどハードウェアクラスの影響を受けませんが、CPU の遅いデバイスでは、フォントや遅延読み込み画像によってリフローが発生し、ブラウザがすでにフレームをコミットした後に完了する場合、レイアウトシフトが発生する可能性があります。

CoreDash で CCS とデバイスメモリを使用する方法

最も生産的なワークフローは、まず CCS をフィルターとして使い、次にデバイスメモリを使用して仮説を確認することです。

まず、CCS 別の INP ブレイクダウンを開きます。75 パーセンタイルの INP が Very Capable (CCS 1) および Capable (CCS 2) の訪問者では良好だが、Limited (CCS 3) 以下で失敗している場合、それはネットワークのボトルネックではなく、CPU またはメモリのボトルネックがあることを意味します。これにより、一連の修正カテゴリ（プリロード、接続ヒント、CDN チューニング）を除外し、JavaScript の実行時間（長いタスク、入力ハンドラーの重さ、すべてのインタラクションで実行されるサードパーティスクリプト）に注意を向けることができます。

次に、デバイスメモリでフィルタリングして、どの RAM バケットが最悪の結果をもたらしているかを確認します。1 GB のデバイスが不当に高い割合で低い INP スコアを占めている場合、その閾値がわかります。4 GB では許容できるスクリプトも、そのデータのみに基づいて延期や削除の候補になります。

グローバルなオーディエンスを持つサイトの場合は、CCS と 国 ディメンションを組み合わせてください。南アジア、東南アジア、サハラ以南のアフリカ、ラテンアメリカの一部では、Constrained および Very Limited デバイスの割合が高いです。国でフィルタリングした CCS ブレイクダウンは、どこで差が最も大きいかを示し、どの市場を優先的に対処すべきかの判断を助けます。

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

データをもとに何をするか

CCS 3、4、または 5 の訪問者がトラフィックの 15% 以上を占め、彼らの INP が一貫して 200 ms を超えている場合、修正セットは具体的です：

• Chrome DevTools でスロットリングを有効にしたデバイスを使用して、最も長いタスクをプロファイリングします。パフォーマンスパネルのタスクアトリビューションにより、どのスクリプトに責任があるかがわかります。
• 非中心的なサードパーティスクリプトをインタラクションまたは視認性のトリガーの後ろに移動し、初期ロードウィンドウ中にメインスレッドを競合させないようにします。
• クリティカルパス上の JavaScript バンドルサイズを削減します。低メモリデバイスでは、JIT コンパイラがコンパイル済みコードをキャッシュする余裕が少ないため、1 キロバイトあたりの解析コストがフラッグシップ機よりも高くなります。
• scheduler.yield() または setTimeout(0) を使用して長いタスクを分割し、チャンク間でブラウザが入力を処理する機会を与えます。

CoreDash は、すべての Core Web Vitals メトリクスと共に CCS とデバイスメモリのディメンションを表示するため、高性能デバイスで INP を改善した修正が、ベストケースのユーザーだけでなく、Constrained な訪問者の数値も動かしたかどうかを確認できます。