Core/Dash Dimension: デバイスタイプ

Core Web Vitalsデータをデバイスのフォームファクタごとに分割し、モバイルにおけるパフォーマンスのギャップをデバッグします。

無料トライアル

Trusted by market leaders · Client results

aleteiadpg mediavpnsnvnina caremarktplaatsmy work featured on web.devkpnhappyhorizonwhowhatwearmonarchnestleebayperionerasmusmcworkivacomparesaturnfotocasaharvardloopearplugsadevinta

ディメンション: デバイスタイプ (d)

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

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

coredash metric table urls

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

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

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

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

CoreDash のデバイスタイプ分布

CoreDash プロジェクト全体において、一般的なトラフィックの割合はモバイルが65%、デスクトップが35%です。Eコマースサイトはモバイルへの偏りが大きく (70〜75%)、B2B SaaS プロダクトでは50対50の割合、あるいはデスクトップが優勢になることもよくあります。

CoreDash データにおけるパフォーマンスのギャップは、世界的な傾向を反映しています。p75の LCP はデスクトップの1.9秒に対し、モバイルは平均2.8秒です。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 ではメインスレッドを 300ms 以上ブロックする可能性があります。モバイルでフィルタリングし、INP の影響度順にソートすれば、実際のスマートフォンで破綻しているインタラクションを正確に見つけることができます。私はこれを常日頃から目の当たりにしています。開発者は MacBook Pro でテストを行い、ユーザーの65%が実際に持ち歩いているデバイスでは使い物にならないインタラクションをリリースしているのです。

Cumulative Layout Shift (CLS)

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

デバッグのワークフロー

  1. すべての調査をデバイスフィルターから始める: 他のディメンションを見る前に、デバイスタイプで分割してください。集計された LCP が2.5秒の場合、デスクトップが1.8秒、モバイルが3.1秒という結果が判明するかもしれません。この場合、「問題」はモバイルに限定されています。
  2. p75だけでなく、分布を比較する: デバイスタイプごとに、良好 (good) / 改善が必要 (needs-improvement) / 不良 (poor) の分布を確認してください。良好が85%のデスクトップと、良好が45%のモバイルでは、p75単体とは全く異なるストーリーが浮かび上がります。
  3. 他のディメンションと組み合わせる: デバイスタイプを特定したら、2つ目のフィルターを追加します。デバイスタイプ + 国 (Country) の組み合わせにより、モバイルのギャップが世界的なものか、それとも低速なネットワーク地域に集中しているかが明らかになります。デバイスタイプ + Navigation Type (ナビゲーションタイプ) の組み合わせにより、モバイルの「戻る・進む」ナビゲーションが適切にキャッシュされているかどうかがわかります。

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

  • モバイルの LCP を2.5秒未満にする: これはGoogleが「良好 (good)」と判定するしきい値です。デスクトップが合格してモバイルが不合格の場合は、Load Delay (fetchpriority、preload) と TTFB (エッジキャッシング、CDN) の削減に注力してください。
  • モバイルの INP を 200ms 未満にする: すべてのインタラクティブな機能を、実際のミッドレンジの Android デバイスでテストしてください。Chrome DevTools の CPU スロットリング (4倍) はこれに近似できますが、実機でのテストに勝るものはありません。
  • デスクトップのみに最適化してはならない: モバイルトラフィックが50%を超える場合 (ほぼ間違いなく超えているはずです)、モバイルのパフォーマンスが検索ランキングのシグナルになります。Googleはランキングにモバイルの CrUX データを使用しています。

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