Dimension CoreDash : Vitesse réseau

Dimension : Vitesse réseau (dl)

La dimension dl rapporte 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 collecte cette valeur à partir de l'API Network Information du navigateur et regroupe les visites par paliers de bande passante. Chaque ligne du tableau CoreDash représente une tranche de vitesse spécifique, ce qui vous permet de comparer côte à côte vos scores Core Web Vitals entre les utilisateurs du haut débit rapide, les connexions à vitesse modérée et les connexions lentes ou mobiles.

La bande passante est l'une des deux caractéristiques réseau qui façonnent la performance du 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 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 réseau est importante 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 de temps de transfert pur, avant de tenir compte de la latence ou de la charge de traitement. Cette différence seule peut faire basculer un score LCP positif dans la zone « à améliorer ».

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 serveur lente est lente quelle que soit la vitesse de connexion. Si le TTFB est médiocre sur tous les paliers 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.

Interaction to Next Paint est presque entièrement limité par le processeur. L'INP mesure le temps entre une action de l'utilisateur et la mise à jour visuelle suivante. Une exécution JavaScript lourde, des tâches longues et le blocage du thread principal (main thread) entraînent de mauvais scores INP. Une connexion lente peut retarder le téléchargement initial des bundles JavaScript, ce qui peut indirectement dégrader l'INP si les scripts sont encore en cours d'analyse (parsing) lorsque l'utilisateur interagit pour la première fois avec la page. Mais une fois les scripts chargés, la performance de l'INP est déterminée par la puissance de calcul de l'appareil, et non par le réseau.

En 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 rapporte le LCP Load Time séparément, ce qui permet de confirmer facilement si les utilisateurs lents attendent le réseau ou autre chose.

Lecture des données

Le trafic de CoreDash sur les sites types se décompose en trois paliers de bande passante. Comprendre ce que représente chaque palier vous aide à prioriser les correctifs.

Haut débit rapide : 50 Mbps et plus

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

Vitesse modérée : 10 à 50 Mbps

Environ 40 % du trafic CoreDash se situe dans cette plage. Ce palier 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 comportant des images non optimisées ou plusieurs ressources bloquant le rendu commenceront à échouer aux seuils LCP dans ce palier. C'est le palier 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 en cas de signal médiocre 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 palier sont presque certains, à moins que l'image LCP n'ait été compressée agressivement, servie via un nœud edge de CDN proche de l'utilisateur et préchargée correctement. Si votre entreprise sert des utilisateurs dans des régions aux infrastructures historiquement plus lentes, vérifiez la dimension Country de CoreDash parallèlement à dl pour confirmer si le trafic à basse vitesse se concentre géographiquement.

Flux de travail de débogage

1. Filtrez sur le palier 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 en échec, la ressource LCP est trop volumineuse pour les connexions lentes. Compressez davantage l'image, passez au format AVIF et confirmez que la ressource est servie depuis un CDN avec un nœud edge proche des utilisateurs concernés.
2. Croisez avec la dimension Country. Si les utilisateurs à basse 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 edge de 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 sur les différents paliers. Si l'INP se dégrade sur les paliers de bande passante faible mais pas sur les paliers élevés, c'est que de gros bundles JavaScript sont encore en cours de téléchargement lors de la première interaction des utilisateurs. Fractionnez votre JavaScript, différez les scripts non critiques et envisagez de céder le contrôle au thread principal (yield) pendant l'initialisation pour réduire l'exposition de l'INP pendant la phase d'analyse (parse phase).

Règle d'or en ingénierie

• Visez une taille de fichier d'image LCP inférieure à 100 Ko (AVIF ou WebP) pour maintenir le LCP Load Time en dessous 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 (above-the-fold) doit rester inférieur à 500 Ko pour offrir un LCP raisonnable sur des connexions à 10 Mbps dans le seuil des 2,5 secondes.
• Utilisez fetchpriority="high" sur l'image LCP et préchargez-la dans le <head> du document afin que le navigateur ne gaspille pas de bande passante sur des ressources de priorité inférieure en premier.
• Servez tous les actifs 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 éloigné et ajoute 300 ms de latence avant l'arrivée du premier octet.
• Si plus de 15 % de votre trafic se situe dans le palier inférieur à 10 Mbps et que le LCP échoue pour ces utilisateurs, traitez l'optimisation des images et la couverture du CDN comme des problèmes de priorité P1 avant de traiter quoi que ce soit d'autre.