Core/Dash Dimension: Enhed og klientkapacitet

Hvad disse dimensioner måler

CoreDash eksponerer to dimensioner under kategorien Enhed og klientkapacitet. De besvarer forskellige spørgsmål, men supplerer hinanden direkte.

Device Memory (gruppekode m) rapporterer den RAM-kategori, som browseren returnerer fra navigator.deviceMemory. Specifikationen runder bevidst ned til nærmeste potens af to og fastlåser resultatet, så du vil se værdier på 0.25, 0.5, 1, 2, 4 eller 8+ GB frem for præcise tal. Denne afrunding er bevidst: den begrænser den tilgængelige præcision for fingerprinting-scripts, samtidig med at den stadig giver udviklere et brugbart signal.

Client Capability Score (gruppekode ccs) er en sammensat score, der beregnes af CoreDash ud fra tre browsersignaler: enhedshukommelse, navigator.hardwareConcurrency (logiske CPU-kerner) og den effektive forbindelsestype fra Network Information API. Resultatet er en af seks kategorier:

Den sammensatte score er mere nyttig end noget enkelt signal isoleret set. En enhed med 4 GB RAM på en 2G-forbindelse opfører sig meget anderledes end den samme enhed på Wi-Fi. Ved at kombinere hukommelse, kerner og forbindelsestype i én ordinal skala, kan du filtrere og sammenligne ydeevnedata uden at køre en separat nedbrydning for hver variabel.

Browsersupport og datadækning

navigator.deviceMemory er et API udelukkende til Chromium. Firefox og Safari eksponerer det ikke, hvilket betyder, at disse browsere altid rapporterer 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 forhold med lav hukommelse koncentrerer sig. Så signalet er mest tilgængeligt præcis dér, 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 forhandlet Accept-CH anmodning. CoreDash bruger JavaScript API'et, som indsamles på tidspunktet for sideindlæsning, så værdien rejser med det RUM-beacon i stedet for at kræve konfiguration af headere på serversiden.

Hvorfor enhedskapacitet er vigtigt for Core Web Vitals

LCP er primært et netværks- og render-problem. INP er primært et CPU- og hukommelsesproblem. Denne forskel er grunden til, at CCS-dimensionen fremstår tydeligst i INP-data.

Lange opgaver på hovedtråden blokerer inputrespons. På en enhed med 1 GB RAM er browseren allerede under hukommelsespres, før dit JavaScript overhovedet kører: mere aggressiv garbage collection, hyppigere kassering af faner og mindre frirum til JIT-kompilering oversættes alt sammen direkte til længere opgavevarigheder. Et website, der består INP på en moderne telefon ved 180 ms, kan nemt ligge på 400 ms på en stærkt begrænset enhed.

2025 Web Almanac Performance-kapitlet bekræfter tendensen: andelen der består mobil INP når 77% overordnet set, men kløften mellem højtydende og low-end enheder i det tal er bred. Omtrent 29% af mobile webbrugere er på enheder, der er tre gange mindre kraftfulde end et nuværende flagskib. Disse brugere er ikke afvigere på de fleste globale markeder; de er median-besøgende.

CLS er mindre følsomt over for hardwareklasse end INP, men enheder med langsomme CPU'er kan stadig producere layoutskift, når skrifttyper eller sent indlæste billeder forårsager reflows, som afsluttes efter, at browseren allerede har committet en frame.

Sådan bruger du CCS og Device Memory i CoreDash

Det mest produktive workflow er at starte med CCS som filter og derefter bruge Device Memory til at bekræfte din hypotese.

Først skal du åbne din INP-nedbrydning efter CCS. Hvis din 75. percentil for INP er god for besøgende i kategorierne Meget kapabel (CCS 1) og Kapabel (CCS 2), men fejler for Begrænset (CCS 3) og derunder, har du en CPU- eller hukommelsesflaskehals snarere end en netværksflaskehals. Det udelukker en hel kategori af rettelser (preloading, forbindelseshints, CDN-justering) og fokuserer din opmærksomhed på udførelsestiden for JavaScript: lange opgaver, vægten af input handlere og tredjeparts-scripts, der kører ved hver interaktion.

Filtrer derefter efter Device Memory for at se, hvilke RAM-kategorier der giver de dårligste resultater. Hvis enheder med 1 GB udgør en uforholdsmæssig stor andel af dårlige INP-scores, kender du grænsen. Scripts, der er acceptable ved 4 GB, kan være kandidater til udskydelse eller fjernelse baseret på disse data alene.

For websites med globale publikummer kan du parre CCS med Country-dimensionen. Markeder i Syd- og Sydøstasien, Afrika syd for Sahara og dele af Latinamerika har høje koncentrationer af stærkt begrænsede og meget begrænsede enheder. En CCS-nedbrydning filtreret efter land vil vise dig, hvor kløften er størst, og hjælpe dig med at prioritere, hvilket marked der skal adresseres først.

Kategorien Ukendt (CCS 0) dækker al trafik fra Firefox og Safari plus enhver session, hvor API'erne ikke returnerede nogen værdi. Ignorer den ikke. På websites med en betydelig andel af Firefox eller Safari kan Ukendt repræsentere en fjerdedel eller mere af alle sessioner. Det betyder ikke, at disse brugere har dårlige enheder; det betyder, at signalet var utilgængeligt. Behandl Ukendt som et separat segment frem for at folde det ind i din baseline.

Hvad skal man gøre med dataene

Hvis besøgende i CCS 3, 4 eller 5 udgør mere end 15% af din trafik, og deres INP konsekvent er over 200 ms, er sættet af rettelser specifikt:

• Profilér dine længste opgaver på en neddroslet enhed i Chrome DevTools. Task Attribution i Performance-panelet vil vise, hvilke scripts der er ansvarlige.
• Flyt ikke-kritiske tredjeparts-scripts ind bag en interaktions- eller synlighedsudløser, så de ikke konkurrerer om hovedtråden i det indledende indlæsningsvindue.
• Reducer JavaScript-bundlestørrelsen på kritiske stier. Hver kilobyte, der parses på en enhed med lav hukommelse, koster mere end på et flagskib, fordi JIT-compileren har mindre plads til at cache kompileret kode.
• Brug scheduler.yield() eller setTimeout(0) til at bryde lange opgaver op og give browseren en chance for at behandle inputhændelser mellem klumperne.

CoreDash fremhæver CCS- og Device Memory-dimensionerne sammen med hver Core Web Vitals-metrik, så du kan bekræfte, om en rettelse, der forbedrede INP på high-end enheder, også rykkede tallene for dine stærkt begrænsede besøgende, og ikke kun dine best-case brugere.