Core/Dash Dimension: Browser

Dimension: Browser (browser)

Die Dimension Browser gruppiert Performance-Daten basierend auf dem vom Client gesendeten User-Agent-String. So kannst du die Core Web Vitals-Performance aus der Perspektive der Software analysieren, die deine Anwendung rendert (z. B. Chrome, Firefox, Safari, Edge, Samsung Internet).

Die Dimension Browser isoliert Software-Einschränkungen, Unterschiede zwischen Rendering-Engines (Blink, Gecko, WebKit) und die Kompatibilität mit Drittanbieter-Skripten.

RUM vs. CrUX

Für eine präzise technische Analyse musst du die Datenquelle verstehen.

• CrUX (Chrome User Experience Report): Dieser Datensatz erfasst 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: Erfasst Daten von jedem Browser, der das JavaScript-Snippet ausführt.

Bei vielen Websites machen Nicht-Chrome-Browser 30–50 % des Traffics aus. Sich nur auf CrUX zu verlassen, schafft einen blinden Fleck: Du optimierst für Googles V8-Engine, vernachlässigst aber die Engines SpiderMonkey (Firefox) und JavaScriptCore (Safari), die ein großer Teil deiner Besucher nutzt.

Metrikspezifische Diagnose

Verschiedene Browser-Engines verwalten Ressourcen, kompilieren JavaScript und berechnen die Layout-Geometrie unterschiedlich. Nutze diese Dimension, um engine-spezifische Probleme gezielt 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 priorisiert Tasks anders als Chrome. Ein rechenintensiver Event-Listener, der in Chrome problemlos durchläuft, kann in Firefox eine spürbare Verzögerung der Eingabe verursachen, da der main thread anders yieldet.
• Safari (JavaScriptCore): zeigt oft ein anderes Verhalten bei der „Tap“-Latenz auf Mobilgeräten. Eine Hydration-Logik, die sich auf Android (Chrome) verzögerungsfrei anfühlt, kann auf iOS durch andere Event-Propagierungsmodelle Verzögerungen verursachen.

Largest Contentful Paint (LCP)

LCP-Abweichungen signalisieren meist eine fehlende Feature-Parität oder mangelnden Support für moderne Optimierungs-APIs.

• Format-Aushandlung: Wenn Chrome einen schnellen LCP meldet, Firefox aber hinterherhinkt, überprüfe deine Bildformat-Strategie. Eventuell lieferst du AVIF an Chrome aus, nutzt aber größere JPEGs als fallback für ältere Browser ohne Support.
• Priority Hints: Chrome beachtet fetchpriority="high" sehr aggressiv. Browser, die dieses Attribut ignorieren, behandeln die LCP-Ressource mit Standardpriorität, was die Ladezeitverzögerung künstlich erhöht.
• Connection Protocols: Edge und Firefox handeln HTTP/3-Verbindungen (QUIC) in Unternehmens- oder eingeschränkten Netzwerkumgebungen eventuell anders aus, was sich auf die TTFB-Komponente des LCP auswirkt.

Cumulative Layout Shift (CLS)

Rendering-Engines berechnen die Pixelgeometrie mit unterschiedlicher Subpixel-Logik.

• Font-Rendering (Gecko vs. Blink): Firefox (Gecko) und Chrome (Blink) rendern Grundlinien und Laufweiten von Schriften minimal unterschiedlich. Wenn die Metriken deiner fallback-Schriftart nicht perfekt übereinstimmen, ändert sich die Größe des Textblocks beim Laden des Webfonts. Das verursacht eine Verschiebung in einem Browser, aber nicht im anderen.
• Scrollbar-Reservierung: Windows-Browser (Edge/Firefox/Chrome) reservieren physischen Platz für Scrollbars, während macOS-Browser sie als Overlay anzeigen. Dieser Unterschied verursacht oft breitenabhängige Layout-Verschiebungen, die bei der Entwicklung auf einem Mac unsichtbar sind, bei Windows-Nutzern jedoch deutlich auffallen.

Workflow: Engine-spezifische Regressionen isolieren

Der Hauptanwendungsfall für diese Dimension ist die „Engine-Validierung“.

• Ausreißer identifizieren: Sortiere deine Browser-Tabelle nach Impact oder Volumen. Suche nach einem bestimmten Browser (z. B. Firefox Mobile), der einen deutlich schlechteren Wert aufweist als die Baseline (Chrome Mobile).
• Umgebung überprüfen: Prüfe, ob das Problem rein browserbedingt ist oder an einer Kombination aus Browser und Betriebssystem liegt (z. B. Edge auf Android vs. Edge unter Windows).
• Debug: Wenn Edge langsam ist, Chrome aber schnell (beide nutzen Blink), untersuche Drittanbieter-Erweiterungen oder bei Edge-Nutzern verbreitete Enterprise-Sicherheitssoftware, die Skripte in das DOM injizieren. Wenn Firefox langsam ist, überprüfe dein CSS auf nicht-standardisierte Eigenschaften oder Layout-Thrashing, das Gecko stärker bestraft als Blink.

Legacy- und Embedded-Browser

Nutze die Dimension Browser, um Performance-Bremsen im „Long Tail“ 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.

Veraltete Versionen: Eventuell siehst du Traffic von veralteten Browser-Versionen. Wenn diese einen hohen INP verursachen, konfiguriere deine Build-Tools (Babel/PostCSS) so, dass sie entweder die nötigen Polyfills ausliefern, oder triff bei vernachlässigbarem Volumen die strategische Entscheidung, den Support einzustellen, um die Bundle-Größe für moderne Nutzer zu reduzieren.