Core/Dash-dimensjon: Enhets- og klientkapasitet

Hva disse dimensjonene måler

CoreDash tilbyr to dimensjoner under kategorien Enhets- og klientkapasitet. 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 toerpotens og begrenser resultatet, så du vil se verdier på 0,25, 0,5, 1, 2, 4 eller 8+ GB i stedet for nøyaktige tall. Denne avrundingen er tilsiktet: den begrenser presisjonen som er tilgjengelig for fingerprinting-skript, samtidig som den gir utviklere et brukbart signal.

Client Capability Score (gruppekode ccs) er en sammensatt verdi som CoreDash beregner fra tre signaler eksponert av nettleseren: 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 et enkelt signal i isolasjon. En enhet med 4 GB RAM på en 2G-tilkobling oppfører seg svært annerledes enn samme enhet på Wi-Fi. Ved å kombinere minne, kjerner og tilkoblingstype i én ordinalskala, kan du filtrere og sammenligne ytelsesdata uten å kjøre en egen oppsplitting for hver variabel.

Nettleserstøtte og datadekning

navigator.deviceMemory er et API som kun finnes i Chromium. Firefox og Safari eksponerer det ikke, noe som betyr at disse nettleserne alltid rapporterer Ukjent (CCS 0) for minnekomponenten. I praksis står Chrome og Chrome-baserte nettlesere for flertallet av Android-trafikken, og Android-enheter er der forhold med lite minne konsentreres. Så signalet er mest tilgjengelig akkurat der det betyr mest.

HTTP-headeren for Device Memory (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 som samles inn ved sidelasting, så verdien sendes med RUM-beaconen i stedet for å kreve headerkonfigurasjon på serversiden.

Hvorfor enhetskapasitet betyr noe for Core Web Vitals

LCP-en er primært et nettverks- og renderingsproblem. INP-en er primært et CPU- og minneproblem. Denne forskjellen er grunnen til at CCS-dimensjonen vises tydeligst i INP-data.

Long tasks på main thread blokkerer inputrespons. På en enhet med 1 GB RAM er nettleseren allerede under minnepress før JavaScript-en din i det hele tatt kjører: mer aggressiv garbage collection, hyppigere tab-discards og mindre margin for JIT-kompilering fører direkte til lengre varighet på long tasks. Et nettsted som består INP på en moderne telefon på 180 ms, kan enkelt ligge på 400 ms på en Kritisk begrenset-enhet.

Performance-kapittelet i Web Almanac for 2025 bekrefter trenden: bestått-ratene for INP på mobil når 77 % totalt, men gapet mellom kraftige enheter og lavpris-enheter i dette tallet er stort. Omtrent 29 % av mobile webbrukere er på enheter som er tre ganger mindre kraftige enn et nåværende flaggskip. Disse brukerne er ikke spesialtilfeller i de fleste globale markeder; de er medianbesøkende.

CLS-en er mindre følsom for maskinvareklasse enn INP-en, men enheter med trege CPU-er kan fortsatt forårsake layoutskift når fonter eller bilder som lastes sent, fører til reflows som fullføres etter at nettleseren allerede har committet en frame.

Hvordan bruke CCS og Device Memory i CoreDash

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

Først åpner du INP-oppsplittingen etter CCS. Hvis 75-persentilen for INP er god for besøkende i kategoriene Svært kapabel (CCS 1) og Kapabel (CCS 2), men feiler for Begrenset (CCS 3) og lavere, har du en flaskehals på CPU- eller minnesiden snarere enn en nettverksflaskehals. Det utelukker en hel kategori med optimaliseringer (preloading, tilkoblingshint, CDN-optimalisering) og retter fokuset mot kjøretiden for JavaScript: long tasks, tyngden på input-håndterere og tredjepartsskript som kjører ved hver interaksjon.

Deretter filtrerer du etter Device Memory for å se hvilke RAM-kategorier som gir de dårligste resultatene. Hvis enheter med 1 GB står for en uforholdsmessig stor andel av de dårlige INP-resultatene, vet du hvor grensen går. Skript som er akseptable ved 4 GB, kan være kandidater for utsettelse eller fjerning basert på disse dataene alene.

For nettsteder med et globalt publikum kan du koble CCS sammen med dimensjonen Country. Markeder i Sør- og Sørøst-Asia, Afrika sør for Sahara og deler av Latin-Amerika har høye konsentrasjoner av Kritisk begrenset- og Svært begrenset-enheter. En CCS-oppsplitting filtrert etter land vil vise deg hvor gapet er størst, og hjelpe deg med å prioritere hvilket marked du skal ta tak i først.

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

Hva du gjør med dataene

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

• Profiler de lengste long tasks-ene dine på en strupet enhet i Chrome DevTools. Task Attribution i Performance-panelet vil vise hvilke skript som er ansvarlige.
• Flytt ikke-kritiske tredjepartsskript bak en interaksjons- eller synlighets-trigger, slik at de ikke kjemper om main thread i løpet av det innledende lastevinduet.
• Reduser størrelsen på JavaScript-bundler i kritiske baner. Hver kilobyte som parses på en enhet med lite minne koster mer enn på et flaggskip, fordi JIT-kompilatoren har mindre plass til å cache kompilert kode.
• Bruk scheduler.yield() eller setTimeout(0) for å dele opp long tasks, og gi nettleseren en sjanse til å behandle input-hendelser mellom delene.

CoreDash viser dimensjonene CCS og Device Memory ved siden av hver Core Web Vitals-metrikk, slik at du kan bekrefte om et tiltak som forbedret INP-en på kraftige enheter også flyttet tallene for de Kritisk begrenset-besøkende, og ikke bare for brukerne med de beste enhetene.