Dimension Core/Dash : Vitesse du réseau

Dimension : Vitesse du réseau (dl)

La dimension dl indique la bande passante de téléchargement effective de la connexion de chaque utilisateur au moment de la visite de la page, mesurée en mégabits par seconde (Mbps). CoreDash recueille cette valeur à partir de l'API Network Information du navigateur et regroupe les visites par niveaux de bande passante. Chaque ligne du tableau CoreDash représente un segment de vitesse spécifique, ce qui vous permet de comparer vos scores Core Web Vitals entre les utilisateurs du haut débit rapide, des connexions à vitesse modérée et des connexions lentes ou mobiles côte à côte.

La bande passante est l'une des deux caractéristiques du réseau qui déterminent les performances de chargement des pages. L'autre est la latence, qui contrôle le temps d'aller-retour vers le serveur. La dimension dl de CoreDash isole la variable de la bande passante afin que vous puissiez répondre à une question concrète : vos scores Core Web Vitals se dégradent-ils à mesure que la vitesse de connexion diminue, et de combien ?

Pourquoi la vitesse du réseau compte pour les Core Web Vitals

La bande passante de téléchargement a un impact direct et mesurable sur le Largest Contentful Paint. Le LCP est presque toujours déclenché par une image hero, une grande image d'arrière-plan ou une police web lourde. Sur une connexion à 100 Mbps, une image hero de 400 Ko arrive en environ 32 millisecondes de temps de transfert. Sur une connexion à 5 Mbps, cette même image prend plus de 640 millisecondes uniquement en temps de transfert, avant même de prendre en compte la latence ou la surcharge de traitement. Cette seule différence peut faire basculer un score LCP satisfaisant dans la plage « needs improvement ».

Le Time to First Byte est moins sensible à la bande passante. Le TTFB est dominé par le temps de traitement du serveur et la latence d'aller-retour du réseau, et non par le volume d'octets transférés. Une réponse lente du serveur est lente quelle que soit la vitesse de connexion. Si le TTFB est médiocre dans tous les niveaux de bande passante dans CoreDash, cela indique des problèmes de serveur ou de CDN plutôt qu'un problème de bande passante côté client.

L'Interaction to Next Paint est presque entièrement lié au processeur (CPU). L'INP mesure le temps entre l'entrée de l'utilisateur et la prochaine mise à jour visuelle. Une lourde exécution JavaScript, des tâches longues et le blocage du thread principal entraînent de mauvais scores INP. Une connexion lente peut retarder le téléchargement initial des bundles JavaScript, ce qui peut indirectement aggraver l'INP si les scripts sont toujours en cours d'analyse lors de la première interaction de l'utilisateur avec la page. Mais une fois les scripts chargés, les performances de l'INP sont déterminées par la puissance de traitement de l'appareil, et non par le réseau.

Dans la pratique, les problèmes de bande passante apparaissent clairement dans le LCP Load Time, la sous-partie du LCP qui mesure le temps passé par le navigateur à télécharger la ressource LCP après sa découverte. CoreDash signale le LCP Load Time séparément, ce qui permet de confirmer facilement si les utilisateurs lents attendent après le réseau ou autre chose.

Lecture des données

Le trafic de CoreDash sur les sites typiques se divise en trois niveaux de bande passante. Comprendre ce que représente chaque niveau vous aide à hiérarchiser les corrections.

Haut débit rapide : 50 Mbps et plus

Environ 35 % du trafic CoreDash se situe dans ce niveau. Cela inclut les connexions fibre, le haut débit par câble et les utilisateurs mobiles 5G dans de bonnes conditions de signal. Les vitesses de téléchargement moyennes de la 5G en 2025 se situent autour de 184 Mbps, et les moyennes du haut débit fixe aux États-Unis ont atteint 214 Mbps. Il est peu probable que les utilisateurs de ce niveau subissent des retards LCP liés au réseau sur des pages bien optimisées. Si les scores LCP sont médiocres ici, le problème est le temps de réponse du serveur, les ressources bloquant le rendu ou le délai de découverte de l'élément LCP, et non la bande passante.

