Dimension Core/Dash : Système d'exploitation
Isolez les régressions de performance spécifiques aux plateformes en segmentant le trafic par système d'exploitation.
Dimension : Système d'exploitation (os)
La dimension Système d'exploitation regroupe les données de performance par plateforme exécutée sur l'appareil de l'utilisateur : Android, iOS, Windows, macOS, Linux ou ChromeOS. Alors que la dimension navigateur isole les différences de moteur de rendu, la dimension OS révèle les contraintes matérielles, la gestion des ressources système et les particularités propres à chaque plateforme dont le navigateur hérite.
L'OS est la couche intermédiaire entre votre code et le matériel. Il contrôle la planification des tâches par le CPU, l'allocation de la mémoire et la priorisation des requêtes réseau. Deux navigateurs identiques sur des systèmes d'exploitation différents peuvent produire des Core Web Vitals très différents.

Le paysage des plateformes
Selon StatCounter (2025), Android domine le trafic web mondial avec 39 %, suivi par Windows avec 30 %, iOS avec 16 %, macOS avec 8 %, Linux avec 4 % et ChromeOS avec 2 %. La répartition de votre trafic varie selon votre secteur d'activité. Les produits SaaS B2B enregistrent un trafic Windows et macOS plus important. Les applications grand public penchent vers Android et iOS.
Caractéristiques de performance selon l'OS
Android
Android est la plateforme la plus hétérogène. Elle équipe des appareils allant du téléphone d'entrée de gamme à 80 $ aux flagships à 1 500 $. Votre segment Android contient donc à la fois vos utilisateurs les plus rapides et les plus lents. Le constat clé : les performances moyennes d'Android sont tirées vers le bas par la longue traîne des appareils d'entrée de gamme. Dans les données CoreDash, l'INP au p75 d'Android est généralement 40 à 60 % plus élevé que celui d'iOS, car l'appareil Android médian possède un CPU moins puissant.
Filtrez le trafic Android par la dimension Client Capability Score pour séparer les utilisateurs de flagships (aux performances similaires à iOS) des utilisateurs d'appareils d'entrée de gamme (qui ont besoin de pages plus légères).
iOS
Apple contrôle l'ensemble du matériel et du logiciel, ce qui produit des performances remarquablement homogènes. La gamme d'appareils est étroite (de l'iPhone 12 à l'iPhone 16) et tous exécutent le moteur WebKit de Safari, quel que soit le nom du navigateur affiché. Le trafic iOS dans CoreDash montre généralement un LCP de 15 à 25 % meilleur et un INP de 30 à 40 % meilleur que ceux d'Android.
Le piège : si vous testez uniquement sur iOS, votre site semble rapide. Vos utilisateurs Android (2,5 fois plus nombreux que ceux d'iOS dans le monde) vivent une expérience bien différente.
Windows
Windows domine le trafic sur ordinateur de bureau. Les performances y sont généralement solides car le matériel de bureau est puissant. Cependant, les environnements d'entreprise Windows introduisent des problèmes spécifiques : les serveurs proxy d'entreprise gonflent le TTFB, les extensions de navigateur obligatoires injectent des scripts qui dégradent l'INP, et les politiques informatiques peuvent imposer d'anciennes versions de navigateurs.
macOS
Le trafic macOS provient d'un parc matériel plutôt haut de gamme. Les performances sont généralement excellentes. Si les utilisateurs de macOS affichent de mauvaises métriques, le problème vient presque certainement de votre code (JavaScript trop lourd, images non optimisées) et non de la plateforme.
Linux and ChromeOS
Ils représentent de faibles parts de trafic, mais des profils d'utilisateurs distincts. Les utilisateurs de Linux sont souvent des développeurs équipés d'un matériel rapide. Les utilisateurs de ChromeOS utilisent souvent des Chromebooks dotés d'une mémoire RAM et d'un stockage limités. Si ChromeOS affiche un mauvais INP, vérifiez si l'empreinte mémoire de votre JavaScript dépasse les contraintes de l'appareil.
Procédure de débogage
- Comparez d'abord Android et iOS : Cela révèle l'écart matériel sur mobile. Si l'INP d'Android est de 250 ms et celui d'iOS de 90 ms, vous avez un problème de complexité JavaScript qui ne se manifeste que sur les CPU plus faibles. La solution consiste à réduire le travail sur le main thread, pas à acheter des serveurs plus rapides.
- Recherchez les anomalies d'entreprise sur Windows : Si le TTFB de Windows est supérieur de 200 ms à celui de macOS, examinez les proxies d'entreprise et les VPN. Ce sont des problèmes d'infrastructure côté utilisateur, mais les comprendre vous évite de chercher de faux problèmes de serveur.
- Combinez OS et navigateur pour plus de précision : « Safari sur iOS » n'a rien à voir avec « Chrome sur Android ». Filtrez par OS + navigateur pour déterminer si une régression est globale ou spécifique à une combinaison navigateur/OS.
Règles empiriques d'ingénierie
- INP Android sous les 200 ms : Si votre INP iOS est validé mais que celui d'Android échoue, réduisez le temps d'exécution JavaScript. Le CPU Android d'entrée de gamme est votre véritable budget de performance.
- Aucun OS ne doit être deux fois plus lent qu'un autre : Un écart de 50 % est normal (différences matérielles). Un écart supérieur à 100 % signale un bug spécifique à la plateforme ou un chemin de code non optimisé.
- Testez sur de vrais appareils Android : Le bridage du CPU dans les Chrome DevTools simule le matériel lent, mais les tests sur des appareils réels révèlent les problèmes d'ordonnancement au niveau de l'OS que l'émulation ne détecte pas.
La dimension Système d'exploitation révèle si vos problèmes de performance sont universels ou spécifiques à une plateforme. Cette distinction détermine s'il faut corriger votre code ou revoir votre stratégie de diffusion.