Core/Dash-dimension: Device & Client Capability

Hvad disse dimensioner måler

CoreDash udstiller to dimensioner under kategorien Device & Client Capability. De besvarer forskellige spørgsmål, men supplerer hinanden direkte.

Device Memory (gruppekode m) rapporterer den RAM-kategori, browseren returnerer fra navigator.deviceMemory. Specifikationen runder bevidst ned til den nærmeste potens af to og begrænser resultatet. Derfor vil du se værdier på 0,25, 0,5, 1, 2, 4 eller 8+ GB i stedet for nøjagtige tal. Afrundingen er tilsigtet. Den begrænser den præcision, der er tilgængelig for fingerprinting-scripts, men giver stadig udviklere et brugbart signal.

Client Capability Score (gruppekode ccs) er en sammensat score, som CoreDash beregner ud fra tre signaler, browseren udstiller: enhedens hukommelse, navigator.hardwareConcurrency (logiske CPU-kerner) og den effektive forbindelsestype fra Network Information API'et. Resultatet er én af seks kategorier:

Den sammensatte score er mere brugbar end de enkelte signaler i sig selv. En enhed med 4 GB RAM på en 2G-forbindelse opfører sig helt anderledes end den samme enhed på Wi-Fi. Ved at kombinere hukommelse, CPU-kerner og forbindelsestype i én ordinalskala kan du filtrere og sammenligne ydeevnedata. Du slipper for at køre en separat opdeling for hver variabel.

Browserunderstøttelse og datadækning

navigator.deviceMemory er et API, der kun findes i Chromium. Firefox og Safari udstiller det ikke. Derfor rapporterer disse browsere altid Ukendt (CCS 0) for hukommelseskomponenten. I praksis står Chrome og Chrome-baserede browsere for størstedelen af Android-trafikken, og det er på Android-enheder, at mangel på hukommelse koncentrerer sig. Signalet er derfor mest tilgængeligt der, hvor det betyder mest.

Device Memory HTTP-headeren (Device-Memory) er en separat mekanisme, der gør det muligt for en server at læse den samme værdi fra en Accept-CH-forhandlet forespørgsel. CoreDash bruger JavaScript-API'et, som indsamles under sideindlæsningen. Værdien sendes derfor med dit RUM-beacon. Du slipper for at konfigurere headere på serveren.

Hvorfor enhedskapacitet betyder noget for Core Web Vitals

LCP er primært et netværks- og renderingsproblem. INP er primært et CPU- og hukommelsesproblem. Den forskel er grunden til, at CCS-dimensionen træder tydeligst frem i INP-data.

Long tasks på main thread blokerer for input-respons. På en enhed med 1 GB RAM er browseren allerede under hukommelsespres, før dit JavaScript overhovedet kører. Mere aggressiv garbage collection, hyppigere tab-discards og mindre plads til JIT-kompilering fører direkte til længere task-varigheder. Et site, der klarer INP på en moderne telefon på 180 ms, kan nemt ligge på 400 ms på en kritisk begrænset enhed.

Performance-kapitlet i Web Almanac 2025 bekræfter tendensen: Beståelsesraten for mobil INP når samlet set 77 %, men forskellen på kraftige og svage enheder er stor. Cirka 29 % af de mobile webbrugere bruger enheder, der er tre gange mindre kraftfulde end et aktuelt flagskib. Disse brugere er ikke outliers på de fleste globale markeder – de er median-besøgende.

CLS is less sensitive to hardware class than INP, but devices with slow CPUs can still produce layout shifts when fonts or late-loading images cause reflows that complete after the browser has already committed a frame.

Sådan bruger du CCS og Device Memory i CoreDash

Den mest effektive arbejdsgang er at starte med CCS som filter og derefter bruge Device Memory til at bekræfte din hypotese.

Start med at åbne din INP-opdeling efter CCS. Hvis din 75. percentil for INP er god for besøgende i kategorierne Meget kraftig (CCS 1) og Kraftig (CCS 2), men fejler for Begrænset (CCS 3) og derunder, har du en CPU- eller hukommelsesflaskehals frem for en netværksflaskehals. Det udelukker en hel kategori af optimeringer som preloading, connection hints og CDN-tuning. Ret i stedet fokus mod JavaScript-afviklingstid: long tasks, tunge input-handlere og tredjepartsscripts, der kører ved hver interaktion.

Filtrer derefter efter Device Memory for at se, hvilke RAM-kategorier der trækker resultaterne mest ned. Hvis enheder med 1 GB står for en uforholdsmæssig stor del af de dårlige INP-scores, kender du grænsen. Scripts, der er acceptable ved 4 GB, kan være kandidater til udskydelse eller fjernelse alene baseret på de data.

For sites med et globalt publikum kan du parre CCS med dimensionen Land. Markeder i Syd- og Sydøstasien, Afrika syd for Sahara samt dele af Latinamerika har høje koncentrationer af enheder i kategorierne Kritisk begrænset og Meget begrænset. En CCS-opdeling filtreret efter land viser dig, hvor forskellen er størst, så du kan prioritere, hvilket markt du skal tage fat på først.

Ukendt-kategorien (CCS 0) dækker al trafik fra Firefox og Safari plus alle sessioner, hvor API'erne ikke returnerede nogen værdi. Ignorer den ikke. På sites med en stor andel af Firefox- eller Safari-brugere kan Ukendt udgøre en fjerdedel eller mere af alle sessioner. Det betyder ikke, at disse brugere har dårlige enheder – det betyder blot, at signalet ikke var tilgængeligt. Behandl Ukendt som et separat segment i stedet for at samle det med din baseline.

Hvad du skal gøre med dataene

Hvis besøgende i kategori CCS 3, 4 eller 5 udgør mere end 15 % af din trafik, og deres INP konstant ligger over 200 ms, er løsningerne specifikke:

• Profilér dine længste tasks på en droslet enhed i Chrome DevTools. Task Attribution i Performance-panelet viser, hvilke scripts der har ansvaret.
• Flyt ikke-kritiske tredjepartsscripts bag en interaktions- eller synligheds-trigger. Så kæmper de ikke om main thread under den indledende indlæsning.
• Reducer din JavaScript-bundlestørrelse på kritiske stier. Hver kilobyte, der parses på en enhed med lidt hukommelse, koster mere end på et flagskib. Det skyldes, at JIT-compileren har mindre plads til at cache den kompilerede kode.
• Brug scheduler.yield() eller setTimeout(0) til at opdele long tasks. Det giver browseren mulighed for at behandle input-events mellem bidderne.

CoreDash viser dimensionerne CCS og Device Memory sammen med alle Core Web Vitals-metrics. Så kan du se, om en rettelse, der forbedrede INP på kraftige enheder, også rykkede tallene for de kritiske begrænsede besøgende – og ikke kun for dine best-case-brugere.