Dimensión de Core/Dash: Network Speed
Segmenta las Core Web Vitals por la velocidad de descarga del usuario para encontrar qué niveles de ancho de banda están perjudicando tu LCP.
Dimensión: Network Speed (dl)
La dimensión dl informa del ancho de banda de descarga efectivo de la conexión de cada usuario en el momento de la visita a la página, medido en Megabits por segundo (Mbps). CoreDash recopila este valor de la Network Information API del navegador y agrupa las visitas en niveles de ancho de banda. Cada fila en la tabla de CoreDash representa un rango de velocidad específico, por lo que puedes comparar tus puntuaciones de Core Web Vitals entre usuarios de banda ancha rápida, conexiones de velocidad moderada y conexiones lentas o móviles, unas junto a otras.
El ancho de banda es una de las dos características de red que configuran el rendimiento de carga de la página. La otra es la latencia, que controla el tiempo de ida y vuelta al servidor. La dimensión dl de CoreDash aísla la variable del ancho de banda para que puedas responder a una pregunta concreta: ¿se están degradando tus puntuaciones de Core Web Vitals a medida que cae la velocidad de la conexión, y en qué medida?

Por qué la Network Speed importa para las Core Web Vitals
El ancho de banda de descarga tiene un impacto directo y medible en el Largest Contentful Paint. El LCP casi siempre se activa por una imagen principal, una imagen de fondo de gran tamaño o una fuente web pesada. En una conexión de 100 Mbps, una imagen principal de 400 KB llega en unos 32 milisegundos de tiempo de transferencia. En una conexión de 5 Mbps, esa misma imagen tarda más de 640 milisegundos solo en tiempo de transferencia, antes de tener en cuenta cualquier latencia o sobrecarga de procesamiento. Solo esa diferencia puede empujar una puntuación LCP aceptable al rango de "necesita mejora".
El Time to First Byte es menos sensible al ancho de banda. El TTFB está dominado por el tiempo de procesamiento del servidor y la latencia de ida y vuelta de la red, no por el volumen de bytes transferidos. Una respuesta lenta del servidor es lenta en cualquier velocidad de conexión. Si el TTFB es deficiente en todos los niveles de ancho de banda en CoreDash, eso apunta a problemas del servidor o de la CDN en lugar de a un problema de ancho de banda del lado del cliente.
El Interaction to Next Paint está casi por completo limitado por la CPU. El INP mide el tiempo entre la entrada del usuario y la siguiente actualización visual. La ejecución pesada de JavaScript, las tareas largas y el bloqueo del hilo principal provocan puntuaciones de INP deficientes. Una conexión lenta puede retrasar la descarga inicial de los paquetes de JavaScript, lo que puede empeorar indirectamente el INP si los scripts aún se están analizando cuando el usuario interactúa por primera vez con la página. Pero una vez cargados los scripts, el rendimiento del INP está determinado por la potencia de procesamiento del dispositivo, no por la red.
En la práctica, los problemas de ancho de banda surgen claramente en el LCP Load Time, la subparte del LCP que mide cuánto tiempo pasó el navegador descargando el recurso LCP tras ser descubierto. CoreDash informa sobre el LCP Load Time por separado, lo que hace que sea sencillo confirmar si los usuarios con conexiones lentas están esperando a la red o a alguna otra cosa.
Lectura de los Datos
El tráfico de CoreDash en sitios típicos se divide en tres niveles de ancho de banda. Comprender qué representa cada nivel te ayuda a priorizar las correcciones.
Banda Ancha Rápida: 50 Mbps y superior
Aproximadamente el 35% del tráfico de CoreDash se encuentra en este nivel. Esto incluye conexiones de fibra, banda ancha por cable y usuarios móviles 5G en buenas condiciones de señal. Las velocidades promedio de descarga 5G en 2025 se sitúan en torno a 184 Mbps, y los promedios de banda ancha fija en los EE. UU. han alcanzado los 214 Mbps. Es poco probable que los usuarios en este nivel experimenten retrasos del LCP causados por la red en páginas bien optimizadas. Si las puntuaciones de LCP son deficientes aquí, el problema es el tiempo de respuesta del servidor, los recursos que bloquean el renderizado o el retraso en el descubrimiento del elemento LCP, no el ancho de banda.
Velocidad Moderada: de 10 a 50 Mbps
Aproximadamente el 40% del tráfico de CoreDash aterriza en este rango. Este nivel abarca conexiones de cable más antiguas, 4G LTE en condiciones de señal promedio (las velocidades reales típicas del 4G oscilan entre 10 y 50 Mbps) y algunos usuarios de conexión inalámbrica fija. Una imagen principal de 300 KB tarda entre 48 y 240 milisegundos de tiempo de transferencia a estas velocidades. Las páginas con imágenes sin optimizar o múltiples recursos que bloquean el renderizado comenzarán a fallar en los umbrales de LCP en este nivel. Este es el nivel donde las opciones de formato de imagen (WebP, AVIF) y la precarga agresiva con fetchpriority="high" marcan una diferencia medible.
Lento y Móvil: Por debajo de 10 Mbps
Aproximadamente el 25% del tráfico de CoreDash proviene de conexiones por debajo de 10 Mbps. Esto incluye usuarios de dispositivos móviles 3G, conexiones fijas rurales y usuarios 4G en malas condiciones de señal o redes congestionadas. A 5 Mbps, una imagen de 400 KB tarda más de 640 milisegundos de tiempo de transferencia. Los fallos del LCP en este nivel son casi seguros a menos que la imagen LCP se haya comprimido de manera agresiva, se sirva a través de un nodo de borde de la CDN cercano al usuario y se precargue correctamente. Si tu negocio presta servicios a usuarios en regiones con una infraestructura históricamente más lenta, verifica la dimensión de País en CoreDash junto con dl para confirmar si el tráfico de baja velocidad se concentra geográficamente.
Flujo de Trabajo de Depuración
- Filtra hasta el nivel de menos de 10 Mbps en CoreDash y verifica el LCP Load Time. Si el LCP Load Time es el principal contribuyente a una puntuación LCP deficiente, el recurso LCP es demasiado grande para conexiones lentas. Comprime más la imagen, cambia al formato AVIF y confirma que el recurso se sirve desde una CDN con un nodo de borde cercano a los usuarios afectados.
- Cruza los datos con la dimensión de País. Si los usuarios de baja velocidad se concentran en países específicos, comprueba si tu CDN tiene buena cobertura en esas regiones. Un usuario con una conexión de 15 Mbps servido por un nodo de borde de la CDN a 200 ms de distancia tendrá una experiencia mucho peor que un usuario a la misma velocidad servido por un nodo a 10 ms de distancia.
- Comprueba las puntuaciones de INP y TTFB en los distintos niveles. Si el INP empeora en los niveles de bajo ancho de banda pero no en los altos, es que los grandes paquetes de JavaScript aún se están descargando cuando los usuarios interactúan por primera vez. Divide tu JavaScript, pospón los scripts no críticos y considera hacer yielding al hilo principal durante la inicialización para reducir la exposición del INP durante la fase de análisis.
Regla General de Ingeniería
- Apunta a un tamaño de archivo de imagen LCP inferior a 100 KB (AVIF o WebP) para mantener el LCP Load Time por debajo de 200 ms incluso en conexiones de 5 Mbps.
- El peso total de la página para los recursos de la mitad superior (above-the-fold) debe mantenerse por debajo de 500 KB para dar un LCP razonable en conexiones de 10 Mbps dentro del umbral de 2,5 segundos.
- Usa
fetchpriority="high"en la imagen LCP y precárgala en el<head>del documento para que el navegador no desperdicie ancho de banda en recursos de menor prioridad primero. - Sirve todos los activos estáticos desde una CDN. Los números de ancho de banda en CoreDash miden la conexión del cliente, no la del servidor. Una conexión rápida del cliente no ayuda si el servidor está geográficamente distante y añade 300 ms de latencia antes de que llegue el primer byte.
- Si más del 15% de tu tráfico se encuentra en el nivel inferior a 10 Mbps y el LCP falla para esos usuarios, trata la optimización de imágenes y la cobertura de la CDN como problemas de máxima prioridad (P1) antes de abordar cualquier otra cosa.