Dimension: Browser (browser)
Browser-dimensionen grupperer performancedata baseret på den User Agent-streng, som klienten sender. Dette giver dig mulighed for at revidere Core Web Vitals-performance gennem linsen af den specifikke software, der renderer din applikation (f.eks. Chrome, Firefox, Safari, Edge, Samsung Internet).
Browser-dimensionen isolerer softwarebegrænsninger, forskelle i browsermotorer (Blink, Gecko, WebKit) og kompatibilitet med tredjepartsskripts.
RUM mod CrUX
Forståelse af kilden til dine data er vigtig for nøjagtig ingeniørmæssig analyse.
- CrUX (Chrome User Experience Report): Dette datasæt indsamler udelukkende data fra brugere på Chrome (og visse Chromium-derivater), der har givet samtykke. Det ekskluderer trafik fra Firefox (Gecko-motor) and Safari (WebKit-motor).
- CoreDash RUM: Indsamler data fra enhver browser, der eksekverer JavaScript-kodestumpen.
For mange websteder udgør ikke-Chrome-browsere 30-50 % af trafikken. At stole udelukkende på CrUX skaber en blind vinkel: du optimerer til Googles V8-motor, mens du ignorerer SpiderMonkey- (Firefox) og JavaScriptCore-motorerne (Safari), som bruges af en massiv del af dit publikum.Metrikspecifik diagnosticering
Forskellige browsermotorer administrerer ressourcer, kompilerer JavaScript og beregner layout-geometri forskelligt. Brug denne dimension til at udpege motorspecifikke fejl.
Interaction to Next Paint (INP)
INP-problemer korrelerer direkte med effektiviteten af browserens JavaScript-motor og planlægning af hovedtråden (main-thread).
- Firefox (SpiderMonkey): Firefox håndterer prioritering af opgaver anderledes end Chrome. En tung event listener, der fungerer i Chrome, kan forårsage mærkbar input-forsinkelse i Firefox på grund af forskelle i, hvordan hovedtråden afgiver kontrollen (yield).
- Safari (JavaScriptCore): udviser ofte specifik adfærd vedrørende "tap"-latenstid på mobil. Hydreringslogik, der føles øjeblikkelig på Android (Chrome), kan udløse forsinkelser på iOS på grund af særskilte modeller for hændelsesudbredelse (event propagation).
Largest Contentful Paint (LCP)
LCP-afvigelser signalerer normalt manglende funktionslighed eller manglende understøttelse af moderne optimerings-API'er.
- Formatforhandling (Format Negotiation): Hvis Chrome rapporterer en hurtig LCP, men Firefox sakker bagud, skal du verificere din strategi for billedformater. Du serverer muligvis AVIF til Chrome, mens du falder tilbage (fallback) på større JPEG-filer til ældre browserversioner, der mangler understøttelse.
- Priority Hints: Chrome respekterer aggressivt fetchpriority="high". Browsere, der ignorerer denne attribut, behandler LCP-ressourcen med standardprioritet, hvilket kunstigt øger Load Delay.
- Forbindelsesprotokoller: Edge og Firefox kan forhandle HTTP\/3 (QUIC)-forbindelser anderledes i virksomhedsnetværk eller begrænsede netværksmiljøer, hvilket påvirker TTFB-komponenten i LCP.
Cumulative Layout Shift (CLS)
Browsermotorer beregner pixelgeometri ved hjælp af særskilt sub-pixel-logik.
- Skrifttype-rendering (Gecko mod Blink): Firefox (Gecko) and Chrome (Blink) renderer skrifttypers basislinjer og spatiereing en smule forskelligt. Hvis du ikke matcher dine fallback-skrifttypemetrikker perfekt, vil tekstblokken ændre størrelse, når webskrifttypen indlæses, hvilket forårsager et skift i én browser, men ikke i den anden.
- Pladsreservation til rullepanel: Windows-browsere (Edge\/Firefox\/Chrome) reserverer fysisk plads til rullepaneler, mens macOS-browsere lægger dem ovenpå. Denne forskel forårsager ofte breddebaserede layout-skift, der er usynlige under udvikling på en Mac, men fremtrædende for Windows-brugere.
Arbejdsgang: Isolering af motorspecifikke performance-forringelser
Den primære anvendelse af denne dimension er "Motorvalidering".
- Identificer afvigeren: Sorter din Browser-tabel efter Effekt (Impact) eller Volumen. Led efter en specifik browser (f.eks. Firefox Mobile), der har en væsentligt dårligere score end udgangspunktet (Chrome Mobile).
- Verificer miljøet: Tjek om problemet er strengt relateret til browseren eller en kombination af browser og OS (f.eks. Edge på Android mod Edge på Windows).
- Debug: Hvis Edge er langsom, men Chrome er hurtig (begge bruger Blink), skal du undersøge tredjepartsudvidelser eller virksomhedssikkerhedssoftware, der er almindelig for Edge-brugere, og som injicerer skripts i DOM'en. Hvis Firefox er langsom, skal du gennemgå din CSS for ikke-standardiserede egenskaber eller layout thrashing, som Gecko straffer hårdere end Blink.
Ældre og indlejrede browsere
Brug Browser-dimensionen til at identificere "Long Tail"-performance-belastninger.
In-App browsere: Trafik fra Instagram, LinkedIn eller Facebook kører ofte i begrænsede WebViews, der opfører sig anderledes end den indfødte mobilbrowser.Ældre versioner: Du kan finde trafik fra forældede browserversioner. Hvis disse genererer høj INP, skal du konfigurere dine build-værktøjer (Babel\/PostCSS) til enten at servere nødvendige polyfills eller, hvis volumen er ubetydelig, tage den strategiske beslutning om at droppe understøttelsen for at reducere pakke-størrelsen for moderne brugere.
[include]sidebarcoredash.html[\/include]