Core/Dash Dimension: Browser

Dimension: Browser (browser)

Die Dimension Browser gruppiert Performance-Daten basierend auf dem vom Client gesendeten User-Agent-String. Dies ermöglicht es Ihnen, die Performance der Core Web Vitals durch die Linse der spezifischen Software zu auditieren, die Ihre Anwendung rendert (z. B. Chrome, Firefox, Safari, Edge, Samsung Internet).

Die Dimension Browser isoliert Softwareeinschränkungen, Unterschiede in der Rendering-Engine (Blink, Gecko, WebKit) und die Kompatibilität von Skripten von Drittanbietern.

RUM vs. CrUX

Das Verständnis der Quelle Ihrer Daten ist wichtig für eine genaue technische Analyse.

• CrUX (Chrome User Experience Report): Dieser Datensatz sammelt Daten ausschließlich von Opt-in-Nutzern auf Chrome (und einigen Chromium-Derivaten). Er schließt Traffic von Firefox (Gecko-Engine) und Safari (WebKit-Engine) blind aus.
• CoreDash RUM: Sammelt Daten von jedem Browser, der das JavaScript-Snippet ausführt.

Für viele Websites machen Nicht-Chrome-Browser 30-50 % des Traffics aus. Wenn Sie sich ausschließlich auf CrUX verlassen, entsteht ein blinder Fleck: Sie optimieren für die V8-Engine von Google und vernachlässigen gleichzeitig die SpiderMonkey- (Firefox) und JavaScriptCore- (Safari) Engines, die von einem massiven Teil Ihrer Zielgruppe verwendet werden.

Metrikspezifische Diagnosen

Unterschiedliche Browser-Engines verwalten Ressourcen, kompilieren JavaScript und berechnen die Layout-Geometrie unterschiedlich. Verwenden Sie diese Dimension, um Engine-spezifische Fehler genau zu lokalisieren.

Interaction to Next Paint (INP)

INP-Probleme korrelieren direkt mit der Effizienz der JavaScript-Engine des Browsers und dem Main-Thread-Scheduling.

• Firefox (SpiderMonkey): Firefox handhabt die Aufgabenpriorisierung anders als Chrome. Ein schwerer Event-Listener, der in Chrome besteht, kann in Firefox aufgrund von Unterschieden beim Yielding des Main-Threads zu spürbaren Eingabeverzögerungen führen.
• Safari (JavaScriptCore): weist auf Mobilgeräten oft unterschiedliche Verhaltensweisen hinsichtlich der "Tap"-Latenz auf. Hydratationslogik, die sich auf Android (Chrome) sofort anfühlt, kann auf iOS aufgrund unterschiedlicher Ereignisausbreitungsmodelle Verzögerungen auslösen.

Largest Contentful Paint (LCP)

LCP-Diskrepanzen signalisieren in der Regel eine mangelnde Funktionsparität oder fehlende Unterstützung für moderne Optimierungs-APIs.

• Format Negotiation: Wenn Chrome einen schnellen LCP meldet, Firefox jedoch hinterherhinkt, überprüfen Sie Ihre Bildformatstrategie. Möglicherweise stellen Sie AVIF für Chrome bereit, während Sie auf größere JPEGs für ältere Browserversionen zurückgreifen, denen die Unterstützung fehlt.
• Priority Hints: Chrome respektiert aggressiv fetchpriority="high". Browser, die dieses Attribut ignorieren, behandeln die LCP-Ressource mit Standardpriorität, was die Ladeverzögerung künstlich in die Höhe treibt.
• Connection Protocols: Edge und Firefox verhandeln HTTP/3- (QUIC) Verbindungen in Unternehmens- oder eingeschränkten Netzwerkumgebungen möglicherweise unterschiedlich, was sich auf die TTFB-Komponente des LCP auswirkt.

Cumulative Layout Shift (CLS)

Rendering-Engines berechnen die Pixelgeometrie anhand einer unterschiedlichen Sub-Pixel-Logik.

• Font Rendering (Gecko vs. Blink): Firefox (Gecko) und Chrome (Blink) rendern Schriftgrundlinien und Laufweite leicht unterschiedlich. Wenn Sie Ihre Fallback-Schriftmetriken nicht perfekt anpassen, wird die Größe des Textblocks beim Laden der Webschriftart geändert, was in einem Browser zu einer Verschiebung führt, im anderen jedoch nicht.
• Scrollbar Reservation: Windows-Browser (Edge/Firefox/Chrome) reservieren physischen Platz für Bildlaufleisten, während macOS-Browser sie überlagern. Diese Diskrepanz führt oft zu breitenbasierten Layoutverschiebungen, die während der Entwicklung auf einem Mac unsichtbar sind, für Windows-Nutzer jedoch prominent in Erscheinung treten.

Workflow: Engine-spezifische Regressionen isolieren

Der primäre Anwendungsfall für diese Dimension ist die "Engine-Validierung".

• Den Ausreißer identifizieren: Sortieren Sie Ihre Browser-Tabelle nach Auswirkungen oder Volumen. Suchen Sie nach einem bestimmten Browser (z. B. Firefox Mobile), der einen signifikant schlechteren Score als die Baseline (Chrome Mobile) aufweist.
• Die Umgebung überprüfen: Überprüfen Sie, ob das Problem ausschließlich mit dem Browser oder einer Kombination aus Browser und Betriebssystem (z. B. Edge auf Android vs. Edge auf Windows) zusammenhängt.
• Debuggen: Wenn Edge langsam, Chrome aber schnell ist (beide verwenden Blink), untersuchen Sie Erweiterungen von Drittanbietern oder Unternehmenssicherheitssoftware, die bei Edge-Nutzern üblich ist und Skripte in das DOM injiziert. Wenn Firefox langsam ist, auditieren Sie Ihr CSS auf nicht standardmäßige Eigenschaften oder Layout-Thrashing, das Gecko stärker bestraft als Blink.

Ältere und eingebettete Browser

Verwenden Sie die Dimension Browser, um "Long Tail"-Performance-Bremsen zu identifizieren.

In-App-Browser: Traffic von Instagram, LinkedIn oder Facebook läuft oft in eingeschränkten WebViews, die sich anders verhalten als der native mobile Browser.

Ältere Versionen: Möglicherweise finden Sie Traffic von veralteten Browserversionen. Wenn diese hohe INP erzeugen, konfigurieren Sie Ihre Build-Tools (Babel/PostCSS) so, dass sie entweder die erforderlichen Polyfills bereitstellen oder, falls das Volumen vernachlässigbar ist, treffen Sie die strategische Entscheidung, die Unterstützung einzustellen, um die Bundle-Größe für moderne Nutzer zu reduzieren.