CoreDash Dimension: Browser

Dimension: Seite & Navigation: URLs (u)

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

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

RUM vs. CrUX

Das Verständnis der Datenquelle ist entscheidend für eine präzise 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. Sich ausschließlich auf CrUX zu verlassen, erzeugt einen blinden Fleck: Sie optimieren für Googles V8-Engine, während Sie die SpiderMonkey (Firefox) und JavaScriptCore (Safari) Engines vernachlässigen, die von einem massiven Teil Ihrer Zielgruppe genutzt werden.

Metrikspezifische Diagnosen

Verschiedene Browser-Engines verwalten Ressourcen, kompilieren JavaScript und berechnen die Layout-Geometrie unterschiedlich. Nutzen Sie diese Dimension, um Engine-spezifische Fehler präzise zu lokalisieren.

Interaction to Next Paint (INP)

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

• Firefox (SpiderMonkey): Firefox handhabt die Aufgabenpriorisierung anders als Chrome. Ein schwerer Event-Listener, der in Chrome funktioniert, kann in Firefox aufgrund von Unterschieden beim yielding des Main-Threads zu spürbaren Eingabeverzögerungen führen.
• Safari (JavaScriptCore): Zeigt oft ein spezifisches Verhalten hinsichtlich der „Tap“-Latenz auf Mobilgeräten. Eine Hydrations-Logik, die sich auf Android (Chrome) sofort anfühlt, kann auf iOS aufgrund unterschiedlicher Event-Propagationsmodelle Verzögerungen auslösen.

Largest Contentful Paint (LCP)

LCP Diskrepanzen signalisieren in der Regel fehlende Feature-Parität oder mangelnde Unterstützung moderner Optimierungs-APIs.

• Format-Aushandlung: Wenn Chrome einen schnellen LCP meldet, Firefox jedoch zurückbleibt, überprüfen Sie Ihre Bildformat-Strategie. Möglicherweise liefern Sie AVIF an Chrome aus, während Sie für ältere Browserversionen ohne Unterstützung auf größere JPEGs als fallback zurückgreifen.
• Priority Hints: Chrome respektiert fetchpriority="high" aggressiv. Browser, die dieses Attribut ignorieren, behandeln die LCP Ressource mit Standardpriorität, was den Load Delay künstlich aufbläht.
• Verbindungsprotokolle: Edge und Firefox können HTTP/3 (QUIC) Verbindungen in Unternehmensumgebungen oder restriktiven Netzwerken anders aushandeln, was die TTFB Komponente von LCP beeinflusst.

Cumulative Layout Shift (CLS)

Rendering-Engines berechnen die Pixelgeometrie mit unterschiedlicher Sub-Pixel-Logik.

• Font-Rendering (Gecko vs. Blink): Firefox (Gecko) und Chrome (Blink) rendern Schrift-Baselines und Tracking leicht unterschiedlich. Wenn Sie Ihre fallback Schriftmetriken nicht perfekt abstimmen, wird der Textblock beim Laden der Webfont seine Größe ändern, was in einem Browser einen Shift verursacht, im anderen jedoch nicht.
• Scrollbar-Reservierung: Windows-Browser (Edge/Firefox/Chrome) reservieren physischen Platz für Scrollbalken, während macOS-Browser diese überlagern. Diese Diskrepanz verursacht oft breitenbasierte Layout-Verschiebungen, die bei der Entwicklung auf einem Mac unsichtbar sind, für Windows-Nutzer jedoch deutlich hervortreten.

Workflow: Isolierung Engine-spezifischer Regressionen

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

• Ausreißer identifizieren: Sortieren Sie Ihre Browser-Tabelle nach Impact oder Volume. Suchen Sie nach einem spezifischen Browser (z. B. Firefox Mobile), der einen deutlich schlechteren Score aufweist als die Baseline (Chrome Mobile).
• Umgebung verifizieren: Prüfen Sie, ob das Problem strikt auf den Browser oder eine Kombination aus Browser und Betriebssystem bezogen ist (z. B. Edge auf Android vs. Edge auf Windows).
• Debuggen: Wenn Edge langsam ist, Chrome aber schnell (beide nutzen Blink), untersuchen Sie Drittanbieter-Erweiterungen oder Unternehmens-Sicherheitssoftware, die bei Edge-Nutzern üblich sind und Skripte in das DOM injizieren. Wenn Firefox langsam ist, prüfen Sie Ihr CSS auf nicht-standardisierte Eigenschaften oder layout thrashing, das Gecko stärker bestraft als Blink.

Legacy- und Embedded-Browser

Nutzen Sie die Dimension Browser, um Performance-Bremser im „Long Tail“ zu identifizieren.

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

Legacy-Versionen: Sie könnten Traffic von veralteten Browserversionen finden. Wenn diese einen hohen INP erzeugen, konfigurieren Sie Ihre Build-Tools (Babel/PostCSS) so, dass entweder notwendige polyfills bereitgestellt werden oder – falls das Volumen vernachlässigbar ist – treffen Sie die strategische Entscheidung, den Support einzustellen, um die bundle size für moderne Nutzer zu reduzieren.