CoreDash Dimensie: Browser

Los cross-browser performance-regressies op door verkeer te segmenteren op basis van de specifieke browser-engine van de gebruiker.

Gratis proefperiode

Trusted by market leaders

saturnaleteiafotocasanestleloopearplugsperionebaywhowhatwearmarktplaatsnina carecompareerasmusmchappyhorizonworkivamonarchsnvdpg mediavpnkpnharvardadevinta

Dimensie: Pagina & Navigatie: URLs (u)

De Browser-dimensie groepeert performance-data op basis van de User Agent-string die door de client wordt verzonden. Hiermee kun je Core Web Vitals performance auditen door de lens van de specifieke software die je applicatie rendert (bijv. Chrome, Firefox, Safari, Edge, Samsung Internet).

De Browser-dimensie isoleert softwarebeperkingen, verschillen in rendering engines (Blink, Gecko, WebKit) en de compatibiliteit van scripts van derden.

coredash metric table urls

RUM vs. CrUX

Het begrijpen van de bron van je data is cruciaal voor een nauwkeurige technische analyse.

  • CrUX (Chrome User Experience Report): Deze dataset verzamelt uitsluitend data van opt-in gebruikers op Chrome (en enkele Chromium-varianten). Het sluit verkeer van Firefox (Gecko engine) en Safari (WebKit engine) volledig uit.
  • CoreDash RUM: Verzamelt data van elke browser die het JavaScript-fragment uitvoert.

Voor veel websites vertegenwoordigen niet-Chrome browsers 30-50% van het verkeer. Alleen vertrouwen op CrUX creëert een blind spot: je optimaliseert voor Google's V8-engine terwijl je de SpiderMonkey (Firefox) en JavaScriptCore (Safari) engines verwaarloost, die door een enorm segment van je publiek worden gebruikt.

Metriek-specifieke diagnostiek

Verschillende browser-engines beheren resources, compileren JavaScript en berekenen layout-geometrie op verschillende manieren. Gebruik deze dimensie om engine-specifieke fouten op te sporen.

Interaction to Next Paint (INP)

INP-problemen correleren direct met de efficiëntie van de JavaScript-engine van de browser en de scheduling van de main-thread.

  • Firefox (SpiderMonkey): Firefox gaat anders om met taakprioritering dan Chrome. Een zware event listener die in Chrome soepel werkt, kan in Firefox merkbare input-vertraging veroorzaken door verschillen in hoe de main thread yield.
  • Safari (JavaScriptCore): Vertoont vaak specifiek gedrag met betrekking tot "tap"-latentie op mobiel. Hydration-logica die instant aanvoelt op Android (Chrome) kan vertragingen veroorzaken op iOS door afwijkende event-propagation modellen.

Largest Contentful Paint (LCP)

LCP-verschillen duiden meestal op een gebrek aan feature-pariteit of ondersteuning voor moderne optimalisatie-APIs.

  • Format-onderhandeling: Als Chrome een snelle LCP rapporteert maar Firefox achterblijft, controleer dan je strategie voor afbeeldingsformaten. Mogelijk serveer je AVIF aan Chrome terwijl je een fallback naar grotere JPEGs gebruikt voor oudere browserversies die ondersteuning missen.
  • Priority Hints: Chrome respecteert fetchpriority="high" agressief. Browsers die dit attribuut negeren, behandelen de LCP-resource met een standaardprioriteit, wat de Load Delay kunstmatig verhoogt.
  • Verbindingsprotocollen: Edge en Firefox kunnen HTTP/3 (QUIC)-verbindingen anders onderhandelen in zakelijke of beperkte netwerkomgevingen, wat invloed heeft op de TTFB-component van LCP.

Cumulative Layout Shift (CLS)

Rendering engines berekenen pixelgeometrie met verschillende sub-pixel logica.

  • Font Rendering (Gecko vs. Blink): Firefox (Gecko) en Chrome (Blink) renderen font baselines en tracking net even anders. Als je de fallback font metrics niet perfect op elkaar afstemt, zal het tekstblok van grootte veranderen wanneer het webfont laadt, wat een shift veroorzaakt in de ene browser maar niet in de andere.
  • Gereserveerde scrollbars: Windows-browsers (Edge/Firefox/Chrome) reserveren fysieke ruimte voor scrollbars, terwijl macOS-browsers deze als overlay tonen. Dit verschil veroorzaakt vaak op breedte gebaseerde layout shifts die onzichtbaar zijn tijdens ontwikkeling op een Mac, maar prominent aanwezig zijn voor Windows-gebruikers.

Workflow: Engine-specifieke regressies isoleren

De belangrijkste use case voor deze dimensie is "Engine Validatie".

  • Identificeer de afwijking: Sorteer je Browser-tabel op Impact of Volume. Zoek naar een specifieke browser (bijv. Firefox Mobile) die een aanzienlijk slechtere score heeft dan de baseline (Chrome Mobile).
  • Verifieer de omgeving: Controleer of het probleem strikt gerelateerd is aan de browser of een combinatie van browser en OS (bijv. Edge op Android vs. Edge op Windows).
  • Debuggen: Als Edge traag is maar Chrome snel (beiden gebruiken Blink), onderzoek dan third-party extensies of enterprise security software die veelvoorkomend is bij Edge-gebruikers en scripts in de DOM injecteert. Als Firefox traag is, audit dan je CSS op niet-standaard eigenschappen of layout thrashing die door Gecko zwaarder wordt bestraft dan door Blink.

Legacy en Embedded Browsers

Gebruik de Browser-dimensie om "Long Tail" performance-knelpunten te identificeren.

In-App Browsers: Verkeer van Instagram, LinkedIn of Facebook draait vaak in beperkte WebViews die zich anders gedragen dan de native mobiele browser.

Legacy-versies: Je kunt verkeer tegenkomen van verouderde browserversies. Als deze een hoge INP genereren, configureer dan je build-tools (Babel/PostCSS) om ofwel de nodige polyfills te serveren of, als het volume verwaarloosbaar is, de strategische beslissing te nemen om ondersteuning te laten vallen en zo de payload van de bundle voor moderne gebruikers te verkleinen.


Dimensie: BrowserCore Web Vitals Dimensie: Browser