Core/Dash Dimension: Browser

Dimension: Page & Navigation: URLs (u)

Browser-dimensionen grupperer performance-data baseret på User Agent-strengen sendt af klienten. Dette giver dig mulighed for at auditere 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 rendering engines (Blink, Gecko, WebKit) og kompatibilitet med tredjeparts-scripts.

RUM vs. CrUX

Forståelse af kilden til dine data er vigtig for nøjagtig teknisk analyse.

• CrUX (Chrome User Experience Report): Dette datasæt indsamler udelukkende data fra opt-in brugere på Chrome (og visse Chromium-derivater). Det ekskluderer blindt trafik fra Firefox (Gecko engine) og Safari (WebKit engine).
• CoreDash RUM: Indsamler data fra enhver browser, der eksekverer JavaScript-snippeten.

For mange websites udgør non-Chrome browsere 30-50% af trafikken. At stole udelukkende på CrUX skaber en blind vinkel: du optimerer til Googles V8 engine, mens du ignorerer SpiderMonkey (Firefox) og JavaScriptCore (Safari) engines, der bruges af et massivt segment af dit publikum.

Metric-specifik diagnostik

Forskellige browser engines håndterer ressourcer, kompilerer JavaScript og beregner layout-geometri forskelligt. Brug denne dimension til at udpege engine-specifikke fejl.

Interaction to Next Paint (INP)

INP-problemer korrelerer direkte med effektiviteten af browserens JavaScript engine og main-thread scheduling.

• Firefox (SpiderMonkey): Firefox håndterer opgaveprioritering anderledes end Chrome. En tung event listener, der passerer i Chrome, kan forårsage mærkbar input delay i Firefox på grund af forskelle i, hvordan main thread yielder.
• Safari (JavaScriptCore): udviser ofte særskilt adfærd vedrørende "tap"-latens på mobil. Hydration-logik, der føles øjeblikkelig på Android (Chrome), kan udløse forsinkelser på iOS på grund af forskellige event propagation-modeller.

Largest Contentful Paint (LCP)

LCP-uoverensstemmelser signalerer normalt manglende feature parity eller understøttelse af moderne optimerings-API'er.

• Formatforhandling: Hvis Chrome rapporterer en hurtig LCP, men Firefox halter bagefter, skal du verificere din billedformatstrategi. Du serverer muligvis AVIF til Chrome, mens du bruger fallback til større JPEG'er for æ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 oppuster Load Delay.
• Forbindelsesprotokoller: Edge og Firefox kan forhandle HTTP/3 (QUIC)-forbindelser forskelligt i virksomheds- eller begrænsede netværksmiljøer, hvilket påvirker TTFB-komponenten af LCP.

Cumulative Layout Shift (CLS)

Rendering engines beregner pixelgeometri ved hjælp af særskilt sub-pixel logik.

• Font Rendering (Gecko vs. Blink): Firefox (Gecko) og Chrome (Blink) renderer font baselines og tracking en smule forskelligt. Hvis du ikke matcher dine fallback font metrics perfekt, vil tekstblokken ændre størrelse, når web fonten indlæses, hvilket forårsager et shift i den ene browser, men ikke den anden.
• Scrollbar Reservation: Windows-browsere (Edge/Firefox/Chrome) reserverer fysisk plads til scrollbars, hvorimod macOS-browsere lægger dem ovenpå (overlay). Denne ulighed forårsager ofte breddebaserede layout shifts, der er usynlige under udvikling på en Mac, men fremtrædende for Windows-brugere.

Workflow: Isolering af engine-specifikke regressioner

Den primære use case for denne dimension er "Engine Validation".

• Identificer afvigeren: Sorter din Browser-tabel efter Impact eller Volume. Kig efter en specifik browser (f.eks. Firefox Mobile), der har en markant dårligere score end baseline (Chrome Mobile).
• Verificer miljøet: Tjek, om problemet udelukkende er relateret til browseren eller en kombination af browser og OS (f.eks. Edge på Android vs. Edge på Windows).
• Debug: Hvis Edge er langsom, men Chrome er hurtig (begge bruger Blink), skal du undersøge tredjepartsudvidelser eller enterprise-sikkerhedssoftware, der er almindelig for Edge-brugere, og som injicerer scripts i DOM'en. Hvis Firefox er langsom, skal du auditere din CSS for ikke-standard properties eller layout thrashing, som Gecko straffer hårdere end Blink.

Legacy og Embedded Browsers

Brug Browser-dimensionen til at identificere "Long Tail" performance-drags.

In-App Browsers: Trafik fra Instagram, LinkedIn eller Facebook kører ofte i begrænsede WebViews, der opfører sig anderledes end den native mobilbrowser.

Legacy Versioner: Du kan finde trafik fra forældede browserversioner. Hvis disse genererer høj INP, skal du konfigurere dine build tools (Babel/PostCSS) til enten at servere nødvendige polyfills eller, hvis volumen er ubetydelig, træffe den strategiske beslutning om at droppe support for at reducere bundle size for moderne brugere.