Dimension CoreDash : Type d'appareil

Dimension : Type d'appareil (d)

La dimension Type d'appareil divise vos données de Real User Monitoring en deux catégories : mobile et desktop. Il s'agit du tout premier filtre, et du plus important, dans toute investigation de performance car le mobile et le desktop sont des environnements informatiques fondamentalement différents. Processeurs différents, conditions réseau différentes, tailles de viewport différentes, moteurs de navigateur différents.

Si vous observez les Core Web Vitals agrégés 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, le mobile sous-performe constamment par rapport au desktop. Selon le Web Almanac 2025, seulement 48 % des origines mobiles réussissent 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 desktops n'ont pas :

• Limitation du processeur (CPU throttling) : Un téléphone Android milieu de gamme a environ 3 à 5 fois moins de puissance de traitement qu'un desktop. Le 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 du viewport : Les écrans plus petits modifient l'élément qui devient le LCP. Votre image hero sur desktop peut se retrouver en dessous d'un bloc de texte sur mobile, changeant complètement la cible d'optimisation.

Distribution des types d'appareils sur CoreDash

Sur l'ensemble des projets CoreDash, la répartition typique du trafic est de 65 % mobile et 35 % desktop. Les sites e-commerce penchent davantage vers le mobile (70-75 %), tandis que les produits SaaS B2B voient souvent une répartition 50/50, voire une domination du desktop.

L'écart de performance dans les données CoreDash reflète la tendance mondiale. Le p75 du LCP mobile est en moyenne de 2,8 s contre 1,9 s sur desktop. Pour l'INP, l'écart est encore plus grand : le p75 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 est en concurrence avec plus de contention de ressources sur un processeur plus lent. Si votre LCP desktop est inférieur à 2,0 s mais que le mobile dépasse 3,0 s, le problème vient rarement du fichier image lui-même. C'est le pipeline de distribution.

Interaction to Next Paint (INP)

C'est là que l'écart entre les appareils frappe le plus fort. Les gestionnaires d'événements JavaScript qui semblent instantanés sur un i7 de desktop peuvent bloquer le thread principal pendant plus de 300 ms sur un Snapdragon 665. Filtrez par mobile, triez par impact sur l'INP, et vous trouverez les interactions exactes qui posent problème sur de vrais téléphones. Je vois cela 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 ont réellement en main.

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 se réduire ou se redimensionner sur mobile. Les métriques de fallback de police qui s'alignent sur desktop provoquent des décalages visibles sur des viewports plus petits. Les polices Web ont un rendu différent selon les navigateurs mobiles et desktop, et la densité physique des pixels affecte l'arrondi des sous-pixels.

Flux de travail de débogage

1. Commencez chaque investigation avec le filtre d'appareil : Avant de regarder toute autre dimension, divisez par type d'appareil. Si votre LCP agrégé 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/nécessite une amélioration/médiocre pour chaque type d'appareil. Un desktop avec 85 % de bons résultats et un mobile avec 45 % raconte une histoire complètement différente du p75 seul.
3. Combinez avec d'autres dimensions : Une fois le type d'appareil isolé, ajoutez un deuxième 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 back-forward mobiles 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 réussit mais que le mobile échoue, concentrez-vous sur la réduction du Load Delay (fetchpriority, preload) et du TTFB (mise en cache edge, CDN).
• INP mobile inférieur à 200 ms : Testez chaque fonctionnalité interactive sur un véritable appareil Android milieu de gamme. La limitation du processeur des Chrome DevTools (4x) s'en rapproche, mais les tests sur de vrais appareils sont préférables.
• N'optimisez jamais uniquement pour le desktop : Si votre trafic mobile dépasse 50 % (et c'est presque certainement le cas), la performance mobile est votre signal de classement dans les recherches. Google utilise les données CrUX mobiles pour le classement SEO.

Le type d'appareil n'est pas un filtre facultatif. C'est la première question que vous posez : « Est-ce un problème mobile ou un problème desktop ? » Toute décision d'optimisation découle de cette réponse.