Por qué tres tests de velocidad dan tres cifras distintas

Tres respuestas, todas defendibles

Ejecuta un test en tres sitios distintos en el mismo minuto y es posible que veas 300 Mbps, 180 Mbps y 90 Mbps. Resulta tentador suponer que dos de ellos están mal. En la práctica, cada uno responde a una pregunta ligeramente distinta, y la dispersión entre ellos aporta más información que cualquier cifra aislada.

Uno mide cuánta capacidad puede transportar la línea cuando se satura deliberadamente. Otro mide la rapidez con la que viajará una descarga real. Otro puede estar midiendo una ruta que nunca sale de la propia red de tu proveedor. Son tres magnitudes legítimas con tres usos legítimos.

Las conexiones paralelas cambian el techo

Una única conexión TCP necesita tiempo para alcanzar la capacidad plena de la línea. Abre ocho o dieciséis a la vez y cada una escala en paralelo, así que el agregado llega al techo mucho antes; en un test corto, esa diferencia es grande. Los tests multihilo suelen reportar cifras más altas y son la herramienta adecuada cuando la pregunta es “¿obtuve la capacidad por la que pagué?”.

Los tests de un solo hilo reportan cifras más bajas y son la herramienta adecuada cuando la pregunta es “¿a qué velocidad irá realmente esta descarga?”. Un stream de vídeo, la descarga de un juego, un archivo de un CDN y una videollamada son, en la práctica, flujos únicos. La diferencia entre ambos métodos no es un error de medición: es la diferencia entre una cifra de capacidad y una cifra de entrega.

La latencia amplifica el efecto. Cuanto mayor es el tiempo de ida y vuelta, más tarda una sola conexión en escalar, de modo que los enlaces de latencia alta —satélite, algunos accesos inalámbricos fijos, rutas internacionales largas— muestran la mayor distancia entre resultados de un hilo y multihilo.

La ubicación del servidor decide qué ruta mediste

Cada herramienta utiliza una red de servidores distinta. Algunas eligen el punto de destino disponible más cercano, otras recurren a una red de entrega de contenidos ligada a un servicio concreto y otras emplean servidores alojados dentro de la propia red de un proveedor de internet. Cada elección mide una ruta diferente.

Un test hacia un servidor dentro de la red de tu proveedor nunca atraviesa una interconexión, por lo que puede reportar legítimamente la mejor cifra que jamás verás, y no dice nada sobre cómo llega el tráfico a los servicios situados fuera de esa red. Un test contra el CDN de un proveedor de contenidos te indica cómo se comportará ese proveedor, no cómo se comportará internet en general. Comparar dos herramientas que usan puntos de destino distintos es comparar rutas tanto como conexiones.

La mayor fuente de error suele ser local

Las diferencias de metodología acaparan la atención, pero en el día a día los errores mayores provienen del entorno:

• Wi-Fi en lugar de Ethernet. La conexión inalámbrica añade latencia, jitter y variabilidad que crecen con la distancia, las paredes y la cantidad de dispositivos que comparten la banda. Con un plan rápido, un test por cable y un test inalámbrico en la misma habitación pueden diferir de forma considerable.
• Tráfico en segundo plano. Una sincronización en la nube, una actualización del sistema, un parche de un juego o el stream 4K de otra persona consumen capacidad durante la ventana del test.
• Extensiones del navegador y VPN. Ambas se sitúan en la ruta y pueden limitar o redirigir el tráfico del test.
• Hora del día. En conexiones de medio compartido, el mismo test ejecutado a las 10:00 y a las 21:00 mide dos redes diferentes.

Leer una cifra con contexto

Un test de velocidad mide una ruta, hacia un servidor, en un momento dado y con un método de transferencia concreto. No demuestra que todos los sitios carguen rápido, que un servidor de juegos responda con agilidad, que la red doméstica esté bien configurada ni que la capacidad se mantenga en hora punta. Trata un resultado como una instantánea de diagnóstico y considera el método parte del resultado: una cifra sin sus condiciones no es una medición.

También conviene separar dos conceptos: el throughput y la capacidad de respuesta son independientes. Una línea de capacidad muy alta con 200 ms de latencia hasta el CDN más cercano se siente peor para el trabajo interactivo que una línea modesta con 10 ms. Si la queja es “se siente lento”, la cifra en Mbps suele ser el dato menos útil de la pantalla.

Una rutina de medición repetible

Estandarizar las condiciones importa más que la herramienta que elijas.

1. Conecta por Ethernet siempre que sea posible. Si debes usar Wi-Fi, permanece en la misma habitación que el punto de acceso y utiliza la banda de 5 GHz o de 6 GHz.
2. Cierra todo lo que mueva datos —copias de seguridad, clientes de sincronización, actualizaciones, streams— tanto en el dispositivo del test como en cualquier otro equipo que comparta la conexión.
3. Realiza el test con un perfil de navegador limpio, sin extensiones y sin VPN.
4. Ejecuta tres tests y toma el resultado intermedio en lugar del mejor.
5. Anota la hora del día y repite en la hora de mayor uso en la que normalmente utilices la red. La diferencia entre ambos es la cifra que predice tu experiencia real.
6. Si dos servicios no coinciden, prueba ambos contra el mismo servidor cercano antes de concluir que la línea es la culpable.

Haz esto una vez a media mañana y otra por la noche, y tendrás una imagen más precisa de tu conexión que cualquier número destacado aislado.