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-grupp som webbläsaren returnerar från navigator.deviceMemory. Specifikationen avrundar avsiktligt 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 medveten: den begränsar precisionen för fingerprinting-skript men ger ändå utvecklare en användbar signal.

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

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 till en enda ordinalskala gör att du kan filtrera och jämföra prestandadata utan att behöva gö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 det är på Android-enheter som förhållanden med lite minne är mest koncentrerade. Så signalen är som 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 av samma värde från en Accept-CH-förhandlad begäran. CoreDash använder det JavaScript-API som samlas in vid sidladdningen, så värdet skickas med RUM-beaconen istä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 renderingsproblem. INP är i första hand ett CPU- och minnesproblem. Den distinktionen är anledningen till att CCS-dimensionen syns tydligast i INP-data.

Långa uppgifter (long tasks) på huvudtråden blockerar respons på inmatning. På en enhet med 1 GB RAM är webbläsaren redan under minnestryck innan ditt JavaScript ens körs: mer aggressiv sophantering (garbage collection), mer frekvent avstängning av flikar (tab discards) och mindre marginal för JIT-kompilering översätts direkt till längre uppgiftstider. En webbplats som klarar INP på en modern telefon vid 180 ms kan lätt ligga på 400 ms på en Kraftigt begränsad (Constrained) enhet.

Kapitlet om prestanda i Web Almanac 2025 bekräftar trenden: andelen som klarar INP på mobil når totalt 77 %, men klyftan mellan kraftfulla enheter och lågbudgetenheter i den siffran är stor. Ungefär 29 % av de mobila webbanvändarna sitter på enheter som är tre gånger mindre kraftfulla än ett aktuellt flaggskepp. Dessa användare är inga undantag på de flesta globala marknader; de utgör medianbesökaren.

CLS är mindre känsligt för hårdvaruklass än INP, men enheter med långsamma processorer kan fortfarande generera layoutskiften när typsnitt eller sent inlästa bilder orsakar omritningar (reflows) som slutförs efter att webbläsaren redan har renderat en bildruta.

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, så har du en CPU- eller minnesflaskhals snarare än en nätverksflaskhals. Det utesluter en hel kategori av åtgärder (preloading, anslutningstips, CDN-optimering) och riktar din uppmärksamhet mot exekveringstiden för JavaScript: långa uppgifter (long tasks), tyngden på inmatningshanterare (input handlers) och tredjepartsskript som körs vid varje interaktion.

Filtrera sedan efter Device Memory för att se vilka RAM-grupper 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 (deferral) eller tas bort enbart baserat på den datan.

För webbplatser med en global publik bör du para ihop CCS med dimensionen Land. Marknaderna 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 störst och hjälper dig att prioritera vilken marknad du ska ta itu med först.

Den Okända gruppen (CCS 0) täcker all trafik från Firefox och Safari plus alla 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 istället för att baka in det i din baslinje.

Vad du gör med datan

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

• Profilera dina längsta uppgifter (longest tasks) på en strypt (throttled) enhet i Chrome DevTools. Task Attribution i Performance-panelen visar vilka skript som är ansvariga.
• Flytta icke-kritiska tredjepartsskript bakom en interaktions- eller synlighetstrigger så att de inte konkurrerar om huvudtråden under det inledande laddningsfönstret.
• Minska storleken på JavaScript-bundles på kritiska sökvägar (critical paths). Varje kilobyte som parsas på en enhet med lite minne kostar mer än på ett flaggskepp eftersom JIT-kompilatorn har mindre utrymme 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 (Constrained) besökare, och inte bara för dina användare med bästa förutsättningar.