Core/Dash-dimension: Enhetstyp

Dimension: Enhetstyp (d)

Dimensionen Enhetstyp delar upp din RUM-data (Real User Monitoring) i två kategorier: mobile och desktop. Detta är det enskilt viktigaste första filtret i alla prestandaundersökningar eftersom mobil och desktop är fundamentalt olika datormiljöer. Olika processorer, olika nätverksförhållanden, olika storlekar på visningsområden och olika webbläsarmotorer.

Om du tittar på aggregerade Core Web Vitals utan att filtrera på enhetstyp så skapar du ett genomsnitt av två populationer som nästan inte har någonting gemensamt. Det genomsnittet är i bästa fall missvisande.

Prestandagapet på mobiler

Mobila enheter står för ungefär 62 % av den globala webbtrafiken enligt Statista (2025). Ändå underpresterar mobiler konsekvent jämfört med desktop. Enligt 2025 Web Almanac klarar endast 48 % av alla mobila källor (origins) alla tre Core Web Vitals, jämfört med 56 % på desktop. Det är ett gap på 8 procentenheter.

Gapet existerar eftersom mobila enheter möter tre begränsningar som desktop inte gör:

• CPU-strypning (throttling): En mellanklass-Android-telefon har ungefär 3–5 gånger mindre processorkraft än en desktop-dator. JavaScript som exekveras på 50 ms på desktop kan ta 200 ms på en mobil, vilket pressar INP förbi tröskelvärdet för "bra".
• Nätverkslatens: Mobila uppkopplingar (4G/5G) har högre svarstider (round-trip times) och mer varians än trådbundna anslutningar. Detta blåser upp TTFB och LCP Load Delay.
• Storlek på visningsområdet (Viewport): Mindre skärmar förändrar vilket element som blir LCP. Din desktop-hjältebild kanske krymper och hamnar under ett textblock på mobilen, vilket helt förändrar vad som behöver optimeras.

CoreDash-fördelning av enhetstyper

Tvärs över CoreDash-projekt är den typiska trafikfördelningen 65 % mobil och 35 % desktop. E-handelssajter lutar kraftigare mot mobil (70–75 %), medan B2B SaaS-produkter ofta ser en 50/50-fördelning eller till och med desktop-dominans.

Prestandagapet i CoreDash-data speglar den globala trenden. Mobilt p75-LCP snittar på 2,8 sekunder jämfört med 1,9 sekunder på desktop. För INP är gapet ännu större: mobilt p75 ligger runt 220 ms medan desktop svävar nära 120 ms.

Mätvärdesspecifik analys

Largest Contentful Paint (LCP)

Mobil-LCP är nästan alltid sämre än desktop. Den primära 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-skannern konkurrerar mer om resurser på en långsammare CPU. Om din desktop-LCP är under 2,0 s men mobilen överstiger 3,0 s är problemet sällan själva bildfilen. Det är leveranskedjan.

Interaction to Next Paint (INP)

Det är här enhetsgapet slår hårdast. Händelsehanterare i JavaScript som känns ögonblickliga på en stationär i7-processor kan blockera huvudtråden i mer än 300 ms på en Snapdragon 665. Filtrera på mobil, sortera på INP-påverkan, och du kommer att hitta exakt de interaktioner som går sönder på riktiga telefoner. Jag ser detta konstant: utvecklare testar på MacBook Pro och levererar interaktioner som är oanvändbara på de enheter som 65 % av deras användare faktiskt bär med sig.

Cumulative Layout Shift (CLS)

CLS-skillnader mellan enhetstyper kan vanligtvis spåras tillbaka till responsiv design. Annonsutrymmen som reserverar plats på desktop kan kollapsa eller ändra storlek på mobilen. Font fallback-mätvärden som linjerar perfekt på desktop orsakar synliga skiften i mindre visningsområden. Webbtypsnitt renderas olika i mobila och stationära webbläsare, och den fysiska pixeltätheten påverkar underpixelsavrundning.

Arbetsflöde för felsökning

1. Starta varje undersökning med enhetsfiltret: Innan du tittar på någon annan dimension, dela upp på Enhetstyp. Om din aggregerade LCP är 2,5 s kanske du upptäcker att desktop ligger på 1,8 s och mobil på 3,1 s. Då är "problemet" uteslutande mobilt.
2. Jämför distributioner, inte bara p75: Kontrollera fördelningen av bra/behöver-förbättras/dålig för varje enhetstyp. En desktop med 85 % bra och en mobil med 45 % bra berättar en helt annan historia än enbart p75.
3. Kombinera med andra dimensioner: När du har isolerat enhetstypen, lägg till ett andra filter. Enhetstyp + Land avslöjar om mobilgapet är globalt eller koncentrerat till regioner med långsammare nätverk. Enhetstyp + Navigationstyp visar om mobila bakåt-framåt-navigeringar cachelagras korrekt.

Tumregler för tekniker

• Mobil-LCP under 2,5 s: Detta är tröskelvärdet Google använder för "bra". Om din desktop klarar sig men mobilen misslyckas, fokusera på att minska Load Delay (fetchpriority, preload) och TTFB (edge-cachning, CDN).
• Mobil-INP under 200 ms: Testa varje interaktiv funktion på en riktig mellanklass-Android-enhet. CPU-strypning (4x) i Chrome DevTools ger en ungefärlig bild av detta, men testning på riktiga enheter är bättre.
• Optimera aldrig enbart för desktop: Om din mobila trafik överstiger 50 % (och det gör den nästan säkert), så är mobilprestandan din rankningssignal för sök. Google använder mobil CrUX-data för rankning.

Enhetstyp är inte ett filter som bara är "bra att ha". Det är den första frågan du ställer dig: "Är det här ett mobilproblem eller ett desktop-problem?" Varje optimeringsbeslut härstammar från det svaret.