Core/Dash-dimensjon: Enhetstype

Dimensjon: Enhetstype (d)

Dimensjonen Enhetstype splitter dine Real User Monitoring-data i to kategorier: mobile og desktop. Dette er det desidert viktigste første filteret i enhver ytelsesundersøkelse fordi mobil og desktop er fundamentalt forskjellige databehandlingsmiljøer. Ulike CPU-er, ulike nettverksforhold, ulike viewport-størrelser, ulike nettlesermotorer.

Hvis du ser på aggregerte Core Web Vitals uten å filtrere på enhetstype, regner du ut gjennomsnittet for to populasjoner som nesten ikke har noe til felles. Det gjennomsnittet er i beste fall misvisende.

Ytelsesgapet på mobil

Mobile enheter står for omtrent 62 % av den globale webtrafikken ifølge Statista (2025). Likevel leverer mobil konsekvent dårligere enn desktop. Ifølge 2025 Web Almanac passerer bare 48 % av mobile origins alle tre Core Web Vitals, sammenlignet med 56 % på desktop. Det er et gap på 8 prosentpoeng.

Gapet eksisterer fordi mobile enheter møter tre begrensninger som desktop ikke gjør:

• CPU-throttling: En mellomklasse Android-telefon har omtrent 3–5x mindre prosesseringskraft enn en desktop. JavaScript som kjører på 50 ms på desktop, kan ta 200 ms på mobil, noe som skyver INP forbi grensen for «god».
• Nettverkslatens: Mobilforbindelser (4G/5G) har høyere tur-retur-tider og mer variasjon enn kablede forbindelser. Dette blåser opp TTFB og LCP Load Delay.
• Viewport-størrelse: Mindre skjermer endrer hvilket element som blir LCP-en. Hero-bildet på desktop kan krympe til under en tekstblokk på mobil, noe som endrer optimaliseringsmålet fullstendig.

Enhetstypefordeling i CoreDash

På tvers av CoreDash-prosjekter er den typiske trafikksplitten 65 % mobil og 35 % desktop. E-handelssider har ofte en enda høyere mobilandel (70–75 %), mens B2B SaaS-produkter ofte ser en 50/50-fordeling eller til og med at desktop dominerer.

Ytelsesgapet i CoreDash-dataene speiler den globale trenden. Mobil p75 LCP har et snitt på 2,8 s sammenlignet med 1,9 s på desktop. For INP er gapet enda større: mobil p75 ligger rundt 220 ms, mens desktop ligger rundt 120 ms.

Metrikkspesifikk analyse

Largest Contentful Paint (LCP)

LCP på mobil er nesten alltid dårligere enn på desktop. Hovedårsaken er Load Delay: mobilnettlesere oppdager LCP-bildet senere fordi HTML-en bruker lengre tid på å komme frem (høyere TTFB), og preload-skanneren må konkurrere om begrensede ressurser på en tregere CPU. Hvis LCP-en på desktop er under 2,0 s, men mobil overskrider 3,0 s, er problemet sjelden selve bildefilen. Det er leveringskjeden.

Interaction to Next Paint (INP)

Det er her enhetsgapet rammer hardest. JavaScript-event-håndterere som føles lynraske på en desktop i7, kan blokkere main thread i over 300 ms på en Snapdragon 665. Filtrer på mobil, sorter etter INP-påvirkning, og du finner nøyaktig hvilke interaksjoner som svikter på ekte telefoner. Jeg ser dette konstant: utviklere tester på MacBook Pro-er og ruller ut interaksjoner som er ubrukelige på enhetene 65 % av brukerne faktisk bruker.

Cumulative Layout Shift (CLS)

CLS-forskjeller mellom enhetstyper skyldes vanligvis responsivt design. Annonseplasser som reserverer plass på desktop, kan kollapse eller endre størrelse på mobil. Font-fallback-metrikker som samstemmer på desktop, forårsaker synlige skift i mindre viewports. Web-fonter rendres ulikt på mobil og desktop, og den fysiske pikseltettheten påvirker sub-piksel-avrunding.

Arbeidsflyt for feilsøking

1. Start enhver undersøkelse med enhetsfilteret: Før du ser på noen annen dimensjon, splitt etter Enhetstype. Hvis den aggregerte LCP-en din er 2,5 s, finner du kanskje desktop på 1,8 s og mobil på 3,1 s. «Problemet» ligger utelukkende på mobil.
2. Sammenlign fordelinger, ikke bare p75: Sjekk fordelingen av god/trenger forbedring/dårlig for hver enhetstype. En desktop med 85 % god og en mobil med 45 % god forteller en helt annen historie enn p75 alene.
3. Kombiner med andre dimensjoner: Når du har isolert enhetstypen, legger du til et filter til. Enhetstype + Land avslører om mobilgapet er globalt eller konsentrert i regioner med tregere nettverk. Enhetstype + Navigasjonstype viser om tilbake/frem-navigeringer på mobil caches riktig.

Tekniske tommelfingerregler

• Mobil LCP under 2,5 s: Dette er grensen Google bruker for «god». Hvis desktop passerer, men mobil feiler, må du fokusere på å redusere Load Delay (fetchpriority, preload) og TTFB (edge-caching, CDN).
• Mobil INP under 200 ms: Test hver interaktive funksjon på en ekte mellomklasse Android-enhet. Chrome DevTools CPU throttling (4x) gir en tilnærming, men testing på ekte enheter er bedre.
• Aldri optimaliser kun for desktop: Hvis mobiltrafikken din overstiger 50 % (noe den nesten sikkert gjør), er mobil ytelse ditt søkerangeringssignal. Google bruker mobile CrUX-data til rangering.

Enhetstype er ikke et kjekt-å-ha-filter. Det er det første spørsmålet du stiller: «Er dette et mobilproblem eller et desktop-problem?» Alle optimaliseringsbeslutninger tas med utgangspunkt i det svaret.