Core/Dash Dimension: Device & Client Capability

Hva disse dimensjonene måler

CoreDash eksponerer to dimensjoner under kategorien Device & Client Capability. De svarer på ulike spørsmål, men utfyller hverandre direkte.

Device Memory (gruppekode m) rapporterer RAM-kategorien nettleseren returnerer fra navigator.deviceMemory. Spesifikasjonen runder bevisst ned til nærmeste potens av to og begrenser resultatet, så du vil se verdier på 0,25, 0,5, 1, 2, 4 eller 8+ GB i stedet for eksakte tall. Denne avrundingen er tilsiktet: den begrenser presisjonen tilgjengelig for fingeravtrykksskript, samtidig som den gir utviklere et brukbart signal.

Client Capability Score (gruppekode ccs) er en sammensatt verdi beregnet av CoreDash fra tre nettlesereksponerte signaler: enhetsminne, navigator.hardwareConcurrency (logiske CPU-kjerner) og den effektive tilkoblingstypen fra Network Information API. Resultatet er én av seks kategorier:

Den sammensatte poengsummen er mer nyttig enn noe enkeltsignal isolert sett. En enhet med 4 GB RAM på en 2G-tilkobling oppfører seg svært forskjellig fra den samme enheten på Wi-Fi. Å kombinere minne, kjerner og tilkoblingstype til én ordinal skala lar deg filtrere og sammenligne ytelsesdata uten å kjøre en separat oppdeling for hver variabel.

Nettleserstøtte og datadekning

navigator.deviceMemory er et Chromium-eksklusivt API. Firefox og Safari eksponerer det ikke, noe som betyr at disse nettleserne alltid rapporterer Unknown (CCS 0) for minnekomponenten. I praksis utgjør Chrome og Chrome-baserte nettlesere hoveddelen av Android-trafikken, og Android-enheter er der lite minne-tilstander konsentrerer seg. Signalet er altså mest tilgjengelig nettopp der det betyr mest.

Device Memory HTTP-headeren (Device-Memory) er en separat mekanisme som lar en server lese den samme verdien fra en Accept-CH-forhandlet forespørsel. CoreDash bruker JavaScript API-et samlet inn ved sidelasttidspunktet, så verdien reiser med RUM-beaconet i stedet for å kreve serversidekonfigurasjon av headere.

Hvorfor enhetskapasitet er viktig for Core Web Vitals

LCP er primært et nettverks- og renderingsproblem. INP er primært et CPU- og minneproblem. Denne distinksjonen er grunnen til at CCS-dimensjonen viser seg tydeligst i INP-data.

Lange oppgaver på hovedtråden blokkerer inputrespons. På en enhet med 1 GB RAM er nettleseren allerede under minnepress før JavaScript-koden din i det hele tatt kjører: mer aggressiv søppelinnsamling, hyppigere fanelukkinger og mindre rom for JIT-kompilering oversettes alle direkte til lengre oppgavevarigheter. Et nettsted som består INP på en moderne telefon med 180 ms kan lett ligge på 400 ms på en Constrained-enhet.

2025 Web Almanac Performance-kapittelet bekrefter trenden: mobile INP-godkjenningsrater når 77 % totalt, men gapet mellom kraftige og rimelige enheter i dette tallet er stort. Omtrent 29 % av mobile nettbrukere er på enheter som er tre ganger mindre kraftige enn et nåværende flaggskip. Disse brukerne er ikke uteliggere i de fleste globale markeder; de er medianbesøkeren.

CLS er mindre følsomt for maskinvareklasse enn INP, men enheter med trege CPU-er kan fortsatt produsere layoutskift når fonter eller sent lastende bilder forårsaker reflows som fullføres etter at nettleseren allerede har forpliktet en ramme.

Hvordan bruke CCS og Device Memory i CoreDash

Den mest produktive arbeidsflyten er å starte med CCS som et filter og deretter bruke Device Memory for å bekrefte hypotesen din.

Åpne først INP-oppdelingen din etter CCS. Hvis din 75. persentil INP er god for Very Capable (CCS 1) og Capable (CCS 2) besøkende, men feiler for Limited (CCS 3) og under, har du en CPU- eller minneflaskehals i stedet for en nettverksflaskehals. Det utelukker en hel kategori av fikser (forhåndsinnlasting, tilkoblingshint, CDN-tuning) og fokuserer oppmerksomheten din på JavaScript-utførelsestid: lange oppgaver, input-handlervekt og tredjepartsskript som kjører ved hver interaksjon.

Filtrer deretter etter Device Memory for å se hvilke RAM-kategorier som gir de verste resultatene. Hvis 1 GB-enheter utgjør en uforholdsmessig stor andel av dårlige INP-poeng, kjenner du terskelen. Skript som er akseptable ved 4 GB kan være kandidater for utsettelse eller fjerning basert på disse dataene alene.

For nettsteder med globale publikum, kombiner CCS med Country-dimensjonen. Sør- og Sørøst-Asia, Afrika sør for Sahara og deler av Latin-Amerika har høye konsentrasjoner av Constrained- og Very Limited-enheter. En CCS-oppdeling filtrert etter land vil vise deg hvor gapet er størst og hjelpe deg med å prioritere hvilket marked du skal adressere først.

Unknown-kategorien (CCS 0) dekker all Firefox- og Safari-trafikk pluss alle sesjoner der API-ene ikke returnerte noen verdi. Ikke ignorer den. På nettsteder med betydelig Firefox- eller Safari-andel kan Unknown representere en fjerdedel eller mer av alle sesjoner. Det betyr ikke at disse brukerne har dårlige enheter; det betyr at signalet var utilgjengelig. Behandle Unknown som et separat segment i stedet for å slå det sammen med grunnlinjen din.

Hva du kan gjøre med dataene

Hvis CCS 3-, 4- eller 5-besøkende utgjør mer enn 15 % av trafikken din og deres INP konsekvent er over 200 ms, er fiksesettet spesifikt:

• Profiler de lengste oppgavene dine på en hastighetsbegrenset enhet i Chrome DevTools. Task Attribution i Performance-panelet vil vise hvilke skript som er ansvarlige.
• Flytt ikke-kritiske tredjepartsskript bak en interaksjons- eller synlighetsutløser slik at de ikke konkurrerer om hovedtråden under det innledende lastevinduet.
• Reduser JavaScript-buntstørrelsen på kritiske stier. Hver kilobyte som parses på en enhet med lite minne koster mer enn på et flaggskip fordi JIT-kompilatoren har mindre plass til å mellomlagre kompilert kode.
• Bruk scheduler.yield() eller setTimeout(0) for å bryte opp lange oppgaver og gi nettleseren en sjanse til å behandle input-hendelser mellom delene.

CoreDash viser CCS- og Device Memory-dimensjonene sammen med alle Core Web Vitals-metrikker slik at du kan bekrefte om en fiks som forbedret INP på avanserte enheter også flyttet tallene for dine Constrained-besøkende, ikke bare dine best-case-brukere.