Core/Dash Dimension: Webbläsare

Dimension: Webbläsare (browser)

Dimensionen Webbläsare grupperar prestandadata baserat på den User Agent-sträng som skickas av klienten. Detta låter dig granska prestanda för Core Web Vitals genom linsen av den specifika programvaran som renderar din applikation (t.ex. Chrome, Firefox, Safari, Edge, Samsung Internet).

Dimensionen Webbläsare isolerar programvarubegränsningar, skillnader i renderingsmotorer (Blink, Gecko, WebKit) och kompatibilitet med tredjepartsskript.

RUM vs. CrUX

Att förstå källan till din data är viktigt för en korrekt teknisk analys.

• CrUX (Chrome User Experience Report): Detta dataset samlar in data uteslutande från användare som har valt att delta på Chrome (och vissa Chromium-derivat). Det exkluderar blint trafik från Firefox (Gecko-motorn) och Safari (WebKit-motorn).
• CoreDash RUM: Samlar in data från varje webbläsare som exekverar JavaScript-kodsnutten.

För många webbplatser representerar andra webbläsare än Chrome 30-50 % av trafiken. Att enbart förlita sig på CrUX skapar en blind fläck: du optimerar för Googles V8-motor samtidigt som du försummar motorerna SpiderMonkey (Firefox) och JavaScriptCore (Safari) som används av ett massivt segment av din publik.

Mätspecifik diagnostik

Olika webbläsarmotorer hanterar resurser, kompilerar JavaScript och beräknar layoutgeometri på olika sätt. Använd denna dimension för att identifiera motorspecifika fel.

Interaction to Next Paint (INP)

INP-problem korrelerar direkt med effektiviteten hos webbläsarens JavaScript-motor och schemaläggning av huvudtråden (main-thread).

• Firefox (SpiderMonkey): Firefox hanterar uppgiftsprioritering annorlunda än Chrome. En tung händelselyssnare (event listener) som passerar i Chrome kan orsaka märkbar inmatningsfördröjning i Firefox på grund av skillnader i hur huvudtråden utför yield.
• Safari (JavaScriptCore): uppvisar ofta distinkta beteenden gällande "tryck"-latens (tap latency) på mobila enheter. Hydreringslogik som känns ögonblicklig på Android (Chrome) kan utlösa fördröjningar på iOS på grund av distinkta modeller för händelsespridning (event propagation).

Largest Contentful Paint (LCP)

LCP-avvikelser signalerar vanligtvis en brist på funktionsparitet eller stöd för moderna optimerings-API:er.

• Formatförhandling: Om Chrome rapporterar ett snabbt LCP men Firefox släpar efter, verifiera din strategi för bildformat. Du kanske serverar AVIF till Chrome medan du använder fallback till större JPEG-bilder för äldre webbläsarversioner som saknar stöd.
• Prioritetsledtrådar (Priority Hints): Chrome respekterar aggressivt fetchpriority="high". Webbläsare som ignorerar detta attribut behandlar LCP-resursen med standardprioritet, vilket på artificiell väg blåser upp laddningsfördröjningen (Load Delay).
• Anslutningsprotokoll: Edge och Firefox kan förhandla HTTP/3-anslutningar (QUIC) på olika sätt i företagsmiljöer eller begränsade nätverksmiljöer, vilket påverkar TTFB-komponenten av LCP.

Cumulative Layout Shift (CLS)

Renderingsmotorer beräknar pixelgeometri med hjälp av distinkt subpixel-logik.

• Typsnittsrendering (Gecko vs. Blink): Firefox (Gecko) och Chrome (Blink) renderar typsnittens baslinjer och teckenavstånd (tracking) något annorlunda. Om du inte matchar måtten på ditt fallback-typsnitt perfekt kommer textblocket att ändra storlek när webbtypsnittet laddas, vilket orsakar en förskjutning i den ena webbläsaren men inte i den andra.
• Reservation för rullningslist: Windows-webbläsare (Edge/Firefox/Chrome) reserverar fysiskt utrymme för rullningslister, medan macOS-webbläsare lägger dem ovanpå. Denna skillnad orsakar ofta breddbaserade layoutförskjutningar som är osynliga under utveckling på en Mac men framträdande för Windows-användare.

Arbetsflöde: Isolera motorspecifika regressioner

Det primära användningsfallet för denna dimension är "Motorvalidering" (Engine Validation).

• Identifiera extremvärdet: Sortera din tabell för Webbläsare efter påverkan (Impact) eller volym. Leta efter en specifik webbläsare (t.ex. Firefox Mobile) som har en betydligt sämre poäng än baslinjen (Chrome Mobile).
• Verifiera miljön: Kontrollera om problemet är strikt relaterat till webbläsaren eller en kombination av webbläsare och operativsystem (t.ex. Edge på Android jämfört med Edge på Windows).
• Felsökning: Om Edge är långsamt men Chrome är snabbt (båda använder Blink), undersök tredjepartstillägg eller säkerhetsprogramvara för företag som är vanliga för Edge-användare och som injicerar skript i DOM.Om Firefox är långsamt, granska din CSS efter icke-standardiserade egenskaper eller layout thrashing som Gecko straffar hårdare än Blink.

Föråldrade och inbäddade webbläsare

Använd dimensionen Webbläsare för att identifiera prestandahinder i "den långa svansen" (Long Tail).

In-App-webbläsare: Trafik från Instagram, LinkedIn eller Facebook körs ofta i begränsade WebViews som beter sig annorlunda än den inbyggda mobila webbläsaren.

Föråldrade versioner: Du kan hitta trafik från föråldrade webbläsarversioner. Om dessa genererar hög INP, konfigurera dina byggverktyg (Babel/PostCSS) för att antingen servera nödvändiga polyfills eller, om volymen är försumbar, ta det strategiska beslutet att slopa stödet för att minska paketstorleken (bundle size) för moderna användare.