Core/Dash Dimensie: Browser

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

Gratis proefperiode

Trusted by market leaders · Client results

saturnnestleadevintavpncompareharvardnina carekpnsnvdpg mediamonarchwhowhatwearfotocasahappyhorizonperionloopearplugsworkivamarktplaatsmy work featured on web.devaleteiaerasmusmcebay

Dimensie: Browser (browser)

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

Begrijpen wat de bron van je gegevens is, is belangrijk voor nauwkeurige technische analyses.

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

Voor veel websites vertegenwoordigen niet-Chrome browsers 30-50% van het verkeer. Alleen 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 deel van je publiek worden gebruikt, verwaarloost.

Metriek-Specifieke Diagnostiek

Verschillende browser engines beheren bronnen, compileren JavaScript en berekenen lay-outgeometrie op een andere manier. Gebruik deze dimensie om engine-specifieke fouten te lokaliseren.

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 invoervertraging veroorzaken vanwege verschillen in hoe de main thread yields.
  • Safari (JavaScriptCore): vertoont vaak afwijkend gedrag met betrekking tot "tap" latentie op mobiel. Hydration logica die op Android (Chrome) direct aanvoelt, kan op iOS vertragingen veroorzaken door afwijkende eventpropagatie modellen.

Largest Contentful Paint (LCP)

LCP-verschillen 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 strategie voor afbeeldingsformaten. Misschien serveer je AVIF aan Chrome, terwijl je terugvalt op grotere JPEG's voor oudere browserversies die hiervoor geen ondersteuning bieden.
  • Priority Hints: Chrome respecteert agressief fetchpriority="high". Browsers die dit attribuut negeren, behandelen de LCP resource met standaardprioriteit, wat de Load Delay kunstmatig verhoogt.
  • Verbindingsprotocollen: Edge en Firefox kunnen HTTP/3 (QUIC) verbindingen in zakelijke of beperkte netwerkomgevingen anders onderhandelen, wat de TTFB component van LCP beïnvloedt.

Cumulative Layout Shift (CLS)

Rendering engines berekenen pixelgeometrie met behulp van afwijkende sub-pixel logica.

  • Lettertyperendering (Gecko vs. Blink): Firefox (Gecko) en Chrome (Blink) renderen lettertypebaselines en spatiëring net iets anders. Als je je fallback font metrics niet perfect afstemt, zal het tekstblok van grootte veranderen wanneer het weblettertype laadt, wat een verschuiving in de ene browser veroorzaakt, maar niet in de andere.
  • Reservering voor schuifbalken: Windows browsers (Edge/Firefox/Chrome) reserveren fysieke ruimte voor schuifbalken, terwijl macOS browsers ze overlappen. Deze ongelijkheid veroorzaakt vaak breedtegebaseerde lay-outverschuivingen die tijdens de ontwikkeling op een Mac onzichtbaar zijn, maar voor Windows gebruikers prominent aanwezig zijn.

Workflow: Isoleren van Engine-Specifieke Regressies

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 basislijn (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).
  • Foutopsporing: Als Edge traag is maar Chrome snel (beide gebruiken Blink), onderzoek dan third-party extensies of zakelijke beveiligingssoftware die vaak door Edge gebruikers worden gebruikt en scripts in de DOM injecteren. Als Firefox traag is, controleer dan je CSS op niet-standaard eigenschappen 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 kunt verkeer van verouderde browserversies tegenkomen. Als deze een hoge INP genereren, configureer dan je build tools (Babel/PostCSS) om de benodigde polyfills te serveren of, als het volume verwaarloosbaar is, neem dan de strategische beslissing om ondersteuning te laten vallen om de bundle size voor moderne gebruikers te verkleinen.


Dimensie: BrowserCore Web Vitals Dimensie: Browser