Core/Dash-dimension: Enhets- och klientkapacitet

Vad dessa dimensioner mäter

CoreDash exponerar två dimensioner under kategorin Enhets- och klientkapacitet. De besvarar olika frågor men kompletterar varandra direkt.

Device Memory (gruppkod m) rapporterar den RAM-kategori som webbläsaren returnerar från navigator.deviceMemory. Specifikationen avrundar medvetet nedåt till närmaste tvåpotens och begränsar resultatet, så du kommer att se värden som 0,25, 0,5, 1, 2, 4 eller 8+ GB snarare än exakta siffror. Denna avrundning är avsiktlig: den begränsar precisionen som är tillgänglig för fingeravtrycksskript, samtidigt som den ger utvecklare en användbar signal.

Client Capability Score (gruppkod ccs) är ett sammansatt värde som beräknas av CoreDash från tre webbläsarexponerade signaler: enhetsminne, navigator.hardwareConcurrency (logiska CPU-kärnor) och den effektiva anslutningstypen från Network Information API. Resultatet är en av sex kategorier:

Det sammansatta värdet är mer användbart än någon enskild signal isolerat. En enhet med 4 GB RAM på en 2G-anslutning beter sig väldigt annorlunda jämfört med samma enhet på Wi-Fi. Att kombinera minne, kärnor och anslutningstyp i en enda ordinalskala låter dig filtrera och jämföra prestandadata utan att behöva köra en separat nedbrytning för varje variabel.

Webbläsarstöd och datatäckning

navigator.deviceMemory är ett API exklusivt för Chromium. Firefox och Safari exponerar det inte, vilket innebär att dessa webbläsare alltid rapporterar Okänd (CCS 0) för minneskomponenten. I praktiken står Chrome och Chrome-baserade webbläsare för majoriteten av Android-trafiken, och Android-enheter är där förhållanden med lite minne koncentreras. Så signalen är mest tillgänglig precis där den spelar störst roll.

HTTP-headern för Device Memory (Device-Memory) är en separat mekanism som låter en server läsa samma värde från en Accept-CH-förhandlad förfrågan. CoreDash använder det JavaScript-API som samlas in vid sidladdning, så värdet färdas med RUM-beaconen i stället för att kräva konfiguration av headers på serversidan.

Varför enhetskapacitet spelar roll för Core Web Vitals

LCP är i första hand ett nätverks- och renderproblem. INP är i första hand ett CPU- och minnesproblem. Denna distinktion är anledningen till att CCS-dimensionen framträder tydligast i INP-data.

Långa uppgifter (long tasks) på huvudtråden blockerar inmatningsresponsen. På en enhet med 1 GB RAM är webbläsaren redan under minnestryck innan din JavaScript ens körs: mer aggressiv skräphantering (garbage collection), tätare nedstängningar av flikar och mindre utrymme för JIT-kompilering översätts direkt till längre uppgiftstider. En webbplats som klarar INP på en modern telefon med 180 ms kan enkelt ligga på 400 ms på en Kraftigt begränsad (Constrained) enhet.

Det prestandakapitel som finns i 2025 Web Almanac bekräftar trenden: godkännandegraden för INP på mobiler når 77 % totalt sett, men klyftan mellan högpresterande och enklare enheter i den siffran är stor. Ungefär 29 % av de mobila webbanvändarna använder enheter som är tre gånger svagare än ett nuvarande flaggskepp. Dessa användare är inga undantag på de flesta globala marknader; de är medianbesökaren.

Så använder du CCS och Device Memory i CoreDash

Det mest produktiva arbetsflödet är att börja med CCS som ett filter och sedan använda Device Memory för att bekräfta din hypotes.

Börja med att öppna din INP-nedbrytning efter CCS. Om din INP för den 75:e percentilen är bra för Mycket kapabla (CCS 1) och Kapabla (CCS 2) besökare, men misslyckas för Begränsade (CCS 3) och därunder, har du en CPU- eller minnesflaskhals i stället för en nätverksflaskhals. Det utesluter en hel kategori av åtgärder (preloading, anslutningstips, CDN-justeringar) och riktar i stället din uppmärksamhet mot exekveringstiden för JavaScript: långa uppgifter, tyngden i inmatningshanterare och tredjepartsskript som körs vid varje interaktion.

Filtrera sedan efter Device Memory för att se vilka RAM-kategorier som driver de sämsta resultaten. Om enheter med 1 GB står för en oproportionerligt stor andel av de dåliga INP-poängen känner du till tröskelvärdet. Skript som är acceptabla vid 4 GB kan bli kandidater för att skjutas upp eller tas bort enbart baserat på denna data.

För webbplatser med en global publik kan du para ihop CCS med dimensionen för Land. Marknader i Syd- och Sydostasien, Afrika söder om Sahara och delar av Latinamerika har höga koncentrationer av Kraftigt begränsade (Constrained) och Mycket begränsade (Very Limited) enheter. En CCS-nedbrytning filtrerad på land visar dig var klyftan är som störst och hjälper dig att prioritera vilken marknad du ska ta itu med först.

Kategorin Okänd (CCS 0) täcker all Firefox- och Safari-trafik plus eventuella sessioner där API:erna inte returnerade något värde. Ignorera den inte. På webbplatser med en betydande andel Firefox- eller Safari-användare kan Okänd representera en fjärdedel eller mer av alla sessioner. Det betyder inte att dessa användare har dåliga enheter; det betyder att signalen var otillgänglig. Behandla Okänd som ett separat segment snarare än att baka in det i ditt basvärde.

Vad du ska göra med datan

Om besökare med CCS 3, 4 eller 5 utgör mer än 15 % av din trafik och deras INP konsekvent ligger över 200 ms, är åtgärdslistan specifik:

• Profilera dina längsta uppgifter på en strypt enhet i Chrome DevTools. Task Attribution i prestandapanelen (Performance) visar vilka skript som är ansvariga.
• Flytta icke-kritiska tredjepartsskript bakom en interaktions- eller synlighetsutlösare så att de inte konkurrerar om huvudtråden under det initiala laddningsfönstret.
• Minska storleken på dina JavaScript-bundles för kritiska sökvägar. Varje kilobyte som tolkas på en enhet med lite minne kostar mer än på ett flaggskepp eftersom JIT-kompilatorn har mindre utrymme för att cacha kompilerad kod.
• Använd scheduler.yield() eller setTimeout(0) för att bryta upp långa uppgifter och ge webbläsaren en chans att bearbeta inmatningshändelser mellan kodblocken.

CoreDash synliggör dimensionerna CCS och Device Memory vid sidan av varje mätvärde för Core Web Vitals, så att du kan bekräfta om en åtgärd som förbättrade INP på avancerade enheter också lyfte siffrorna för dina Kraftigt begränsade besökare, och inte bara för användarna med de bästa förutsättningarna.