Core/Dash Dimension: Geräte- & Client-Fähigkeit

Was diese Dimensionen messen

CoreDash stellt zwei Dimensionen in der Kategorie Geräte- & Client-Fähigkeit bereit. Sie beantworten unterschiedliche Fragen, ergänzen sich aber direkt.

Device Memory (Gruppencode m) meldet den RAM-Bereich, den der Browser aus navigator.deviceMemory zurückgibt. Die Spezifikation rundet bewusst auf die nächste Zweierpotenz ab und begrenzt das Ergebnis, sodass Sie Werte wie 0.25, 0.5, 1, 2, 4 oder 8+ GB anstelle von exakten Zahlen sehen. Diese Rundung ist beabsichtigt: Sie schränkt die für Fingerprinting-Skripte verfügbare Präzision ein, bietet Entwicklern aber dennoch ein nutzbares Signal.

Der Client Capability Score (Gruppencode ccs) ist ein von CoreDash berechneter zusammengesetzter Wert aus drei vom Browser bereitgestellten Signalen: Device Memory (Arbeitsspeicher), navigator.hardwareConcurrency (logische CPU-Kerne) und dem effektiven Verbindungstyp aus der Network Information API. Das Ergebnis ist einer von sechs Bereichen:

Der zusammengesetzte Score ist nützlicher als jedes einzelne Signal isoliert betrachtet. Ein Gerät mit 4 GB RAM und einer 2G-Verbindung verhält sich völlig anders als dasselbe Gerät im WLAN. Die Kombination von Arbeitsspeicher, Kernen und Verbindungstyp in einer ordinalen Skala ermöglicht es Ihnen, Leistungsdaten zu filtern und zu vergleichen, ohne für jede Variable eine separate Aufschlüsselung vornehmen zu müssen.

Browser-Unterstützung und Datenabdeckung

navigator.deviceMemory ist eine reine Chromium-API. Firefox und Safari stellen sie nicht bereit, was bedeutet, dass diese Browser für die Arbeitsspeicher-Komponente immer Unbekannt (CCS 0) melden. In der Praxis machen Chrome und Chrome-basierte Browser den Großteil des Android-Traffics aus, und auf Android-Geräten konzentrieren sich Bedingungen mit wenig Arbeitsspeicher. Das Signal ist also genau dort am besten verfügbar, wo es am wichtigsten ist.

Der Device Memory HTTP-Header (Device-Memory) ist ein separater Mechanismus, der es einem Server ermöglicht, denselben Wert aus einer über Accept-CH ausgehandelten Anfrage zu lesen. CoreDash nutzt die beim Seitenaufbau erfasste JavaScript-API, sodass der Wert mit dem RUM-Beacon übertragen wird, anstatt eine serverseitige Header-Konfiguration zu erfordern.

Warum die Gerätefähigkeit für Core Web Vitals wichtig ist

LCP ist in erster Linie ein Netzwerk- und Rendering-Problem. INP ist in erster Linie ein CPU- und Arbeitsspeicher-Problem. Diese Unterscheidung ist der Grund, warum die CCS-Dimension am deutlichsten in den INP-Daten sichtbar wird.

Lange Tasks im Main Thread blockieren die Reaktion auf Eingaben. Auf einem Gerät mit 1 GB RAM steht der Browser bereits unter Speicherdruck, bevor Ihr JavaScript überhaupt ausgeführt wird: aggressivere Garbage Collection, häufigeres Verwerfen von Tabs (Tab Discards) und weniger Spielraum für die JIT-Kompilierung führen direkt zu längeren Task-Laufzeiten. Eine Website, die INP auf einem modernen Smartphone mit 180 ms besteht, kann auf einem stark limitierten (Constrained) Gerät leicht bei 400 ms liegen.

Das Performance-Kapitel des Web Almanac 2025 bestätigt diesen Trend: Die INP-Bestehensquoten auf Mobilgeräten erreichen insgesamt 77 %, aber die Kluft zwischen leistungsstarken und Low-End-Geräten ist in dieser Zahl groß. Etwa 29 % der mobilen Webnutzer verwenden Geräte, die dreimal weniger leistungsstark sind als ein aktuelles Flaggschiff. Diese Nutzer sind in den meisten globalen Märkten keine Ausreißer; sie sind der durchschnittliche Besucher (Median).

