CoreDash-dimensjon: Browser

Dimensjon: Browser (browser)

Browser-dimensjonen grupperer ytelsesdata basert på User Agent-strengen sendt av klienten. Dette lar deg revidere Core Web Vitals-ytelse gjennom linsen til den spesifikke programvaren som randerer applikasjonen din (f.eks. Chrome, Firefox, Safari, Edge, Samsung Internet).

Browser-dimensjonen isolerer programvarebegrensninger, forskjeller i randeringsmotorer (Blink, Gecko, WebKit) og kompatibilitet med tredjepartsskript.

RUM vs. CrUX

Å forstå kilden til dataene dine er viktig for nøyaktig teknisk analyse.

• CrUX (Chrome User Experience Report): Dette datasettet samler inn data eksklusivt fra brukere som har valgt å dele data på Chrome (og enkelte Chromium-derivater). Det ekskluderer blindt trafikk fra Firefox (Gecko-motoren) og Safari (WebKit-motoren).
• CoreDash RUM: Samler inn data fra hver nettleser som utfører JavaScript-kodesnutten.

For mange nettsteder representerer andre nettlesere enn Chrome 30–50 % av trafikken. Å stole utelukkende på CrUX skaper en blindsone: du optimerer for Googles V8-motor mens du ignorerer SpiderMonkey (Firefox) og JavaScriptCore (Safari)-motorene som brukes av en massiv del av publikummet ditt.

Metrikk-spesifikk diagnostikk

Ulike nettlesermotorer administrerer ressurser, kompilerer JavaScript og beregner layoutgeometri forskjellig. Bruk denne dimensjonen til å peke ut motor-spesifikke feil.

Interaction to Next Paint (INP)

INP-problemer korrelerer direkte med effektiviteten til nettleserens JavaScript-motor og planlegging på main-thread.

• Firefox (SpiderMonkey): Firefox håndterer oppgaveprioritering annerledes enn Chrome. En tung event listener som passerer i Chrome, kan forårsake merkbar input delay i Firefox på grunn av forskjeller i hvordan main thread gir etter (yield).
• Safari (JavaScriptCore): utviser ofte distinkt oppførsel når det gjelder "tap"-latens på mobil. Hydration-logikk som føles umiddelbar på Android (Chrome), kan utløse forsinkelser på iOS på grunn av distinkte modeller for hendelsesforplantning.

Largest Contentful Paint (LCP)

LCP-avvik signaliserer vanligvis mangel på funksjonsparitet eller støtte for moderne optimerings-API-er.

• Format Negotiation: Hvis Chrome rapporterer en rask LCP, men Firefox lagger, bør du verifisere bildefilmformat-strategien din. Det kan hende du serverer AVIF til Chrome mens du faller tilbake på større JPEG-filer for eldre nettleserversjoner som mangler støtte.
• Priority Hints: Chrome respekterer aggressivt fetchpriority="high". Nettlesere som ignorerer dette attributtet, behandler LCP-ressursen med standard prioritet, noe som kunstig blåser opp Load Delay.
• Connection Protocols: Edge og Firefox kan forhandle HTTP/3 (QUIC)-tilkoblinger annerledes i bedrifts- eller begrensede nettverksmiljøer, noe som påvirker TTFB-komponenten av LCP.

Cumulative Layout Shift (CLS)

Randeringsmotorer beregner pikselgeometri ved hjelp av distinkt sub-piksel-logikk.

• Fontranderig (Gecko vs. Blink): Firefox (Gecko) og Chrome (Blink) randerer font-baselines og tracking litt forskjellig. Hvis du ikke matcher fallback-fontmetrikkene dine perfekt, vil tekstblokken endre størrelse når web font lastes inn, noe som forårsaker et skift i én nettleser, men ikke den andre.
• Reservering av rullefelt: Nettlesere på Windows (Edge/Firefox/Chrome) reserverer fysisk plass for rullefelt, mens nettlesere på macOS legger dem over innholdet. Dette avviket forårsaker ofte breddebaserte layoutskift som er usynlige under utvikling på en Mac, men fremtredende for Windows-brukere.

Arbeidsflyt: Isolere motor-spesifikke regresjoner

Det primære bruksområdet for denne dimensjonen er "motor-validering" (Engine Validation).

• Identifiser avviket: Sorter Browser-tabellen din etter Impact eller Volume. Se etter en spesifikk nettleser (f.eks. Firefox Mobile) som har en betydelig dårligere poengsum enn baselinen (Chrome Mobile).
• Verifiser miljøet: Sjekk om problemet er strengt relatert til nettleseren eller en kombinasjon av nettleser og OS (f.eks. Edge på Android vs. Edge på Windows).
• Debugging: Hvis Edge er treg, men Chrome er rask (begge bruker Blink), bør du undersøke tredjepartsutvidelser eller bedriftssikkerhetsprogramvare som er vanlig for Edge-brukere og som injiserer skript i DOM-en. Hvis Firefox er treg, bør du revidere CSS-en din for ikke-standardiserte egenskaper eller layout thrashing som Gecko straffer hardere enn Blink.

Legacy og innebygde nettlesere

Bruk Browser-dimensjonen til å identifisere suksessiv ytelsesforringelse ("Long Tail").

In-App-nettlesere: Trafikk fra Instagram, LinkedIn eller Facebook kjører ofte i begrensede WebView-er som oppfører seg annerledes enn den innebygde mobilnettleseren.

Legacy-versjoner: Du kan finne trafikk fra utdaterte nettleserversjoner. Hvis disse genererer høy INP, bør du konfigurere build-verktøyene dine (Babel/PostCSS) til enten å servere nødvendige polyfills eller, hvis volumet er ubetydelig, ta den strategiske beslutningen om å droppe støtte for å redusere bundle-størrelsen for moderne brukere.