Core/Dash Dimension: Device Type

Dimension: Device Type (d)

Device Type-dimensionen opdeler dine Real User Monitoring-data i to kategorier: mobile og desktop. Dette er det absolut vigtigste første filter i enhver performance-undersøgelse, fordi mobile og desktop er fundamentalt forskellige computermiljøer. Forskellige CPU'er, forskellige netværksforhold, forskellige viewport-størrelser, forskellige browsermotorer.

Hvis du kigger på samlede Core Web Vitals uden at filtrere efter enhedstype, tager du gennemsnittet af to populationer, der næsten intet har til fælles. Det gennemsnit er i bedste fald misvisende.

Den mobile performance-kløft

Mobile enheder står for omkring 62% af den globale webtrafik ifølge Statista (2025). Alligevel klarer mobil sig konsekvent dårligere end desktop. Ifølge 2025 Web Almanac består kun 48% af mobile origins alle tre Core Web Vitals sammenlignet med 56% på desktop. Det er en forskel på 8 procentpoint.

Kløften opstår, fordi mobile enheder er underlagt tre begrænsninger, som desktop ikke er:

• CPU-throttling: En gennemsnitlig Android-telefon har cirka 3-5x mindre processorkraft end en desktop. JavaScript, der afvikles på 50ms på desktop, kan tage 200ms på mobil, hvilket skubber INP forbi grænsen for "good".
• Netværkslatens: Mobile forbindelser (4G/5G) har højere round-trip-tider og større varians end kablede forbindelser. Dette oppuster TTFB og LCP Load Delay.
• Viewport-størrelse: Mindre skærme ændrer, hvilket element der bliver LCP. Dit desktop-hero-billede kan skrumpe til under en tekstblok på mobil, hvilket fuldstændig ændrer optimeringsmålet.

CoreDash Device Type-fordeling

På tværs af CoreDash-projekter er den typiske trafikfordeling 65% mobil og 35% desktop. E-handelssider hælder mere mod mobil (70-75%), mens B2B SaaS-produkter ofte ser en 50/50-fordeling eller endda desktop-dominans.

Performance-kløften i CoreDash-data afspejler den globale tendens. Mobil p75 LCP ligger i gennemsnit på 2,8s sammenlignet med 1,9s på desktop. For INP er kløften endnu større: mobil p75 ligger på omkring 220ms, mens desktop svæver tæt på 120ms.

Metrik-specifik analyse

Largest Contentful Paint (LCP)

Mobil LCP er næsten altid dårligere end desktop. Den primære årsag er Load Delay: mobile browsere opdager LCP-billedet senere, fordi HTML'en tager længere tid om at ankomme (højere TTFB), og preload-scanneren konkurrerer med større ressourcekamp på en langsommere CPU. Hvis din desktop-LCP er under 2,0s, men mobil overstiger 3,0s, er problemet sjældent selve billedfilen. Det er leveringspipelinen.

Interaction to Next Paint (INP)

Det er her, enhedskløften rammer hårdest. JavaScript-event-handlere, der føles øjeblikkelige på en desktop i7, kan blokere main thread i over 300ms på en Snapdragon 665. Filtrer efter mobil, sorter efter INP-påvirkning, og du vil finde de præcise interaktioner, der fejler på rigtige telefoner. Jeg ser det konstant: Udviklere tester på MacBook Pro'er og udruller interaktioner, der er ubrugelige på de enheder, som 65% af deres brugere rent faktisk har med sig.

Cumulative Layout Shift (CLS)

CLS-forskelle mellem enhedstyper kan normalt spores tilbage til responsivt design. Annoncepladser, der reserverer plads på desktop, kan kollapse eller ændre størrelse på mobil. Skrifttypers fallback-metrikker, der passer sammen på desktop, forårsager synlige skift på mindre viewports. Webskrifttyper renderes forskelligt på tværs af mobil- og desktop-browsere, og den fysiske pixel-tæthed påvirker subpixel-afrunding.

Workflow til fejlfinding

1. Start enhver fejlfinding med enhedsfilteret: Før du kigger på nogen anden dimension, skal du opdele efter Device Type. Hvis din samlede LCP er 2,5s, vil du måske finde desktop på 1,8s og mobil på 3,1s. "Problemet" er udelukkende mobilt.
2. Sammenlign fordelinger, ikke kun p75: Tjek fordelingen af good/needs-improvement/poor for hver enhedstype. En desktop med 85% good og en mobil med 45% good fortæller en helt anden historie end p75 alene.
3. Kombiner med andre dimensioner: Når du har isoleret enhedstypen, skal du tilføje et ekstra filter. Device Type + Country afslører, om den mobile kløft er global eller koncentreret i regioner med langsommere netværk. Device Type + Navigation Type viser, om mobile tilbage/frem-navigeringer cachelagres korrekt.

Tekniske tommelfingerregler

• Mobil LCP under 2,5s: Dette er den grænse, Google bruger for "good". Hvis din desktop består, men mobil fejler, så fokuser på at reducere Load Delay (fetchpriority, preload) og TTFB (edge-caching, CDN).
• Mobil INP under 200ms: Test enhver interaktiv funktion på en rigtig Android-enhed i mellemklassen. Chrome DevTools CPU-throttling (4x) tilnærmer sig dette, men test på en rigtig enhed er bedre.
• Optimer aldrig kun til desktop: Hvis din mobile trafik overstiger 50% (og det gør den næsten med sikkerhed), er mobil performance dit signal til søgerangering. Google bruger mobile CrUX-data til rangering.

Device Type er ikke bare et rart filter at have. Det er det første spørgsmål, du stiller: "Er dette et mobil- eller et desktop-problem?" Enhver optimeringsbeslutning udspringer af det svar.