Core/Dash ディメンション: Device Type

ディメンション: Device Type (d)

Device Typeディメンションは、RUMデータをmobileとdesktopの2つのカテゴリに分割する。モバイルとデスクトップは根本的に異なるコンピューティング環境であるため、これはあらゆるパフォーマンス調査において最も重要な最初のフィルターとなる。異なるCPU、異なるネットワーク条件、異なるビューポートサイズ、異なるブラウザエンジンが存在する。

デバイスタイプでフィルタリングせずに、集計されたCore Web Vitalsを見ている場合、共通点がほとんどない2つの集団を平均していることになる。その平均値は、よく言っても誤解を招くものだ。

モバイルパフォーマンスのギャップ

Statista（2025）によると、モバイルデバイスは世界のウェブトラフィックの約62%を占めている。それにもかかわらず、モバイルは一貫してデスクトップのパフォーマンスを下回っている。2025 Web Almanacによれば、すべての3つのCore Web Vitalsをパスするモバイルのオリジンはわずか48%であり、デスクトップの56%と比較して8パーセントポイントのギャップがある。

このギャップが存在するのは、モバイルデバイスがデスクトップにはない3つの制約に直面しているためである：

• CPUスロットリング: ミドルレンジのAndroidスマートフォンの処理能力は、デスクトップの約3〜5分の1である。デスクトップで50ミリ秒で実行されるJavaScriptが、モバイルでは200ミリ秒かかることがあり、INPを「良好」のしきい値超えに押し上げる。
• ネットワーク遅延: モバイル接続（4G/5G）は、有線接続に比べてラウンドトリップタイムが長く、変動が大きい。これがTTFBとLCPのLoad Delayを増大させる。
• ビューポートサイズ: 画面が小さいと、どの要素がLCPになるかが変わる。デスクトップのヒーロー画像がモバイルではテキストブロックの下に縮小され、最適化のターゲットが完全に変わってしまうことがある。

CoreDashにおけるDevice Typeの分布

CoreDashのプロジェクト全体で、一般的なトラフィックの割合はモバイル65%、デスクトップ35%である。Eコマースサイトはモバイルに偏る傾向があり（70〜75%）、一方B2B SaaS製品では50/50の割合か、あるいはデスクトップが優勢になることもよくある。

CoreDashのデータにおけるパフォーマンスのギャップは、世界的な傾向を反映している。モバイルのp75 LCPは平均2.8秒であるのに対し、デスクトップは1.9秒である。INPについてはこのギャップがさらに大きく、デスクトップが120ms付近にとどまるのに対し、モバイルのp75は220ms前後となっている。

指標別の分析

Largest Contentful Paint (LCP)

モバイルのLCPはほぼ常にデスクトップより悪い。主な原因はLoad Delayである。HTMLの到着に時間がかかり（高いTTFB）、プレロードスキャナーが低速なCPUでより多くのリソースの競合に直面するため、モバイルブラウザはLCP画像の発見が遅れる。デスクトップのLCPが2.0秒未満であるのにモバイルが3.0秒を超える場合、問題が画像ファイル自体にあることはまれである。問題は配信パイプラインにある。

Interaction to Next Paint (INP)

ここが、デバイス間のギャップが最も影響する部分である。デスクトップのCore i7で瞬時に感じられるJavaScriptのイベントハンドラーが、Snapdragon 665ではメインスレッドを300ミリ秒以上ブロックすることがある。モバイルでフィルタリングし、INPの影響度でソートすると、実際のスマートフォンで機能していないインタラクションを正確に見つけることができる。私はこれを常に目にしている。開発者はMacBook Proでテストし、実際のユーザーの65%が持っているデバイスでは使い物にならないインタラクションをリリースしているのだ。

Cumulative Layout Shift (CLS)

デバイスタイプ間のCLSの違いは、通常、レスポンシブデザインに起因する。デスクトップでスペースを確保している広告枠が、モバイルでは折りたたまれたりサイズが変更されたりすることがある。デスクトップで整列するフォントのfallbackメトリクスが、小さなビューポートでは視覚的なずれを引き起こす。Webフォントのレンダリングはモバイルとデスクトップのブラウザで異なり、物理的なピクセル密度がサブピクセルの丸めに影響を与える。

デバッグのワークフロー

1. すべての調査をデバイスのフィルターから開始する: 他のディメンションを見る前に、Device Typeで分割する。もし全体のLCPが2.5秒の場合、デスクトップが1.8秒、モバイルが3.1秒という結果がわかるかもしれない。この「問題」は完全にモバイル限定である。
2. p75だけでなく、分布を比較する: 各デバイスタイプの「良好/改善が必要/不良」の分布を確認する。デスクトップの「良好」が85%、モバイルの「良好」が45%である場合、p75単独の数値とはまったく異なる状況を示している。
3. 他のディメンションと組み合わせる: デバイスタイプを特定したら、2つ目のフィルターを追加する。Device Type + Countryによって、モバイルのギャップが世界的なものなのか、ネットワークが遅い地域に集中しているものなのかがわかる。Device Type + Navigation Typeによって、モバイルの「戻る・進む」ナビゲーションが適切にキャッシュされているかがわかる。

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

• モバイルのLCPを2.5秒未満にする: これはGoogleが「良好」と判断するしきい値である。デスクトップはパスしているがモバイルで失敗している場合は、Load Delayの短縮（fetchpriorityやpreload）とTTFBの改善（エッジキャッシングやCDN）に注力する。
• モバイルのINPを200ms未満にする: すべてのインタラクティブな機能は、実際のミドルレンジのAndroidデバイスでテストする。Chrome DevToolsのCPUスロットリング（4倍）はこれに近い状態を再現できるが、実際のデバイスでのテストの方がより確実である。
• 決してデスクトップのためだけに最適化しない: モバイルのトラフィックが50%を超える場合（そして、ほぼ確実にそうだろう）、モバイルのパフォーマンスは検索ランキングのシグナルになる。GoogleはランキングにモバイルのCrUXデータを使用している。

Device Typeは、あれば便利なフィルターではない。それは「これはモバイルの問題か、それともデスクトップの問題か？」という、あなたが尋ねるべき最初の質問である。すべての最適化の決定は、その答えから導き出される。