CoreDash Dimensie: Device & Client Capability

Wat deze dimensies meten

CoreDash ontsluit twee dimensies onder de categorie Device & Client Capability. Ze beantwoorden verschillende vragen, maar vullen elkaar direct aan.

Device Memory (groepscode m) rapporteert de RAM-categorie die de browser teruggeeft via navigator.deviceMemory. De specificatie rondt dit bewust af naar de dichtstbijzijnde macht van twee en begrenst het resultaat, dus u zult waarden zien van 0.25, 0.5, 1, 2, 4, of 8+ GB in plaats van exacte cijfers. Deze afronding is opzettelijk: het beperkt de precisie die beschikbaar is voor fingerprinting-scripts, terwijl het ontwikkelaars toch een bruikbaar signaal geeft.

Client Capability Score (groepscode ccs) is een samengestelde score die door CoreDash wordt berekend op basis van drie door de browser vrijgegeven signalen: device memory, navigator.hardwareConcurrency (logische CPU-kernen), en het effectieve verbindingstype uit de Network Information API. Het resultaat is een van de zes categorieën:

De samengestelde score is nuttiger dan elk afzonderlijk signaal op zich. Een apparaat met 4 GB RAM op een 2G-verbinding gedraagt zich heel anders dan hetzelfde apparaat op Wi-Fi. Door geheugen, kernen en verbindingstype te combineren in één ordinale schaal, kunt u prestatiegegevens filteren en vergelijken zonder voor elke variabele een aparte uitsplitsing te hoeven maken.

Browserondersteuning en datadekking

navigator.deviceMemory is een API die alleen in Chromium-browsers beschikbaar is. Firefox en Safari geven dit niet vrij, wat betekent dat die browsers voor de geheugencomponent altijd Unknown (CCS 0) rapporteren. In de praktijk zijn Chrome en op Chrome gebaseerde browsers verantwoordelijk voor het grootste deel van het Android-verkeer, en Android-apparaten zijn juist de plek waar situaties met weinig geheugen zich concentreren. Het signaal is dus het meest beschikbaar precies daar waar het het meest nodig is.

De Device Memory HTTP-header (Device-Memory) is een afzonderlijk mechanisme waarmee een server dezelfde waarde kan lezen uit een via Accept-CH genegotieerd verzoek. CoreDash gebruikt de JavaScript API die wordt verzameld op het moment dat de pagina wordt geladen, zodat de waarde meereist met het RUM-baken en er geen server-side headerconfiguratie nodig is.

Waarom device capability belangrijk is voor Core Web Vitals

LCP is primair een netwerk- en renderprobleem. INP is primair een CPU- en geheugenprobleem. Dat onderscheid is de reden waarom de CCS-dimensie het duidelijkst naar voren komt in INP-gegevens.

Lange taken op de main thread blokkeren de reactie op invoer. Op een apparaat met 1 GB RAM staat de browser al onder geheugendruk voordat uw JavaScript überhaupt wordt uitgevoerd: agressievere garbage collection, vaker verwijderen van tabbladen uit het geheugen en minder ruimte voor JIT-compilatie vertalen zich direct in langere taakduur. Een site die op een moderne telefoon slaagt voor INP met 180 ms, kan op een Constrained apparaat gemakkelijk op 400 ms uitkomen.

Het 2025 Web Almanac Performance hoofdstuk bevestigt deze trend: de pass-rates voor mobiele INP bereiken 77% in totaal, maar de kloof tussen krachtige en low-end apparaten in dat cijfer is groot. Ongeveer 29% van de mobiele webgebruikers werkt op apparaten die drie keer minder krachtig zijn dan een huidig topmodel. Die gebruikers zijn in de meeste wereldwijde markten geen uitzonderingen; zij vormen de mediane bezoeker.

CLS is minder gevoelig voor de hardware-klasse dan INP, maar apparaten met trage CPU's kunnen nog steeds layout shifts veroorzaken wanneer lettertypen of traag ladende afbeeldingen reflows veroorzaken die pas worden voltooid nadat de browser al een frame heeft vastgelegd.

Hoe u CCS en Device Memory gebruikt in CoreDash

De meest productieve werkwijze is om te beginnen met CCS als filter en vervolgens Device Memory te gebruiken om uw hypothese te bevestigen.

Open eerst uw INP-uitsplitsing per CCS. Als uw 75e percentiel INP goed is voor Very Capable (CCS 1) en Capable (CCS 2) bezoekers, maar faalt voor Limited (CCS 3) en lager, dan heeft u te maken met een CPU- of geheugenbottleneck in plaats van een netwerkbottleneck. Dat sluit een hele categorie oplossingen uit (preloading, connection hints, CDN-tuning) en richt uw aandacht op de uitvoeringstijd van JavaScript: lange taken, het gewicht van de input handler en scripts van derden die bij elke interactie draaien.

Filter vervolgens op Device Memory om te zien welke RAM-categorieën de slechtste resultaten veroorzaken. Als apparaten met 1 GB een onevenredig groot aandeel hebben in slechte INP-scores, kent u de drempel. Scripts die acceptabel zijn bij 4 GB kunnen op basis van die gegevens alleen al kandidaten zijn voor uitstel of verwijdering.

Voor sites met een wereldwijd publiek combineert u CCS met de Country dimensie. Markten in Zuid- en Zuidoost-Azië, Afrika bezuiden de Sahara en delen van Latijns-Amerika hebben hoge concentraties van Constrained en Very Limited apparaten. Een CCS-uitsplitsing gefilterd op land laat u zien waar de kloof het grootst is en helpt u bij het prioriteren van de markt die u het eerst moet aanpakken.

De Unknown categorie (CCS 0) omvat al het Firefox- en Safari-verkeer, plus elke sessie waarbij de API's geen waarde teruggaven. Negeer deze niet. Op sites met een aanzienlijk aandeel Firefox of Safari kan Unknown een kwart of meer van alle sessies vertegenwoordigen. Het betekent niet dat die gebruikers slechte apparaten hebben; het betekent dat het signaal niet beschikbaar was. Behandel Unknown als een afzonderlijk segment in plaats van het op te nemen in uw baseline.

Wat te doen met de data

Als bezoekers met CCS 3, 4 of 5 meer dan 15% van uw verkeer uitmaken en hun INP consequent boven de 200 ms ligt, is de set oplossingen specifiek:

• Profileer uw langste taken op een begrensd apparaat in Chrome DevTools. Task Attribution in het Performance-paneel laat zien welke scripts verantwoordelijk zijn.
• Plaats niet-kritieke scripts van derden achter een interactie- of zichtbaarheidstrigger, zodat ze niet concurreren om de main thread tijdens het initiële laadvenster.
• Verminder de JavaScript-bundelgrootte op kritieke paden. Elke kilobyte die op een apparaat met weinig geheugen wordt geparst, kost meer dan op een topmodel, omdat de JIT-compiler minder ruimte heeft om gecompileerde kood te cachen.
• Gebruik scheduler.yield() of setTimeout(0) om lange taken op te breken en de browser een kans te geven om input-events te verwerken tussen de blokken door.

CoreDash brengt de CCS- en Device Memory-dimensies naar voren naast elke Core Web Vitals-metriek, zodat u kunt bevestigen of een oplossing die de INP verbeterde op high-end apparaten ook de cijfers voor uw Constrained bezoekers heeft verbeterd, en niet alleen voor uw 'best-case' gebruikers.