Core/Dash-dimension: Webbläsare

Dimension: Sida & Navigering: URL:er (u)

Dimensionen Webbläsare grupperar prestandadata baserat på den User Agent-sträng som skickas av klienten. Detta gör att du kan granska Core Web Vitals-prestanda genom linsen av den specifika programvara 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 kontra 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 uteslutande in data från användare som valt att delta i Chrome (och vissa Chromium-derivater). 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-snippetet.

För många webbplatser utgör icke-Chrome-webbläsare 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åttspecifik 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.

• Firefox (SpiderMonkey): Firefox hanterar uppgiftsprioritering annorlunda än Chrome. En tung event listener som passerar i Chrome kan orsaka märkbar input delay i Firefox på grund av skillnader i hur huvudtråden utför yielding.
• Safari (JavaScriptCore): uppvisar ofta distinkta beteenden gällande "tap"-latens på mobilen. Hydration-logik som känns omedelbar på Android (Chrome) kan utlösa fördröjningar på iOS på grund av distinkta 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 strategi för bildformat. Du kanske serverar AVIF till Chrome medan du använder en fallback till större JPEG-filer för äldre webbläsarversioner som saknar stöd.
• Priority Hints: Chrome respekterar aggressivt fetchpriority="high". Webbläsare som ignorerar detta attribut behandlar LCP-resursen med standardprioritet, vilket artificiellt blåser upp Load Delay.
• Anslutningsprotokoll: Edge och Firefox kan förhandla HTTP/3 (QUIC)-anslutningar annorlunda 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 sub-pixel-logik.

• Teckensnittsrendering (Gecko kontra Blink): Firefox (Gecko) och Chrome (Blink) renderar teckensnittsbaslinjer och tracking något annorlunda. Om du inte matchar dina mått för fallback-teckensnitt perfekt, kommer textblocket att ändra storlek när webbteckensnittet laddas, vilket orsakar ett skift i en webbläsare men inte i den andra.
• Reservering av rullningslist: Windows-webbläsare (Edge/Firefox/Chrome) reserverar fysiskt utrymme för rullningslister, medan macOS-webbläsare lägger dem ovanpå. Denna olikhet orsakar ofta breddbaserade layoutskift 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ändningsområdet för denna dimension är "Motorvalidering".

• Identifiera avvikelsen: Sortera din tabell för webbläsare efter påverkan 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 OS (t.ex. Edge på Android kontra Edge på Windows).
• Debug: Om Edge är långsam men Chrome är snabb (båda använder Blink), undersök tredjepartstillägg eller säkerhetsprogramvara för företag som är vanlig bland Edge-användare och som injicerar skript i DOM:en. 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 identifiera prestandasänken i "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.

Äldre 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, fatta det strategiska beslutet att slopa stödet för att minska bundle-storleken för moderna användare.