Vitesse modérée : 10 à 50 Mbps

Environ 40 % du trafic CoreDash se situe dans cette plage. Ce niveau couvre les anciennes connexions par câble, la 4G LTE dans des conditions de signal moyennes (les vitesses réelles typiques de la 4G se situent entre 10 et 50 Mbps) et certains utilisateurs du sans-fil fixe. Une image hero de 300 Ko prend entre 48 et 240 millisecondes de temps de transfert à ces vitesses. Les pages avec des images non optimisées ou plusieurs ressources bloquant le rendu commenceront à échouer aux seuils LCP dans ce niveau. C'est le niveau où les choix de format d'image (WebP, AVIF) et le préchargement agressif avec fetchpriority="high" font une différence mesurable.

Lent et Mobile : Moins de 10 Mbps

Environ 25 % du trafic CoreDash provient de connexions inférieures à 10 Mbps. Cela inclut les utilisateurs mobiles 3G, les connexions fixes rurales et les utilisateurs 4G dans de mauvaises conditions de signal ou de réseau encombré. À 5 Mbps, une image de 400 Ko prend plus de 640 millisecondes de temps de transfert. Les échecs LCP dans ce niveau sont presque certains, à moins que l'image LCP n'ait été compressée de manière agressive, servie via un nœud périphérique CDN proche de l'utilisateur et correctement préchargée. Si votre entreprise sert des utilisateurs dans des régions aux infrastructures historiquement plus lentes, vérifiez la dimension Country (Pays) de CoreDash aux côtés de dl pour confirmer si le trafic à faible vitesse se concentre géographiquement.

Flux de travail de débogage

1. Filtrez sur le niveau inférieur à 10 Mbps dans CoreDash et vérifiez le LCP Load Time. Si le LCP Load Time est le principal contributeur à un score LCP défaillant, la ressource LCP est trop volumineuse pour les connexions lentes. Compressez l'image davantage, passez au format AVIF et confirmez que la ressource est servie par un CDN doté d'un nœud périphérique à proximité des utilisateurs concernés.
2. Faites des recoupements avec la dimension Country (Pays). Si les utilisateurs à faible vitesse se concentrent dans des pays spécifiques, vérifiez si votre CDN a une bonne couverture dans ces régions. Un utilisateur sur une connexion à 15 Mbps servi par un nœud périphérique CDN situé à 200 ms aura une expérience bien pire qu'un utilisateur à la même vitesse servi par un nœud situé à 10 ms.
3. Vérifiez les scores INP et TTFB à tous les niveaux. Si l'INP s'aggrave aux niveaux de bande passante faibles mais pas aux niveaux élevés, de gros bundles JavaScript sont toujours en cours de téléchargement lorsque les utilisateurs interagissent pour la première fois. Fractionnez votre JavaScript, différez les scripts non critiques et envisagez de procéder à un yielding au thread principal lors de l'initialisation pour réduire l'exposition de l'INP pendant la phase d'analyse.

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

• Ciblez une taille de fichier d'image LCP inférieure à 100 Ko (AVIF ou WebP) pour maintenir le LCP Load Time à moins de 200 ms, même sur des connexions à 5 Mbps.
• Le poids total de la page pour les ressources au-dessus de la ligne de flottaison doit rester inférieur à 500 Ko pour fournir un LCP raisonnable sur des connexions à 10 Mbps dans le seuil de 2,5 secondes.
• Utilisez fetchpriority="high" sur l'image LCP et préchargez-la dans le <head> du document pour que le navigateur ne gaspille pas d'abord la bande passante sur des ressources de priorité inférieure.
• Servez tous les assets statiques depuis un CDN. Les chiffres de bande passante dans CoreDash mesurent la connexion du client, pas celle du serveur. Une connexion client rapide n'aide pas si le serveur est géographiquement distant et ajoute 300 ms de latence avant l'arrivée du premier octet.
• Si plus de 15 % de votre trafic se situe dans le niveau inférieur à 10 Mbps et que le LCP échoue pour ces utilisateurs, traitez l'optimisation des images et la couverture CDN comme des problèmes P1 avant d'aborder toute autre chose.