Core/Dash ディメンション： Browser

ディメンション：Page & Navigation: URLs (u)

Browser ディメンションは、クライアントから送信された User Agent 文字列に基づいてパフォーマンスデータをグループ化する。これにより、アプリケーションをレンダリングする特定のソフトウェア（Chrome、Firefox、Safari、Edge、Samsung Internet など）の観点から Core Web Vitals パフォーマンスを監査できる。

Browser ディメンションは、ソフトウェアの制約、レンダリングエンジンの違い（Blink、Gecko、WebKit）、およびサードパーティスクリプトの互換性を分離する。

RUM vs. CrUX

データのソースを理解することは、正確なエンジニアリング分析にとって重要である。

• CrUX (Chrome User Experience Report): このデータセットは、Chrome（および一部の Chromium 派生ブラウザ）のオプトインユーザーからのみデータを収集する。Firefox（Gecko エンジン）や Safari（WebKit エンジン）からのトラフィックは盲目的に除外される。
• CoreDash RUM: JavaScript スニペットを実行するすべてのブラウザからデータを収集する。

多くのウェブサイトにおいて、非 Chrome ブラウザはトラフィックの 30〜50% を占める。CrUX のみに依存することは死角を生むことになる。つまり、Google の V8 エンジン向けに最適化を行う一方で、オーディエンスの大部分が使用している SpiderMonkey (Firefox) や JavaScriptCore (Safari) エンジンを無視することになるのだ。

メトリクス固有の診断

ブラウザエンジンが異なれば、リソースの管理、JavaScript のコンパイル、レイアウトジオメトリの計算方法も異なる。このディメンションを使用して、エンジン固有の障害を特定せよ。

Interaction to Next Paint (INP)

INP の問題は、ブラウザの JavaScript エンジンおよびメインスレッドのスケジューリング効率と直接相関している。

• Firefox (SpiderMonkey): Firefox は Chrome とは異なるタスク優先順位付けを行う。Chrome ではパスする重いイベントリスナーでも、メインスレッドが yield する方法の違いにより、Firefox では顕著な入力遅延を引き起こす可能性がある。
• Safari (JavaScriptCore): モバイルでの「タップ」レイテンシに関して独特の挙動を示すことが多い。Android (Chrome) では瞬時に感じられるハイドレーションロジックも、イベント伝播モデルの違いにより、iOS では遅延を引き起こす場合がある。

Largest Contentful Paint (LCP)

LCP の不一致は通常、機能の同等性（feature parity）の欠如、または最新の最適化 API のサポート不足を示唆している。

• フォーマットネゴシエーション: Chrome が高速な LCP を報告しているのに Firefox が遅れている場合は、画像フォーマット戦略を検証する。Chrome には AVIF を配信している一方で、サポートのない古いブラウザバージョンには、より大きな JPEG に fallback している可能性がある。
• Priority Hints: Chrome は fetchpriority="high" を積極的に尊重する。この属性を無視するブラウザは、LCP リソースを標準の優先度で扱うため、Load Delay が人為的に増大する。
• 接続プロトコル: Edge や Firefox は、企業ネットワークや制限されたネットワーク環境において HTTP/3 (QUIC) 接続のネゴシエーションを異なる方法で行う場合があり、これが LCP の TTFB コンポーネントに影響を与える。

Cumulative Layout Shift (CLS)

レンダリングエンジンは、独自のサブピクセルロジックを使用してピクセルジオメトリを計算する。

• フォントレンダリング (Gecko vs. Blink): Firefox (Gecko) と Chrome (Blink) では、フォントのベースラインとトラッキングのレンダリングがわずかに異なる。fallback フォントのメトリクスを完全に一致させない限り、ウェブフォントの読み込み時にテキストブロックのサイズが変更され、一方のブラウザではシフトが発生し、もう一方では発生しないという事態になる。
• スクロールバーの領域確保: Windows ブラウザ (Edge/Firefox/Chrome) はスクロールバーのために物理的なスペースを確保するが、macOS ブラウザはオーバーレイ表示する。この不一致により、Mac での開発中には見えない幅ベースのレイアウトシフトが、Windows ユーザーには顕著に現れることがよくある。

ワークフロー：エンジン固有のリグレッションの分離

このディメンションの主なユースケースは「エンジン検証」である。

• 外れ値の特定: Browser テーブルを Impact または Volume でソートする。ベースライン (Chrome Mobile) よりもスコアが著しく悪い特定のブラウザ (例: Firefox Mobile) を探す。
• 環境の検証: 問題がブラウザ単体に関連しているのか、ブラウザと OS の組み合わせ (例: Android 上の Edge 対 Windows 上の Edge) に関連しているのかを確認する。
• デバッグ: Edge が遅く Chrome が速い場合（どちらも Blink を使用）、DOM にスクリプトを注入する Edge ユーザーに一般的なサードパーティ拡張機能やエンタープライズセキュリティソフトウェアを調査する。Firefox が遅い場合は、Gecko が Blink よりも厳しくペナルティを科す非標準プロパティやレイアウトスラッシングがないか、CSS を監査する。

レガシーおよび組み込みブラウザ

Browser ディメンションを使用して、「ロングテール」のパフォーマンス低下要因を特定する。

アプリ内ブラウザ: Instagram、LinkedIn、Facebook からのトラフィックは、ネイティブモバイルブラウザとは異なる挙動をする制限された WebView で実行されることが多い。

レガシーバージョン: 古いブラウザバージョンからのトラフィックが見つかる場合がある。これらが高い INP を生成している場合は、ビルドツール (Babel/PostCSS) を設定して必要なポリフィルを提供するか、ボリュームが無視できる程度であれば、最新ユーザー向けにバンドルサイズを削減するためにサポートを打ち切るという戦略的決定を下す。