Core/Dash Dimension: Leistungsfähigkeit von Gerät & Client

Was diese Dimensionen messen

CoreDash stellt zwei Dimensionen in der Kategorie Leistungsfähigkeit von Gerät & Client 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 genauer Zahlen sehen. Diese Rundung ist beabsichtigt: Sie schränkt die Präzision für Fingerprinting-Skripte ein, gibt 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, navigator.hardwareConcurrency (logische CPU-Kerne) und dem effektiven Verbindungstyp aus der Network Information API. Das Ergebnis fällt in einen von sechs Bereichen:

Der zusammengesetzte Score ist nützlicher als jedes einzelne Signal isoliert betrachtet. Ein Gerät mit 4 GB RAM bei 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 durchzuführen.

Browser-Unterstützung und Datenabdeckung

navigator.deviceMemory ist eine exklusive API von Chromium. Firefox und Safari stellen diese nicht zur Verfügung, was bedeutet, dass diese Browser für die Arbeitsspeicher-Komponente immer Unbekannt (CCS 0) melden. In der Praxis machen Chrome und auf Chrome basierende Browser den Großteil des Android-Traffics aus, und auf Android-Geräten konzentrieren sich die Bedingungen mit geringem 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 JavaScript API, deren Daten zur Ladezeit der Seite erfasst werden, sodass der Wert mit dem RUM-Beacon übertragen wird und keine serverseitige Header-Konfiguration erforderlich ist.

Warum die Geräteleistung 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 in INP-Daten am deutlichsten sichtbar wird.

Lange Tasks auf dem Main Thread blockieren die Eingabereaktion. 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 und weniger Spielraum für JIT-Kompilierung führen direkt zu längeren Task-Dauern. Eine Website, die INP auf einem modernen Smartphone mit 180 ms besteht, kann auf einem stark limitierten Gerät leicht bei 400 ms liegen.

Das Performance-Kapitel des Web Almanac 2025 bestätigt diesen Trend: Die mobilen INP-Erfolgsquoten erreichen insgesamt 77 %, aber die Kluft zwischen leistungsstarken und leistungsschwachen Geräten ist bei 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.

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

So nutzen Sie CCS und Device Memory in CoreDash

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 leistungsstarke (CCS 1) und leistungsstarke (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 Korrekturen aus (Preloading, Connection Hints, CDN-Tuning) und lenkt Ihre Aufmerksamkeit auf die JavaScript-Ausführungszeit: lange Tasks, Gewicht von Input-Handlern und Skripte von Drittanbietern, 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 überproportionalen Anteil an schlechten INP-Werten ausmachen, kennen Sie den Schwellenwert. Skripte, die bei 4 GB akzeptabel sind, können allein aufgrund dieser Daten Kandidaten für eine Verzögerung oder Entfernung sein.

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

Der Bereich Unbekannt (CCS 0) deckt den gesamten Traffic von Firefox und Safari ab, sowie jede Sitzung, in der die APIs keinen Wert zurückgegeben haben. Ignorieren Sie ihn nicht. Auf Websites mit signifikantem 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 ein separates Segment, anstatt es in Ihre Baseline aufzunehmen.

Was Sie mit den Daten tun können

Wenn Besucher mit CCS 3, 4 oder 5 mehr als 15 % Ihres Traffics ausmachen und ihr INP konstant über 200 ms liegt, ist die Herangehensweise zur Fehlerbehebung spezifisch:

• Profilen Sie Ihre längsten Tasks auf einem gedrosselten Gerät in den Chrome DevTools. Die Task Attribution im Performance-Panel zeigt Ihnen, welche Skripte dafür verantwortlich sind.
• Verschieben Sie nicht-kritische Drittanbieter-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-Bundlegröß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 Chance zu geben, Eingabeereignisse zwischen den Chunks zu verarbeiten.

CoreDash macht die Dimensionen CCS und Device Memory neben jeder Core Web Vitals-Metrik sichtbar, 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 nach oben bewegt hat und nicht nur für Ihre Best-Case-Nutzer.