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

ディメンション：Browser (browser)

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

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

RUMとCrUXの比較

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

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

多くのWebサイトにおいて、Chrome以外のブラウザはトラフィックの30〜50%を占めています。CrUXにのみ依存すると、GoogleのV8エンジンに最適化する一方で、オーディエンスの大部分が使用するSpiderMonkey（Firefox）およびJavaScriptCore（Safari）エンジンを無視するという盲点が生まれます。

指標別の診断

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

Interaction to Next Paint (INP)

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

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

Largest Contentful Paint (LCP)

LCPの不一致は通常、機能のパリティの欠如、または最新の最適化APIのサポートの欠如を示しています。

• フォーマットネゴシエーション: Chromeでは高速なLCPが報告されるのにFirefoxでは遅延する場合は、画像フォーマットの戦略を確認してください。ChromeにはAVIFを提供しつつ、サポートがない古いブラウザバージョンにはサイズの大きいJPEGにfallbackしている可能性があります。
• Priority Hints: Chromeはfetchpriority="high"を積極的に尊重します。この属性を無視するブラウザは、LCPリソースを標準の優先度で処理するため、読み込み遅延が人為的に増加します。
• 接続プロトコル: 企業や制限の厳しいネットワーク環境では、EdgeとFirefoxでHTTP/3（QUIC）接続のネゴシエート方法が異なる場合があり、LCPのTTFBコンポーネントに影響を与えます。

Cumulative Layout Shift (CLS)

レンダリングエンジンは、それぞれ異なるサブピクセルロジックを使用してピクセルジオメトリを計算します。

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

ワークフロー：エンジン固有のパフォーマンス低下の特定

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

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

レガシーブラウザと組み込みブラウザ

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

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

レガシーバージョン: 時代遅れのブラウザバージョンからのトラフィックが見つかる場合があります。これらが高いINPを引き起こす場合は、必要なポリフィルを提供するようにビルドツール（Babel/PostCSS）を構成するか、ボリュームが無視できる程度であれば、モダンユーザーのためにバンドルサイズを減らす目的でサポートを打ち切るという戦略的な決定を下します。