Dimensión de CoreDash: Velocidad de red

Dimensión: Velocidad de red (dl)

La dimensión dl informa el 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 grupo 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 lado a lado.

El ancho de banda es una de las dos características de red que determinan 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 disminuye la velocidad de conexión, y en qué medida?

Por qué importa la velocidad de red para los 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 hero, una imagen de fondo grande o una fuente web pesada. En una conexión de 100 Mbps, una imagen hero de 400 KB llega en aproximadamente 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 contabilizar cualquier latencia o sobrecarga de procesamiento. Esa diferencia por sí sola puede empujar una puntuación LCP aprobada 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 del CDN en lugar de un problema de ancho de banda del lado del cliente.

El Interaction to Next Paint está casi completamente 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 impulsan malas puntuaciones de INP. 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 que se cargan 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 después de que fue descubierto. CoreDash reporta el LCP Load Time por separado, lo que facilita confirmar si los usuarios con conexiones lentas están esperando a la red o a otra cosa.

Lectura de los datos

El tráfico de CoreDash en los sitios típicos se divide en tres niveles de ancho de banda. Comprender lo que representa cada nivel te ayuda a priorizar las soluciones.

Banda ancha rápida: 50 Mbps y superior

Aproximadamente el 35% del tráfico de CoreDash cae 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 rondan los 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 en el LCP impulsados 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: 10 a 50 Mbps

Aproximadamente el 40% del tráfico de CoreDash aterriza en este rango. Este nivel cubre conexiones de cable más antiguas, 4G LTE en condiciones de señal promedio (las velocidades típicas de 4G en el mundo real se sitúan entre 10 y 50 Mbps) y algunos usuarios de red inalámbrica fija. Una imagen hero de 300 KB toma entre 48 y 240 milisegundos de tiempo de transferencia a estas velocidades. Las páginas con imágenes no optimizadas o múltiples recursos que bloquean el renderizado comenzarán a fallar 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 los 10 Mbps. Esto incluye usuarios 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 en tiempo de transferencia. Los fallos de LCP en este nivel son casi seguros a menos que la imagen LCP haya sido comprimida agresivamente, servida a través de un nodo edge de un CDN cercano al usuario y precargada correctamente. Si tu negocio sirve a usuarios en regiones con infraestructura históricamente más lenta, verifica la dimensión de País de CoreDash junto con dl para confirmar si el tráfico de baja velocidad se concentra geográficamente.

Flujo de trabajo de depuración

1. Filtra hasta el nivel inferior a 10 Mbps en CoreDash y verifica el LCP Load Time. Si el LCP Load Time es el contribuyente dominante a una puntuación deficiente de LCP, el recurso LCP es demasiado grande para las conexiones lentas. Comprime aún más la imagen, cambia al formato AVIF y confirma que el recurso se sirve desde un CDN con un nodo edge cercano a los usuarios afectados.
2. 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 edge de 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.
3. Verifica las puntuaciones de INP y TTFB en todos los niveles. Si el INP empeora en los niveles de ancho de banda bajo pero no en los altos, los paquetes grandes de JavaScript aún se están descargando cuando los usuarios interactúan por primera vez. Divide tu JavaScript, aplaza 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 por debajo de 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 brindar 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 primero en recursos de menor prioridad.
• Sirve todos los activos estáticos desde un CDN. Los números de ancho de banda en CoreDash miden la conexión del cliente, no la del servidor. Una conexión de cliente rápida no ayuda si el servidor está distante geográficamente 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 del CDN como problemas de prioridad 1 (P1) antes de abordar cualquier otra cosa.