Dimension: Device Type (d)
Dimensionen Device Type delar upp din Real User Monitoring-data i två kategorier: mobile och desktop. Detta är det enskilt viktigaste första filtret i varje prestandaundersökning eftersom mobil och skrivbord är fundamentalt olika datormiljöer. Olika CPU:er, olika nätverksförhållanden, olika viewport-storlekar, olika webbläsarmotorer.
Om du tittar på aggregerade Core Web Vitals utan att filtrera efter enhetstyp, tar du ett genomsnitt av två populationer som nästan inte har något gemensamt. Det genomsnittet är i bästa fall missledande.
Mobilens prestandagap
Mobila enheter står för cirka 62 % av den globala webbtrafiken enligt Statista (2025). Ändå underpresterar mobila enheter konsekvent jämfört med skrivbord. Enligt 2025 Web Almanac klarar endast 48 % av mobila ursprung (origins) alla tre Core Web Vitals jämfört med 56 % på skrivbordet. Det är ett gap på 8 procentenheter.
Gapet beror på att mobila enheter står inför tre begränsningar som skrivbord inte gör:
- CPU-strypning: En Android-telefon i mellanklassen har cirka 3–5 gånger mindre processorkraft än en stationär dator. JavaScript som exekveras på 50 ms på skrivbordet kan ta 200 ms på mobilen, vilket pressar INP förbi tröskelvärdet för "bra".
- Nätverkslatenst: Mobila anslutningar (4G\/5G) har högre tider för tur och retur (round-trip times) och större varians än trådbundna anslutningar. Detta ökar TTFB och LCP Load Delay.
- Viewport-storlek: Mindre skärmar ändrar vilket element som blir LCP. Din hjältebild (hero image) på skrivbordet kan krympa under ett textblock på mobilen, vilket helt ändrar optimeringsmålet.
CoreDash-fördelning per enhetstyp
Över CoreDash-projekt är den typiska trafikfördelningen 65 % mobil och 35 % skrivbord. E-handelswebbplatser lutar tyngre mot mobil (70–75 %), medan B2B SaaS-produkter ofta ser en 50\/50-fördelning eller till och med dominans av skrivbord.
Prestandagapet i CoreDash-data speglar den globala trenden. Mobil p75 LCP ligger i genomsnitt på 2,8 s jämfört med 1,9 s på skrivbord. För INP är gapet ännu större: mobil p75 ligger runt 220 ms medan skrivbordet svävar nära 120 ms.
Metrikspecifik analys
Largest Contentful Paint (LCP)
Mobil LCP är nästan alltid sämre än skrivbord. Den främsta orsaken är Load Delay: mobila webbläsare upptäcker LCP-bilden senare eftersom HTML-koden tar längre tid att anlända (högre TTFB) och preload-scannern konkurrerar med mer resurskonflikter på en långsammare CPU. Om din LCP på skrivbordet är under 2,0 s men mobilen överstiger 3,0 s, är problemet sällan själva bildfilen. Det är leveranskedjan (delivery pipeline).
Interaction to Next Paint (INP)
Det är här enhetsgapet slår hårdast. JavaScript-händelsehanterare som känns omedelbara på en i7 på skrivbordet kan blockera huvudtråden i 300 ms+ på en Snapdragon 665. Filtrera efter mobil, sortera efter INP-påverkan, så hittar du de exakta interaktionerna som går sönder på riktiga telefoner. Jag ser detta ständigt: utvecklare testar på MacBook Pro och skickar ut interaktioner som är obrukbara på de enheter som 65 % av deras användare faktiskt bär med sig.
Cumulative Layout Shift (CLS)
CLS-skillnader mellan enhetstyper spåras vanligtvis tillbaka till responsiv design. Annonsplatser som reserverar utrymme på skrivbordet kan kollapsa eller ändra storlek på mobilen. Teckensnittets reservmetrik (font fallback metrics) som matchar på skrivbordet orsakar synliga förskjutningar på mindre viewports. Webbteckensnitt renderas olika på mobila och stationära webbläsare, och den fysiska pixeltätheten påverkar avrundning av subpixlar.
Felsökningsarbetsflöde
- Starta varje undersökning med enhetsfiltret: Innan du tittar på någon annan dimension, dela upp efter Device Type. Om din aggregerade LCP är 2,5 s, kan du hitta skrivbord på 1,8 s och mobil på 3,1 s. "Problemet" är uteslutande mobilt.
- Jämför distributioner, inte bara p75: Kontrollera fördelningen för bra\/behöver förbättras\/dålig för varje enhetstyp. Ett skrivbord med 85 % bra och en mobil med 45 % bra berättar en helt annan historia än enbart p75.
- Kombinera med andra dimensioner: När du väl har isolerat enhetstypen, lägg till ett andra filter. Device Type + Country avslöjar om mobilgapet är globalt eller koncentrerat till regioner med långsammare nätverk. Device Type + Navigation Type visar om mobila bakåt-framåt-navigeringar cachelagras korrekt.
Tumregel för ingenjörer
- Mobil LCP under 2,5 s: Detta är tröskelvärdet Google använder för "bra". Om ditt skrivbord klarar sig men mobilen misslyckas, fokusera på att minska Load Delay (fetchpriority, preload) och TTFB (edge caching, CDN).
- Mobil INP under 200 ms: Testa varje interaktiv funktion på en riktig Android-enhet i mellanklassen. Chrome DevTools CPU-strypning (4x) approximerar detta, men testning på riktiga enheter är bättre.
- Optimera aldrig enbart för skrivbord: Om din mobiltrafik överstiger 50 % (vilket den nästan säkert gör), är mobilprestanda din sökrankningssignal. Google använder mobil CrUX-data för rankning.
Device Type är inte bara ett filter som är "bra att ha". Det är den första frågan du ställer: "Är detta ett mobilproblem eller ett skrivbordsproblem?" Varje optimeringsbeslut utgår från det svaret.