Core/Dash Dimension: Browser

Dimension: Browser (browser)

Browser-dimensionen grupperer performance-data baseret på den User Agent-streng, som klienten sender. 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-motorer (Blink, Gecko, WebKit) og kompatibilitet med tredjeparts-scripts.

RUM vs. CrUX

Det er vigtigt at forstå kilden til dine data for at kunne foretage en nøjagtig ingeniørmæssig analyse.

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

For mange websites udgør ikke-Chrome-browsere 30-50% af trafikken. At stole udelukkende på CrUX skaber en blind vinkel: du optimerer for Googles V8-motor, mens du negligerer SpiderMonkey (Firefox) og JavaScriptCore (Safari)-motorerne, som bruges af et massivt segment af dit publikum.

Metrik-specifik diagnostik

Forskellige browser-motorer håndterer ressourcer, kompilerer JavaScript og beregner layoutgeometri forskelligt. Brug denne dimension til at lokalisere motorspecifikke fejl.

Interaction to Next Paint (INP)

INP-problemer korrelerer direkte med effektiviteten af browserens JavaScript-motor og main thread-planlægning.

• Firefox (SpiderMonkey): Firefox håndterer opgaveprioritering anderledes end Chrome. En tung event listener, der passerer i Chrome, kan forårsage mærkbar inputforsinkelse i Firefox på grund af forskelle i, hvordan the main thread yielder.
• Safari (JavaScriptCore): udviser ofte distinkt adfærd med hensyn til "tap"-forsinkelse på mobilen. Hydration-logik, der føles øjeblikkelig på Android (Chrome), kan udløse forsinkelser på iOS på grund af forskellige modeller for hændelsesudbredelse.

Largest Contentful Paint (LCP)

LCP-uoverensstemmelser signalerer normalt en mangel på funktionsparitet eller understøttelse af moderne optimerings-API'er.

• Formatforhandling: Hvis Chrome rapporterer en hurtig LCP, men Firefox halter efter, skal du verificere din billedformat-strategi. Du serverer muligvis AVIF til Chrome, mens du bruger større JPEG'er som fallback 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 puster Load Delay op.
• 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-motorer beregner pixelgeometri ved hjælp af distinkt sub-pixel logik.

• Skrifttype-rendering (Gecko vs. Blink): Firefox (Gecko) og Chrome (Blink) renderer font baselines og tracking lidt forskelligt. Hvis du ikke matcher dine fallback-skrifttype-metrikker perfekt, vil tekstblokken ændre størrelse, når web-skrifttypen indlæses, hvilket forårsager et skift i den ene browser, men ikke i den anden.
• Scrollbar-reservation: Windows-browsere (Edge/Firefox/Chrome) reserverer fysisk plads til scrollbars, hvorimod macOS-browsere lægger dem ovenpå (overlay). Denne forskel forårsager ofte breddebaserede layoutskift, der er usynlige under udvikling på en Mac, men fremtrædende for Windows-brugere.

Workflow: Isolering af motorspecifikke regressioner

Den primære use-case for denne dimension er "Motorvalidering."

• Identificer outlier'en: Sortér din Browser-tabel efter Impact eller Volume. Se efter en specifik browser (f.eks. Firefox Mobile), der har en markant dårligere score end basislinjen (Chrome Mobile).
• Bekræft miljøet: Kontrollér, 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 fælles for Edge-brugere, der injicerer scripts i DOM'en. Hvis Firefox er langsom, skal du auditere din CSS for ikke-standardiserede properties 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 native mobile browser.

Æ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 mængden er ubetydelig, træffe den strategiske beslutning om at droppe understøttelsen for at reducere bundle-størrelsen for moderne brugere.