Core/Dash ディメンション: ブラウザ

ディメンション: ブラウザ (browser)

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

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

RUM vs. CrUX

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

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

多くのウェブサイトにとって、Chrome以外のブラウザはトラフィックの30〜50%を占めています。CrUXのみに依存すると死角が生じます。つまり、オーディエンスの大部分が使用しているSpiderMonkey（Firefox）やJavaScriptCore（Safari）エンジンを無視しながら、GoogleのV8エンジンに最適化することになります。

指標固有の診断

ブラウザエンジンが異なれば、リソースの管理、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を提供し、サポートが欠けている古いブラウザバージョンには、fallbackとしてより重いJPEGを提供している可能性があります。
• 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フォントのメトリクスを完全に一致させない場合、Webフォントの読み込み時にテキストブロックのサイズが変更され、一方のブラウザではシフトが発生し、もう一方では発生しないことがあります。
• スクロールバーの予約: Windowsブラウザ（Edge/Firefox/Chrome）はスクロールバーのための物理的なスペースを予約しますが、macOSブラウザはそれらをオーバーレイで表示します。この違いは、Macでの開発中には見えないものの、Windowsユーザーにとっては目立つ、幅に基づくレイアウトシフトを頻繁に引き起こします。

ワークフロー: エンジン固有のパフォーマンス低下の分離

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

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

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

ブラウザディメンションを使用して、「ロングテール」のパフォーマンスの足を引っ張る要因を特定します。

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

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