CLS ist weniger empfindlich gegenüber der Hardwareklasse als INP, aber Geräte mit langsamen CPUs können dennoch Layoutverschiebungen erzeugen, wenn Schriftarten oder spät ladende Bilder Reflows verursachen, die erst abgeschlossen werden, nachdem der Browser bereits einen Frame gerendert hat.

Wie man CCS und Device Memory in CoreDash nutzt

Der produktivste Workflow besteht darin, mit CCS als Filter zu beginnen und dann Device Memory zu verwenden, um Ihre Hypothese zu bestätigen.

Öffnen Sie zunächst Ihre INP-Aufschlüsselung nach CCS. Wenn Ihr INP im 75. Perzentil für sehr leistungsfähige (CCS 1) und leistungsfähige (CCS 2) Besucher gut ist, aber bei eingeschränkten (CCS 3) und darunterliegenden fehlschlägt, haben Sie eher einen CPU- oder Arbeitsspeicher-Engpass als einen Netzwerk-Engpass. Das schließt eine ganze Kategorie von Fixes aus (Preloading, Connection Hints, CDN-Tuning) und lenkt Ihre Aufmerksamkeit auf die JavaScript-Ausführungszeit: lange Tasks, das Gewicht von Input-Handlern und Third-Party-Skripte, die bei jeder Interaktion ausgeführt werden.

Filtern Sie dann nach Device Memory, um zu sehen, welche RAM-Bereiche die schlechtesten Ergebnisse verursachen. Wenn 1-GB-Geräte einen unverhältnismäßig hohen Anteil an schlechten INP-Werten ausmachen, kennen Sie den Schwellenwert. Skripte, die bei 4 GB noch akzeptabel sind, können allein aufgrund dieser Daten Kandidaten für eine Verzögerung (Deferral) oder Entfernung sein.

Bei Websites mit einem globalen Publikum sollten Sie CCS mit der Dimension Country (Land) kombinieren. Süd- und südostasiatische Märkte, Subsahara-Afrika und Teile Lateinamerikas weisen eine hohe Konzentration von stark limitierten (Constrained) und sehr eingeschränkten (Very Limited) Geräten auf. Eine nach Land gefilterte CCS-Aufschlüsselung zeigt Ihnen, wo die Lücke am größten ist, und hilft Ihnen bei der Priorisierung, welcher Markt zuerst adressiert werden soll.

Der Bereich Unbekannt (CCS 0) deckt den gesamten Firefox- und Safari-Traffic ab, plus jede Sitzung, bei der die APIs keinen Wert zurückgegeben haben. Ignorieren Sie ihn nicht. Auf Websites mit einem signifikanten Firefox- oder Safari-Anteil kann Unbekannt ein Viertel oder mehr aller Sitzungen ausmachen. Das bedeutet nicht, dass diese Nutzer schlechte Geräte haben; es bedeutet lediglich, dass das Signal nicht verfügbar war. Behandeln Sie Unbekannt als separates Segment, anstatt es in Ihre Baseline einfließen zu lassen.

Was Sie mit den Daten tun können

Wenn Besucher mit CCS 3, 4 oder 5 mehr als 15 % Ihres Traffics ausmachen und deren INP konstant über 200 ms liegt, ist das Set an Maßnahmen spezifisch:

• Profilieren Sie Ihre längsten Tasks auf einem gedrosselten Gerät in den Chrome DevTools. Die Task Attribution im Performance-Panel zeigt, welche Skripte dafür verantwortlich sind.
• Verschieben Sie nicht-kritische Third-Party-Skripte hinter einen Interaktions- oder Sichtbarkeits-Trigger, damit sie während des anfänglichen Ladefensters nicht um den Main Thread konkurrieren.
• Reduzieren Sie die JavaScript-Bundle-Größe auf kritischen Pfaden. Jedes Kilobyte, das auf einem Gerät mit wenig Arbeitsspeicher geparst wird, kostet mehr als auf einem Flaggschiff, da der JIT-Compiler weniger Platz hat, um kompilierten Code zwischenzuspeichern.
• Verwenden Sie scheduler.yield() oder setTimeout(0), um lange Tasks aufzuteilen und dem Browser die Möglichkeit zu geben, Eingabeereignisse zwischen den Chunks zu verarbeiten.

CoreDash stellt die Dimensionen CCS und Device Memory neben jeder Core Web Vitals-Metrik bereit, sodass Sie bestätigen können, ob ein Fix, der INP auf High-End-Geräten verbessert hat, auch die Zahlen für Ihre stark limitierten Besucher bewegt hat und nicht nur für Ihre Best-Case-Nutzer.