Core/Dash Dimensie: Device & Client Capability

Wat deze dimensies meten

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

Device Memory (groepscode m) rapporteert de RAM-bucket die de browser teruggeeft via navigator.deviceMemory. De specificatie rondt bewust naar beneden af op de dichtstbijzijnde macht van twee en begrenst het resultaat. Je ziet dus waarden van 0,25, 0,5, 1, 2, 4 of 8+ GB in plaats van exacte getallen. Deze afronding is opzettelijk: het beperkt de precisie voor fingerprinting-scripts, maar geeft ontwikkelaars nog steeds een bruikbaar signaal.

Client Capability Score (groepscode ccs) is een samengestelde score die CoreDash berekent op basis van drie door de browser vrijgegeven signalen: het apparaatgeheugen, navigator.hardwareConcurrency (logische CPU-cores) en het effectieve verbindingstype uit de Network Information API. Het resultaat valt in een van de zes buckets:

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

Browserondersteuning en datadekking

navigator.deviceMemory is een API die alleen in Chromium werkt. Firefox en Safari bieden deze niet aan, waardoor die browsers voor de geheugencomponent altijd Unknown (CCS 0) rapporteren. In de praktijk vormen Chrome en op Chrome gebaseerde browsers het merendeel van het Android-verkeer. Juist op Android-apparaten concentreren situaties met weinig geheugen zich, dus het signaal is beschikbaar waar het het meest uitmaakt.

De Device Memory HTTP-header (Device-Memory) is een apart mechanisme waarmee een server dezelfde waarde kan lezen uit een via Accept-CH onderhandeld request. CoreDash gebruikt de JavaScript-API die tijdens het laden van de pagina gegevens verzamelt. Hierdoor reist de waarde mee met het RUM-beacon en is er geen server-side headerconfiguratie nodig.

Waarom apparaatcapaciteit ertoe doet voor Core Web Vitals

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

Long tasks op de main thread blokkeren de reactie op input. Op een apparaat met 1 GB RAM staat de browser al onder geheugendruk voordat je JavaScript überhaupt draait: agressievere garbage collection, frequentere tab-discards en minder ruimte voor JIT-compilatie leiden direct tot een langere task-duur. Een site die op een moderne telefoon met 180 ms slaagt voor de INP, kan op een Constrained-apparaat gemakkelijk op 400 ms uitkomen.

Het Performance-hoofdstuk van de 2025 Web Almanac bevestigt deze trend: het mobiele INP-slaagpercentage ligt gemiddeld op 77%, maar het verschil tussen krachtige en zwakkere apparaten is daarin groot. Ongeveer 29% van de mobiele internetgebruikers zit op apparaten die drie keer minder krachtig zijn dan een huidig vlaggenschip. Die gebruikers zijn in de meeste wereldwijde markten geen uitzondering; ze zijn de mediane bezoeker.

CLS is minder gevoelig voor de hardwareklasse dan INP, maar apparaten met trage CPU's kunnen nog steeds layout shifts veroorzaken wanneer lettertypen of laat ladende afbeeldingen reflows veroorzaken die pas klaar zijn nadat de browser al een frame heeft gecommit.

Hoe je CCS en Device Memory gebruikt in CoreDash

De meest productieve workflow is om te starten met CCS als filter en daarna Device Memory te gebruiken om je hypothese te bevestigen.

Open eerst je INP-uitsplitsing per CCS. Als je INP op het 75e percentiel goed is voor bezoekers in de categorieën Very Capable (CCS 1) en Capable (CCS 2), maar faalt voor Limited (CCS 3) en lager, dan heb je een CPU- of geheugenbottleneck in plaats van een netwerkbottleneck. Dat sluit direct een hele categorie oplossingen uit (preloading, connection hints, CDN-tuning) en verplaatst de focus naar de JavaScript-uitvoertijd: long tasks, zware input-handlers en third-party scripts die bij elke interactie draaien.

Filter vervolgens op Device Memory om te zien welke RAM-buckets de slechtste resultaten veroorzaken. Als 1 GB-apparaten verantwoordelijk zijn voor een onevenredig groot deel van de slechte INP-scores, ken je de drempelwaarde. Scripts die prima werken op 4 GB kunnen op basis van die data alleen al kandidaat zijn voor uitstel of verwijdering.

Combineer voor sites met een wereldwijd publiek CCS met de dimensie Country. Markten in Zuid- en Zuidoost-Azië, Sub-Saharisch Afrika en delen van Latijns-Amerika hebben hoge concentraties Constrained- en Very Limited-apparaten. Een CCS-uitsplitsing gefilterd op land laat zien waar het gat het grootst is en helpt je te prioriteren welke markt je als eerste aanpakt.

De Unknown-bucket (CCS 0) dekt al het Firefox- en Safari-verkeer plus elke sessie waarin 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. Dit betekent niet dat die gebruikers slechte apparaten hebben; het betekent simpelweg dat het signaal niet beschikbaar was. Behandel Unknown als een apart segment en voeg het niet zomaar samen met je baseline.

Wat te doen met de data

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

• Profileer je langste taken op een vertraagd apparaat in Chrome DevTools. Task Attribution in het Performance-paneel laat zien welke scripts verantwoordelijk zijn.
• Plaats niet-kritieke third-party scripts achter een interactie- of zichtbaarheidstrigger, zodat ze tijdens de initiële laadfase niet concurreren om de main thread.
• Verklein de JavaScript-bundelgrootte op kritieke paden. Elke kilobyte die wordt geparsed op een apparaat met weinig geheugen kost meer dan op een vlaggenschip, omdat de JIT-compiler minder ruimte heeft om gecompileerde code te cachen.
• Gebruik scheduler.yield() of setTimeout(0) om long tasks op te breken. Zo geef je de browser de kans om tussendoor input-events te verwerken.

CoreDash toont de dimensies CCS en Device Memory naast elke Core Web Vitals-metriek. Zo kun je controleren of een oplossing die de INP op krachtige apparaten verbeterde, ook de cijfers voor je Constrained-bezoekers heeft verbeterd, en niet alleen voor je best-case gebruikers.