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 gör att du kan granska prestanda för Core Web Vitals utifrån den specifika programvara som renderar din applikation (t.ex. Chrome, Firefox, Safari, Edge, Samsung Internet).

Dimensionen Webbläsare isolerar programvarubegränsningar, skillnader mellan 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): Denna datamängd samlar uteslutande in data från användare som har valt att delta på Chrome (och vissa Chromium-derivat). Den exkluderar blint trafik från Firefox (Gecko-motorn) och Safari (WebKit-motorn).
• CoreDash RUM: Samlar in data från alla webbläsare som kör JavaScript-kodsnutten.

För många webbplatser utgör andra webbläsare än Chrome 30–50 % av trafiken. Att enbart lita på CrUX skapar en blind fläck: du optimerar för Googles V8-motor men försummar motorerna SpiderMonkey (Firefox) och JavaScriptCore (Safari) som används av en stor del av dina besökare.

Metrikspecifik diagnostik

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

Interaction to Next Paint (INP)

INP-problem är direkt kopplade till effektiviteten i webbläsarens JavaScript-motor och main thread-schemaläggning.

• Firefox (SpiderMonkey): Firefox hanterar uppgiftsprioritering annorlunda än Chrome. En tung händelselyssnare som fungerar utan problem i Chrome kan orsaka märkbar inmatningsfördröjning i Firefox på grund av skillnader i hur main thread yieldar.
• Safari (JavaScriptCore): uppvisar ofta avvikande beteende för ”tap”-fördröjning på mobila enheter. Hydreringslogik som känns omedelbar på Android (Chrome) kan utlösa fördröjningar på iOS på grund av annorlunda modeller för händelsepropagering.

Largest Contentful Paint (LCP)

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

• Formatförhandling: Om Chrome rapporterar en snabb LCP men Firefox släpar efter, verifiera din bildformatsstrategi. Du kanske serverar AVIF till Chrome men använder en fallback med större JPEG-bilder för äldre webbläsarversioner som saknar stöd.
• Priority Hints: Chrome respekterar fetchpriority="high" aggressivt. Webbläsare som ignorerar detta attribut behandlar LCP-resursen med standardprioritet, vilket på ett konstgjort sätt ökar laddningsfördröjningen.
• Anslutningsprotokoll: Edge och Firefox kan förhandla HTTP/3-anslutningar (QUIC) annorlunda i företagsnätverk eller begränsade nätverksmiljöer, vilket påverkar TTFB-komponenten för LCP.

Cumulative Layout Shift (CLS)

Renderingsmotorer beräknar pixelgeometri med olika subpixel-logik.

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

Arbetsflöde: Isolera motorspecifika regressioner

Det primära användningsområdet för denna dimension är ”motorvalidering”.

• Identifiera avvikaren: Sortera din webbläsartabell efter Impact eller Volume. Leta efter en specifik webbläsare (t.ex. Firefox Mobile) som har ett betydligt sämre resultat än baslinjen (Chrome Mobile).
• Verifiera miljön: Kontrollera om problemet är strikt relaterat till webbläsaren eller till en kombination av webbläsare och operativsystem (t.ex. Edge på Android vs. Edge på Windows).
• Felsök: Om Edge är långsam men Chrome är snabb (båda använder Blink), undersök tredjepartstillägg eller företagssäkerhetsprogramvara som är vanliga bland Edge-användare och som injicerar skript i DOM.Om Firefox är långsam, granska din CSS efter icke-standardiserade egenskaper eller layout thrashing som Gecko straffar hårdare än Blink.

Äldre och inbäddade webbläsare

Använd dimensionen Webbläsare för att hitta prestandatjuvar 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 fungerar annorlunda än den nativa mobilwebbläsaren.

Äldre versioner: Du kan hitta trafik från föråldrade webbläsarversioner. Om dessa genererar högt INP bör du konfigurera dina byggverktyg (Babel/PostCSS) till att antingen leverera nödvändiga polyfills eller – om volymen är försumbar – ta det strategiska beslutet att sluta ge stöd för att minska bundle-storleken för moderna användare.