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. Elles répondent à des questions différentes mais se complètent directement.

Device Memory (code de groupe m) indique la tranche de RAM que le navigateur renvoie à partir de 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, de sorte que vous verrez 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.

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

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 sur le Wi-Fi. Combiner la mémoire, les cœurs et le type de connexion en une seule échelle ordinale vous permet de filtrer et de comparer les données de performance sans exécuter une répartition distincte pour chaque variable.

Prise en charge des navigateurs 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 signalent 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 les appareils Android sont ceux où 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 avec 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é de l'appareil 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 en raison de cette distinction que la dimension CCS apparaît 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 est déjà sous pression de mémoire avant même que votre JavaScript ne s'exécute : un garbage collection plus agressif, des abandons d'onglets plus fréquents et moins de marge pour la compilation JIT se traduisent tous directement par des durées de tâche plus longues. Un site qui réussit l'INP sur un téléphone moderne à 180 ms peut facilement se situer à 400 ms sur un appareil Contraint.

Le chapitre Performance du Web Almanac 2025 confirme la tendance : les taux de réussite INP sur mobile atteignent 77 % au total, mais l'écart entre les appareils puissants et ceux d'entrée de gamme dans ce chiffre est important. 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 avec des 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 reflows qui se terminent après que le navigateur a déjà validé une frame.

Comment utiliser CCS et Device Memory dans CoreDash

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

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

Ensuite, filtrez par Device Memory pour voir quelles tranches de RAM entraînent 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 être des candidats au report ou à la suppression sur la base de ces seules données.

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

La tranche Inconnu (CCS 0) couvre tout le trafic Firefox et Safari, ainsi que toute session où 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 n'était pas disponible. Traitez Inconnu comme un segment distinct plutôt que de l'intégrer à votre base de référence.

Que faire de ces données

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

• Profilez vos tâches les plus longues sur un appareil bridé dans 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 du bundle JavaScript sur les chemins critiques. Chaque kilo-octet analysé sur un appareil à faible mémoire coûte plus cher que sur un modèle phare, car le compilateur JIT a moins d'espace pour mettre en cache le code compilé.
• Utilisez scheduler.yield() ou setTimeout(0) pour fractionner les tâches longues et donner au navigateur une chance de traiter les événements d'entrée entre les blocs.

CoreDash affiche les dimensions CCS et Device Memory à côté de chaque métrique des Core Web Vitals afin que vous puissiez 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 Contraints, et pas seulement pour vos utilisateurs les mieux équipés.