Core/Dash-dimensjon: Nettleser

Dimensjon: Nettleser (browser)

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

Nettleser-dimensjonen isolerer programvarebegrensninger, forskjeller i gjengivelsesmotorer (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 utelukkende fra brukere som har valgt det på Chrome (og noen Chromium-derivater). Det ekskluderer blindt trafikk fra Firefox (Gecko-motoren) og Safari (WebKit-motoren).
• CoreDash RUM: Samler inn data fra alle nettlesere som utfører JavaScript-kodesnutten.

For mange nettsteder representerer nettlesere som ikke er Chrome 30-50 % av trafikken. Å stole utelukkende på CrUX skaper en blindsone: du optimaliserer for Googles V8-motor mens du forsømmer SpiderMonkey (Firefox) og JavaScriptCore (Safari)-motorene som brukes av et massivt segment av publikummet ditt.

Metrikkspesifikk diagnostikk

Ulike nettlesermotorer administrerer ressurser, kompilerer JavaScript og beregner layoutgeometri på forskjellige måter. Bruk denne dimensjonen til å lokalisere motorspesifikke feil.

Interaction to Next Paint (INP)

INP-problemer korrelerer direkte med effektiviteten til nettleserens JavaScript-motor og hovedtrådens planlegging.

• Firefox (SpiderMonkey): Firefox håndterer oppgaveprioritering annerledes enn Chrome. En tung hendelseslytter (event listener) som passerer i Chrome kan forårsake merkbar inndataforsinkelse i Firefox på grunn av forskjeller i hvordan hovedtråden gir slipp (yields).
• Safari (JavaScriptCore): utviser ofte distinkt oppførsel angående "tap"-latens på mobil. Hydreringslogikk som føles umiddelbar på Android (Chrome) kan utløse forsinkelser på iOS på grunn av distinkte modeller for hendelsesforplantning (event propagation).

Largest Contentful Paint (LCP)

LCP-avvik signaliserer vanligvis mangel på funksjonsparitet eller støtte for moderne optimaliserings-APIer.

• Formatforhandling (Format Negotiation): Hvis Chrome rapporterer en rask LCP, men Firefox henger etter, bør du bekrefte bildeformatstrategien din. Du serverer kanskje AVIF til Chrome, mens du faller tilbake (fallback) til større JPEG-filer for eldre nettleserversjoner som mangler støtte.
• Prioritetshint (Priority Hints): Chrome respekterer aggressivt fetchpriority="high". Nettlesere som ignorerer dette attributtet behandler LCP-ressursen med standard prioritet, noe som kunstig blåser opp lasteforsinkelsen (Load Delay).
• Tilkoblingsprotokoller: Edge og Firefox kan forhandle HTTP/3 (QUIC)-tilkoblinger forskjellig i bedrifts- eller begrensede nettverksmiljøer, noe som påvirker TTFB-komponenten til LCP.

Cumulative Layout Shift (CLS)

Gjengivelsesmotorer (rendering engines) beregner pikselgeometri ved å bruke distinkt sub-piksel logikk.

• Fontgjengivelse (Gecko vs. Blink): Firefox (Gecko) og Chrome (Blink) gjengir fontgrunnlinjer og sporing litt forskjellig. Hvis du ikke matcher dine fallback-fontmetrikker perfekt, vil tekstblokken endre størrelse når nettfonten lastes inn, noe som forårsaker et skifte i den ene nettleseren, men ikke i den andre.
• Rullefeltreservasjon (Scrollbar Reservation): Windows-nettlesere (Edge/Firefox/Chrome) reserverer fysisk plass for rullefelt, mens macOS-nettlesere legger dem over. Denne ulikheten forårsaker ofte breddebaserte layoutskifter som er usynlige under utvikling på en Mac, men fremtredende for Windows-brukere.

Arbeidsflyt: Isolering av motorspesifikke regresjoner

Den primære bruken for denne dimensjonen er "Motorvalidering" (Engine Validation).

• Identifiser avvikeren: Sorter nettlesertabellen etter innvirkning (Impact) eller volum (Volume). Se etter en bestemt nettleser (f.eks. Firefox Mobile) som har en betydelig dårligere poengsum enn grunnlinjen (Chrome Mobile).
• Bekreft 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).
• Feilsøk (Debug): 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, som injiserer skript i DOM. Hvis Firefox er treg, må du revidere CSS-en din for ikke-standardiserte egenskaper eller layout-thrashing som Gecko straffer tyngre enn Blink.

Eldre og innebygde nettlesere

Bruk Nettleser-dimensjonen for å identifisere ytelsesdrag i "den lange halen" (Long Tail).

Nettlesere i appen (In-App Browsers): Trafikk fra Instagram, LinkedIn eller Facebook kjører ofte i begrensede WebViews som oppfører seg annerledes enn den opprinnelige mobilnettleseren.

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