Core/Dash Dimensie: Browser

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

Gratis proefperiode

Trusted by market leaders · Client results

perionebaykpnhappyhorizonmarktplaatsnina caremy work featured on web.devsnvadevintanestlecompareerasmusmcmonarchloopearplugsvpnsaturnwhowhatweardpg mediaaleteiaharvardworkivafotocasa

Dimensie: Browser (browser)

De Browser dimensie groepeert prestatiedata op basis van de User Agent string die door de client wordt verzonden. Dit stelt je in staat om Core Web Vitals prestaties te auditeren 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 compatibiliteit met third-party scripts.

coredash metric table urls

RUM vs. CrUX

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

  • CrUX (Chrome User Experience Report): Deze dataset verzamelt exclusief data van opt-in gebruikers op Chrome (en sommige Chromium-afgeleiden). Het sluit blindelings verkeer van Firefox (Gecko engine) en Safari (WebKit engine) uit.
  • CoreDash RUM: Verzamelt data van elke browser die de JavaScript snippet uitvoert.

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

Metriek-Specifieke Diagnostiek

Verschillende browser engines beheren resources, compileren JavaScript en berekenen lay-out geometrie op een andere manier. Gebruik deze dimensie om engine-specifieke fouten te pinpointen.

Interaction to Next Paint (INP)

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

  • Firefox (SpiderMonkey): Firefox gaat anders om met taakprioritering dan Chrome. Een zware event listener die in Chrome goed presteert, kan in Firefox een merkbare input delay veroorzaken door verschillen in de manier waarop de main thread yields.
  • Safari (JavaScriptCore): vertoont vaak afwijkend gedrag met betrekking tot "tap" latency op mobiel. Hydration logica die op Android (Chrome) direct aanvoelt, kan op iOS vertragingen veroorzaken door afwijkende event propagation modellen.

Largest Contentful Paint (LCP)

LCP discrepanties duiden meestal op een gebrek aan feature-pariteit of ondersteuning voor moderne optimalisatie-API's.

  • Formaatonderhandeling: Als Chrome een snelle LCP rapporteert maar Firefox achterblijft, controleer dan je image format strategie. Misschien serveer je AVIF aan Chrome terwijl je een fallback gebruikt naar grotere JPEG's voor oudere browserversies die hiervoor geen ondersteuning bieden.
  • Priority Hints: Chrome respecteert fetchpriority="high" agressief. Browsers die dit attribuut negeren behandelen de LCP resource met standaard prioriteit, wat de Load Delay kunstmatig verhoogt.
  • Connectieprotocollen: Edge en Firefox kunnen HTTP/3 (QUIC) connecties in bedrijfs- of beperkte netwerkomgevingen anders onderhandelen, wat impact heeft op de TTFB component van LCP.

Cumulative Layout Shift (CLS)

Rendering engines berekenen pixel geometrie met behulp van 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 metrics van je fallback font niet perfect afstemt, zal het tekstblok van grootte veranderen wanneer het web font laadt, wat een shift in de ene browser veroorzaakt maar niet in de andere.
  • Scrollbar Reservering: Windows browsers (Edge/Firefox/Chrome) reserveren fysieke ruimte voor scrollbars, terwijl macOS browsers ze overlappen. Deze ongelijkheid veroorzaakt vaak width-gebaseerde layout shifts die onzichtbaar zijn tijdens de ontwikkeling op een Mac, maar prominent aanwezig zijn voor Windows gebruikers.

Workflow: Engine-Specifieke Regressies Isoleren

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

  • Identificeer de Uitschieter: 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 aan een combinatie van browser en OS (bijv. Edge op Android vs. Edge op Windows).
  • Debuggen: Als Edge traag is maar Chrome is snel (beide gebruiken Blink), onderzoek dan third-party extensies of bedrijfsbeveiligingssoftware die gebruikelijk is bij Edge gebruikers en die scripts in de DOM injecteert.Als Firefox traag is, controleer dan je CSS op niet-standaard properties of layout thrashing die door Gecko zwaarder worden bestraft dan door Blink.

Legacy en Embedded Browsers

Gebruik de Browser dimensie om "Long Tail" prestatievertragingen 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 vindt mogelijk verkeer van verouderde browserversies. Als deze een hoge INP genereren, configureer dan je build tools (Babel/PostCSS) om de benodigde polyfills te serveren, of maak, indien het volume verwaarloosbaar is, de strategische beslissing om ondersteuning te laten vallen om de bundle size voor moderne gebruikers te verkleinen.


Dimensie: BrowserCore Web Vitals Dimensie: Browser