Dimension CoreDash : Type d'appareil

Dimension : Type d'appareil (d)

La dimension Type d'appareil divise vos données RUM en deux catégories : mobile et desktop. C'est le tout premier filtre critique dans toute investigation de performance car le mobile et le desktop sont des environnements informatiques fondamentalement différents. Différents processeurs, différentes conditions réseau, différentes tailles de fenêtres d'affichage, différents moteurs de navigateur.

Si vous analysez vos Core Web Vitals globaux sans filtrer par type d'appareil, vous faites la moyenne de deux populations qui n'ont presque rien en commun. Cette moyenne est au mieux trompeuse.

L'écart de performance mobile

Les appareils mobiles représentent environ 62 % du trafic web mondial selon Statista (2025). Pourtant, les performances sur mobile sont systématiquement inférieures à celles sur desktop. Selon le Web Almanac 2025, seulement 48 % des origines mobiles valident les trois Core Web Vitals, contre 56 % sur desktop. Il s'agit d'un écart de 8 points de pourcentage.

Cet écart existe car les appareils mobiles font face à trois contraintes que les ordinateurs de bureau n'ont pas :

• Bridage du processeur (CPU throttling) : Un téléphone Android milieu de gamme a environ 3 à 5 fois moins de puissance de traitement qu'un ordinateur de bureau. Un JavaScript qui s'exécute en 50 ms sur desktop peut prendre 200 ms sur mobile, poussant l'INP au-delà du seuil « bon ».
• Latence réseau : Les connexions mobiles (4G/5G) ont des temps d'aller-retour plus élevés et plus de variance que les connexions filaires. Cela gonfle le TTFB et le Load Delay du LCP.
• Taille de la fenêtre d'affichage (Viewport) : Les écrans plus petits modifient l'élément qui devient le LCP. Votre image hero sur desktop peut se réduire en dessous d'un bloc de texte sur mobile, changeant complètement la cible d'optimisation.

Distribution des types d'appareils CoreDash

À travers les projets CoreDash, la répartition typique du trafic est de 65 % sur mobile et 35 % sur desktop. Les sites e-commerce penchent davantage vers le mobile (70-75 %), tandis que les produits SaaS B2B observent souvent une répartition 50/50, voire une dominance du desktop.

L'écart de performance dans les données CoreDash reflète la tendance mondiale. Le p75 du LCP sur mobile est en moyenne de 2,8 s comparé à 1,9 s sur desktop. Pour l'INP, l'écart est encore plus important : le p75 sur mobile se situe autour de 220 ms tandis que le desktop oscille près de 120 ms.

Analyse spécifique aux métriques

Largest Contentful Paint (LCP)

Le LCP sur mobile est presque toujours pire que sur desktop. La cause principale est le Load Delay : les navigateurs mobiles découvrent l'image LCP plus tard car le HTML met plus de temps à arriver (TTFB plus élevé) et le scanner de préchargement entre en compétition avec davantage de conflits de ressources sur un processeur plus lent. Si votre LCP sur desktop est inférieur à 2,0 s mais que sur mobile il dépasse 3,0 s, le problème vient rarement du fichier image lui-même. C'est le pipeline de livraison.

Interaction to Next Paint (INP)

C'est ici que l'écart entre appareils frappe le plus fort. Les gestionnaires d'événements JavaScript qui semblent instantanés sur un i7 de bureau peuvent bloquer le thread principal pendant plus de 300 ms sur un Snapdragon 665. Filtrez par mobile, triez par impact INP, et vous trouverez les interactions exactes qui échouent sur de vrais téléphones. Je le constate constamment : les développeurs testent sur des MacBook Pro et déploient des interactions qui sont inutilisables sur les appareils que 65 % de leurs utilisateurs possèdent réellement.

Cumulative Layout Shift (CLS)

Les différences de CLS entre les types d'appareils remontent généralement au responsive design. Les emplacements publicitaires qui réservent de l'espace sur desktop peuvent s'effondrer ou se redimensionner sur mobile. Les métriques de la police de fallback qui s'alignent sur desktop provoquent des décalages visibles sur des fenêtres d'affichage plus petites. Les polices web s'affichent différemment sur les navigateurs mobiles et de bureau, et la densité de pixels physiques affecte l'arrondi sous-pixel.

Flux de travail de débogage

1. Commencez chaque investigation avec le filtre d'appareil : Avant d'examiner toute autre dimension, divisez par Type d'appareil. Si votre LCP global est de 2,5 s, vous pourriez trouver le desktop à 1,8 s et le mobile à 3,1 s. Le « problème » est exclusivement mobile.
2. Comparez les distributions, pas seulement le p75 : Vérifiez la distribution bon/besoin d'amélioration/médiocre pour chaque type d'appareil. Un desktop avec 85 % de « bon » et un mobile avec 45 % de « bon » racontent une histoire complètement différente que le p75 seul.
3. Combinez avec d'autres dimensions : Une fois que vous avez isolé le type d'appareil, ajoutez un second filtre. Type d'appareil + Pays révèle si l'écart mobile est mondial ou concentré dans des régions avec des réseaux plus lents. Type d'appareil + Type de navigation montre si les navigations avant-arrière (back-forward) sur mobile sont correctement mises en cache.

Règle d'or de l'ingénierie

• LCP mobile inférieur à 2,5 s : C'est le seuil que Google utilise pour « bon ». Si votre desktop passe mais que le mobile échoue, concentrez-vous sur la réduction du Load Delay (fetchpriority, preload) et du TTFB (mise en cache en périphérie, CDN).
• INP mobile inférieur à 200 ms : Testez chaque fonctionnalité interactive sur un véritable appareil Android de milieu de gamme. Le bridage du processeur (CPU throttling) des Chrome DevTools (4x) s'en rapproche, mais le test sur appareil réel est préférable.
• N'optimisez jamais uniquement pour le desktop : Si votre trafic mobile dépasse 50 % (ce qui est très certainement le cas), la performance mobile est votre signal de classement de recherche. Google utilise les données CrUX mobiles pour le classement.

Le Type d'appareil n'est pas un filtre facultatif. C'est la première question que vous posez : « S'agit-il d'un problème sur mobile ou sur desktop ? » Chaque décision d'optimisation découle de cette réponse.