Dimension Core/Dash : Capacité de l'appareil et du client

Ce que mesurent ces dimensions

CoreDash expose deux dimensions dans la catégorie Capacité de l'appareil et du client (Device & Client Capability). Elles répondent à des questions différentes mais se complètent directement.

Device Memory (code de groupe m) indique le palier de RAM que le navigateur renvoie via navigator.deviceMemory. La spécification arrondit délibérément à l'inférieur, à la puissance de deux la plus proche, et limite le résultat. Vous verrez donc des valeurs de 0.25, 0.5, 1, 2, 4 ou 8+ Go plutôt que des chiffres exacts. Cet arrondi est intentionnel : il limite la précision disponible pour les scripts de fingerprinting tout en fournissant aux développeurs un signal exploitable.

Le Client Capability Score (code de groupe ccs) est une mesure composite calculée par CoreDash à partir de trois signaux exposés par le navigateur : la mémoire de l'appareil (device memory), navigator.hardwareConcurrency (les cœurs logiques du CPU), et le type de connexion effectif de l'API Network Information. Le résultat correspond à l'un des six paliers suivants :

Le score composite est plus utile que n'importe quel signal pris isolément. Un appareil avec 4 Go de RAM sur une connexion 2G se comporte très différemment du même appareil connecté en Wi-Fi. La combinaison de la mémoire, des cœurs et du type de connexion en une seule échelle ordinale vous permet de filtrer et de comparer les données de performance sans avoir à effectuer une ventilation séparée pour chaque variable.

Support navigateur et couverture des données

navigator.deviceMemory est une API exclusive à Chromium. Firefox et Safari ne l'exposent pas, ce qui signifie que ces navigateurs renvoient toujours Inconnu (CCS 0) pour le composant mémoire. En pratique, Chrome et les navigateurs basés sur Chrome représentent la majorité du trafic Android, et c'est sur les appareils Android que se concentrent les conditions de faible mémoire. Le signal est donc le plus disponible précisément là où il est le plus important.

L'en-tête HTTP Device Memory (Device-Memory) est un mécanisme distinct qui permet à un serveur de lire la même valeur à partir d'une requête négociée via Accept-CH. CoreDash utilise l'API JavaScript collectée au moment du chargement de la page, la valeur voyage donc avec la balise RUM au lieu de nécessiter une configuration d'en-tête côté serveur.

Pourquoi la capacité des appareils est importante pour les Core Web Vitals

Le LCP est principalement un problème de réseau et de rendu. L'INP est principalement un problème de CPU et de mémoire. C'est cette distinction qui explique pourquoi la dimension CCS ressort le plus clairement dans les données INP.

Les tâches longues sur le thread principal bloquent la réponse aux entrées. Sur un appareil avec 1 Go de RAM, le navigateur subit déjà une pression sur la mémoire avant même que votre JavaScript ne s'exécute : un ramasse-miettes plus agressif, des abandons d'onglets plus fréquents et une marge de manœuvre réduite pour la compilation JIT se traduisent directement par des durées de tâches plus longues. Un site qui réussit le test INP sur un téléphone moderne à 180 ms peut facilement atteindre 400 ms sur un appareil Restreint.

Le chapitre Performance du Web Almanac 2025 confirme la tendance : les taux de réussite INP sur mobile atteignent 77 % au global, mais l'écart entre les appareils très performants et ceux d'entrée de gamme dans ce chiffre est considérable. Environ 29 % des utilisateurs du web mobile sont sur des appareils trois fois moins puissants qu'un modèle phare actuel. Ces utilisateurs ne sont pas des exceptions sur la plupart des marchés mondiaux ; ils représentent le visiteur médian.

Le CLS est moins sensible à la classe de matériel que l'INP, mais les appareils dotés de CPU lents peuvent tout de même produire des décalages de mise en page lorsque les polices ou les images à chargement tardif provoquent des recalculs qui s'achèvent après que le navigateur a déjà validé une frame.

Comment utiliser le CCS et Device Memory dans CoreDash

Le flux de travail le plus productif consiste à commencer avec le CCS comme filtre, puis à utiliser Device Memory pour confirmer votre hypothèse.

Tout d'abord, ouvrez votre ventilation INP par CCS. Si votre INP au 75e centile est bon pour les visiteurs Très performants (CCS 1) et Performants (CCS 2) mais échoue pour les Limités (CCS 3) et en dessous, vous avez un goulot d'étranglement lié au CPU ou à la mémoire plutôt qu'au réseau. Cela écarte toute une catégorie de correctifs (préchargement, indications de connexion, optimisation du CDN) et concentre votre attention sur le temps d'exécution JavaScript : tâches longues, poids des gestionnaires d'événements d'entrée et scripts tiers qui s'exécutent à chaque interaction.

Ensuite, filtrez par Device Memory pour voir quels paliers de RAM génèrent les pires résultats. Si les appareils avec 1 Go représentent une part disproportionnée des mauvais scores INP, vous connaissez le seuil. Les scripts qui sont acceptables à 4 Go peuvent devenir des candidats au report ou à la suppression sur la seule base de ces données.

Pour les sites ayant une audience mondiale, associez le CCS à la dimension Pays. Les marchés d'Asie du Sud et du Sud-Est, d'Afrique subsaharienne et de certaines régions d'Amérique latine présentent de fortes concentrations d'appareils Restreints et Très limités. Une ventilation CCS filtrée par pays vous montrera où l'écart est le plus important et vous aidera à prioriser le marché à cibler en premier.

Le palier Inconnu (CCS 0) couvre l'ensemble du trafic Firefox et Safari, ainsi que toute session pour laquelle les API n'ont renvoyé aucune valeur. Ne l'ignorez pas. Sur les sites avec une part importante de Firefox ou de Safari, Inconnu peut représenter un quart ou plus de toutes les sessions. Cela ne signifie pas que ces utilisateurs ont de mauvais appareils ; cela signifie que le signal était indisponible. Traitez Inconnu comme un segment distinct plutôt que de l'intégrer à votre base de référence.

Que faire avec ces données

Si les visiteurs de niveau CCS 3, 4 ou 5 représentent plus de 15 % de votre trafic et que leur INP est constamment supérieur à 200 ms, l'ensemble des correctifs est spécifique :

• Profilez vos tâches les plus longues sur un appareil bridé dans les Chrome DevTools. L'attribution des tâches dans le panneau Performance montrera quels scripts sont responsables.
• Déplacez les scripts tiers non critiques derrière un déclencheur d'interaction ou de visibilité afin qu'ils ne soient pas en concurrence pour le thread principal pendant la fenêtre de chargement initial.
• Réduisez la taille des bundles JavaScript sur les chemins critiques. Chaque kilo-octet analysé sur un appareil avec peu de mémoire coûte plus cher que sur un appareil haut de gamme car le compilateur JIT a moins d'espace pour mettre en cache le code compilé.
• Utilisez scheduler.yield() ou setTimeout(0) pour fragmenter les tâches longues et donner au navigateur une chance de traiter les événements d'entrée entre les morceaux.

CoreDash fait remonter les dimensions CCS et Device Memory aux côtés de chaque métrique Core Web Vitals, ce qui vous permet de confirmer si un correctif qui a amélioré l'INP sur les appareils haut de gamme a également fait bouger les chiffres pour vos visiteurs Restreints, et pas seulement pour vos utilisateurs dans le meilleur des cas.