デバイス別パフォーマンス

モバイルデバイスとデスクトップのユーザーは、通常、同じエクスペリエンスを得られません。高速なラップトップで素早く読み込まれるページでも、低速なプロセッサーとセルラー接続を持つスマートフォンでは遅く感じられる可能性があります。Zenovay の Performance タブ（Speed Insights）を使用すると、Core Web Vitals をデバイス別に分割でき、これらのギャップを確認して修正できます。

場所を見つける

Domains からあなたのウェブサイトのダッシュボードを開き、次に Performance タブを選択します。Performance はダッシュボードのサイドバーの Behavior の下にグループ化されています。

Performance タブは、リアルユーザーから 5 つの Core Web Vitals を計測します：

• LCP — Largest Contentful Paint
• CLS — Cumulative Layout Shift
• INP — Interaction to Next Paint
• FCP — First Contentful Paint
• TTFB — Time to First Byte

デバイス別にパフォーマンスを分割する

Performance ツールバーには、3 つのオプションを備えた デバイスフィルター があります：

• All — すべてのユーザー
• Desktop
• Mobile

フィルターを切り替えて、同じメトリックをデバイスクラス全体で比較します。モバイルは通常、デスクトップより遅い Core Web Vitals を表示します。理由は：

• プロセッサーが遅く、メモリが少ない
• レイテンシーが高いセルラーネットワーク
• より小さいビューポート。コンテンツの読み込み方と移動方法に影響を与えることがあります

パーセンタイル セレクター（p75、p90、p95、p99）とデバイスフィルターを組み合わせて、問題がほとんどのモバイルユーザーに影響するか、または最も遅いユーザーのみに影響するかを確認します。

原因を掘り下げる

デバイスクラスが遅く見える場合は、Performance タブの内訳を使用して、問題がどこにあるかを見つけます：

• ページ別 — 選択したメトリックの最悪の値を持つルート。単一の重いテンプレートは、デバイスセグメント全体を引き下げることがよくあります。
• 国別 — 世界地図に加えてランク付きリスト。デバイス問題とネットワーク/地理の問題を区別できます。
• TTFB フェーズ — DNS、接続、サーバー、転送時間に Time to First Byte を分割するウォーターフォール。バックエンドの遅さとネットワーク距離を分離するのに役立ちます。
• 最も責任のある要素 — 各ルートで選択したメトリックに最も責任のある特定のセレクター。

デバイスフィルターとこれらの内訳を組み合わせることで、通常は問題を特定できます。たとえば「INP はモバイルで低下しており、特にチェックアウトルートで」など。

通知の受け取り

Zenovay の自動アラートは、メトリックごと、デバイスごとのしきい値ではなく、異常検出とトラフィックスパイク通知をカバーしています。全体的なパフォーマンスの変化について通知され、定期的なサマリーをスケジュールするには、Performance Alerts ガイドを参照してください。

最適化戦略

Mobile-first

モバイルは通常、最大かつ最も遅いセグメントなので、優先してください：

1. JavaScript を削減 — 通常 INP とロード時間の最大のメリット
2. モバイルビューポート用にイメージを最適化し、サイズを適切に調整
3. レイアウトシフト（CLS）を最小化
4. タップターゲットサイズを改善
5. エミュレータだけでなく、実際のローエンドデバイスでテスト

デバイスごとに正しいアセットを提供する

携帯電話がデスクトップサイズのファイルをダウンロードしないようにレスポンシブ画像を使用します：

<!-- Responsive images -->
<picture>
  <source
    srcset="image-mobile.webp"
    media="(max-width: 768px)"
  >
  <source
    srcset="image-desktop.webp"
    media="(min-width: 769px)"
  >
  <img src="image-fallback.jpg" alt="Description">
</picture>

プログレッシブエンハンスメント

すべてのデバイスがすべての API をサポートしていると仮定するのではなく、機能を検出します：

// Feature detection
if ('IntersectionObserver' in window) {
  // Use modern lazy loading
} else {
  // Fall back to a simpler approach
}

デバイス別パフォーマンス予算

リグレッションを防ぐシンプルな方法は、デバイスクラスごとに予算を設定し、それ以上のものはすべてバグとして扱うことです：

Performance Budgets

Metric      Desktop    Mobile
LCP         < 2.0s     < 2.5s
INP         < 150ms    < 200ms
CLS         < 0.05     < 0.1

トラブルシューティング

デバイスデータなし

チェック：

• トラッキングスクリプトが想定されるページにインストールされている（Install the tracking script を参照）
• ユーザーはプライバシーツールまたはアド ブロッカーによってブロックされていない
• 選択した期間を埋めるのに十分な最近のトラフィックがある

デバイスクラスがメトリックを表示しない

Core Web Vitals はリアルユーザーのセッションから収集されます。新しいサイト、低トラフィックのページ、または非常に短い期間は、デバイス分割用の十分なサンプルをまだ持っていない可能性があります。範囲を拡張するか、より多くのトラフィックを待ってください。

次のステップ

• Core Web Vitals
• Page Load Performance
• Performance Alerts