Core/Dash Dimension: Enhedstype

Dimension: Enhedstype (d)

Dimensionen Enhedstype 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, da mobil og desktop er fundamentalt forskellige computermiljøer. Forskellige CPU'er, forskellige netværksbetingelser, forskellige viewport-størrelser, forskellige browser-motorer.

Hvis du ser på aggregerede 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

Mobilenheder står for cirka 62 % af den globale webtrafik ifølge Statista (2025). Alligevel underpræsterer mobil konsekvent i forhold til 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 kløft på 8 procentpoint.

Kløften eksisterer, fordi mobilenheder står over for tre begrænsninger, som desktops ikke gør:

• CPU throttling: En mellemklasse Android-telefon har cirka 3-5 gange mindre processorkraft end en desktop. JavaScript, der udføres på 50 ms på desktop, kan tage 200 ms på mobil, hvilket skubber INP forbi tærsklen for "good".
• Netværkslatens: Mobilforbindelser (4G/5G) har højere round-trip-tider og større varians end kablede forbindelser. Dette puster TTFB og LCP Load Delay kunstigt op.
• Viewport-størrelse: Mindre skærme ændrer, hvilket element der bliver din LCP. Dit hero-billede på desktop kan skrumpe til under en tekstblok på mobil, hvilket fuldstændigt ændrer optimeringsmålet.

CoreDash fordeling af enhedstyper

På tværs af CoreDash-projekter er den typiske trafikfordeling 65 % mobil og 35 % desktop. E-handelswebsteder 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 i gennemsnit er 2,8 s sammenlignet med 1,9 s på desktop. For INP er kløften endnu større: mobil p75 ligger på omkring 220 ms, mens desktop svinger omkring 120 ms.

Metrikspecifik analyse

Largest Contentful Paint (LCP)

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

Interaction to Next Paint (INP)

Det er her, enhedskløften rammer hårdest. JavaScript event handlers, der føles øjeblikkelige på en desktop i7, kan blokere hovedtråden i over 300 ms på en Snapdragon 665. Filtrer efter mobil, sortér efter INP-påvirkning, og du vil finde de præcise interaktioner, der fejler på rigtige telefoner. Jeg ser dette konstant: Udviklere tester på MacBook Pros og udgiver interaktioner, der er ubrugelige på de enheder, som 65 % af deres brugere faktisk har i hænderne.

Cumulative Layout Shift (CLS)

CLS-forskelle mellem enhedstyper kan normalt spores tilbage til responsivt design. Reklamepladser, der reserverer plads på desktop, kan kollapse eller ændre størrelse på mobil. Font fallback-metrikker, der passer sammen på desktop, forårsager synlige forskydninger på mindre viewports. Webfonte renderes forskelligt på tværs af mobil- og desktopbrowsere, og den fysiske pixeltæthed påvirker sub-pixel-afrunding.

Fejlfindings-workflow

1. Start hver undersøgelse med enhedsfilteret: Før du ser på nogen anden dimension, skal du opdele efter enhedstype. Hvis din aggregerede LCP er 2,5 s, finder du måske desktop på 1,8 s og mobil på 3,1 s. "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 andet filter. Enhedstype + Land afslører, om mobilkløften er global eller koncentreret i regioner med langsommere netværk. Enhedstype + Navigationstype viser, om mobil back-forward-navigationer caches korrekt.

Teknisk tommelfingerregel

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

Enhedstype er ikke et nice-to-have filter. Det er det første spørgsmål, du stiller: "Er dette et mobilproblem eller et desktopproblem?" Enhver optimeringsbeslutning udspringer af det svar.