Core/Dash-dimensjon: Enhetstype

Dimensjon: Enhetstype (d)

Dimensjonen Enhetstype deler Real User Monitoring-dataene dine 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 datamiljøer. Ulike CPU-er, ulike nettverksforhold, ulike visningsområder, ulike nettlesermotorer.

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

Ytelsesgapet på mobil

Mobile enheter står for omtrent 62 % av den globale nettrafikken ifølge Statista (2025). Likevel underpresterer mobil konsekvent sammenlignet med desktop. Ifølge 2025 Web Almanac består bare 48 % av mobil-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 har:

• CPU throttling: En Android-telefon i mellomklassen har omtrent 3-5 ganger mindre prosesseringskraft enn en desktop. JavaScript som kjøres på 50 ms på desktop kan ta 200 ms på mobil, noe som presser INP forbi terskelen for "god".
• Nettverksforsinkelse: Mobilforbindelser (4G/5G) har høyere "round-trip"-tider og mer variasjon enn kablede forbindelser. Dette blåser opp TTFB og LCP Load Delay.
• Størrelse på visningsområdet (viewport): Mindre skjermer endrer hvilket element som blir LCP. Hero-bildet ditt på desktop kan krympe til under en tekstblokk på mobil, og dermed fullstendig endre optimaliseringsmålet.

Fordeling av enhetstyper i CoreDash

På tvers av CoreDash-prosjekter er den typiske trafikkfordelingen 65 % mobil og 35 % desktop. E-handelsnettsteder lener seg tyngre mot mobil (70-75 %), mens B2B SaaS-produkter ofte ser en 50/50-fordeling eller til og med at desktop dominerer.

Ytelsesgapet i CoreDash-data gjenspeiler den globale trenden. p75 LCP på mobil er i gjennomsnitt 2,8 s sammenlignet med 1,9 s på desktop. For INP er gapet enda større: p75 for mobil ligger på rundt 220 ms, mens desktop ligger i nærheten av 120 ms.

Metrikkspesifikk analyse

Largest Contentful Paint (LCP)

Mobil-LCP er nesten alltid verre enn desktop. Hovedårsaken er Load Delay: mobilnettlesere oppdager LCP-bildet senere fordi HTML-en tar lengre tid å ankomme (høyere TTFB), og preload-skanneren konkurrerer om flere ressurser på en tregere CPU. Hvis din desktop-LCP er under 2,0 s, men mobil overstiger 3,0 s, er problemet sjelden selve bildefilen. Det er leveringskjeden.

Interaction to Next Paint (INP)

Det er her enhetsgapet slår hardest ut. JavaScript-hendelseshåndterere som føles umiddelbare på en desktop i7, kan blokkere hovedtråden i over 300 ms på en Snapdragon 665. Filtrer på mobil, sorter etter INP-innvirkning, og du vil finne nøyaktig hvilke interaksjoner som svikter på ekte telefoner. Jeg ser dette hele tiden: utviklere tester på MacBook Pro og lanserer interaksjoner som er ubrukelige på enhetene 65 % av brukerne deres faktisk bruker.

Cumulative Layout Shift (CLS)

Forskjeller i CLS mellom enhetstyper kan vanligvis spores tilbake til responsivt design. Annonseplasser som reserverer plass på desktop, kan kollapse eller endre størrelse på mobil. Font fallback-metrikker som stemmer overens på desktop, forårsaker synlige forskyvninger på mindre visningsområder. Web-fonter gjengis ulikt i mobil- og desktop-nettlesere, og den fysiske pikseltettheten påvirker "sub-pixel"-avrunding.

Arbeidsflyt for feilsøking

1. Start hver undersøkelse med enhetsfilteret: Før du ser på noen annen dimensjon, del opp etter enhetstype. Hvis din samlede LCP er 2,5 s, finner du kanskje desktop på 1,8 s og mobil på 3,1 s. "Problemet" gjelder da utelukkende mobil.
2. Sammenlign distribusjoner, 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, legg til et andre filter. Enhetstype + Land avslører om mobilgapet er globalt eller konsentrert i regioner med tregere nettverk. Enhetstype + Navigasjonstype viser om tilbake/frem-navigasjoner på mobil caches riktig.

Tommelfingerregel for utvikling

• Mobil-LCP under 2,5 s: Dette er terskelen Google bruker for "god". Hvis din desktop består, men mobil feiler, fokuser på å redusere Load Delay (fetchpriority, preload) og TTFB (edge caching, CDN).
• Mobil-INP under 200 ms: Test hver interaktive funksjon på en ekte Android-enhet i mellomklassen. Chrome DevTools CPU throttling (4x) gir en god tilnærming, men testing på ekte enheter er bedre.
• Optimer aldri kun for desktop: Hvis mobiltrafikken din overstiger 50 % (og det gjør den nesten garantert), er det mobilytelsen som er ditt rangeringssignal for søk. Google bruker CrUX-data fra mobil for rangering.

Enhetstype er ikke bare et "kjekt å ha"-filter. Det er det første spørsmålet du stiller: "Er dette et mobilproblem eller et desktop-problem?" Hver eneste beslutning om optimalisering springer ut fra det svaret.