Metodología · transparencia técnica

Cómo medimos de verdad tu conexión

Un test de velocidad no se cree por su cara bonita. Aquí está todo: contra qué servidores medimos y por qué, cuánto dura cada fase, cómo se calcula el número final y — sobre todo — qué no puede decirte esta medida. Esa última parte falta en casi todas partes, y es la que importa cuando tienes que decidir si reclamar al operador o cambiar el router.

En dos líneas: el test corre en tu navegador contra la infraestructura pública de Cloudflare, dura unos veinte segundos en total y devuelve un valor estable calculado por percentiles en vez de una media. No usamos servidores alojados dentro de las redes de los operadores, porque un servidor dentro de la red de tu proveedor da números más bonitos y menos ciertos.

1. Contra qué medimos, y por qué

El test consulta la infraestructura global de Cloudflare, repartida por cientos de centros de datos. Cloudflare enruta la petición al punto de presencia más cercano a tu dirección, así que mides el trayecto que recorres realmente al navegar.

• Latencia y jitter: https://speed.cloudflare.com/__down con carga vacía, para aislar el tiempo de ida y vuelta del tiempo de transferencia.
• Descarga: el mismo punto final con cargas crecientes.
• Subida: https://speed.cloudflare.com/__up mediante POST.
• Ubicación del servidor: https://speed.cloudflare.com/meta.

Elegir infraestructura neutra es la mayor diferencia frente a muchos test populares, que miden contra servidores alojados dentro de la red del propio operador. Esos servidores adornan el resultado porque el tráfico nunca sale del proveedor: es como cronometrar un coche cuesta abajo.

2. Cuánto dura el test

Unos veinte segundos en total:

• Latencia: 12 medidas consecutivas, precedidas de una petición de calentamiento que solo abre la conexión (DNS, TLS) y se descarta.
• Descarga: 8 segundos.
• Subida: 9 segundos.

Lo fijo es el tiempo, no el volumen de datos: en una línea lenta se transfiere menos, pero la medida dura lo mismo. Por eso el test funciona incluso en una conexión móvil mala, donde los test de volumen fijo suelen rendirse.

3. Ping y jitter

Hacemos 12 peticiones consecutivas con carga vacía y cronometramos cada ida y vuelta. Después:

• Ping = el valor mínimo de los 12. No la media: el mínimo es la latencia de la red cuando nada se interpone, es decir, la característica física del enlace. Las medidas más altas incluyen colas de espera, competencia en el wifi y retardos del sistema operativo, que son otra pregunta.
• Jitter = la variación media entre medidas consecutivas. Es el número que importa en videollamadas y juegos online: una línea con ping bajo pero jitter alto da más problemas que otra con ping más alto y constante.

También mostramos una media recortada, calculada descartando la mejor y la peor muestra, como indicación de la latencia típica.

4. Descarga

Durante 8 segundos descargamos cargas de tamaño creciente — 1, 5, 10, 25 y 50 MB — midiendo el rendimiento instantáneo mientras llegan los datos con performance.now(). Cada muestra es bytes recibidos × 8 dividido por el tiempo transcurrido, en Mbps.

El valor final es el percentil 90 del último 60% de las muestras. Dos decisiones, dos motivos:

• Descartamos el primer 40% porque al principio la conexión está arrancando (el llamado slow start) y la velocidad es artificialmente baja. Incluirlo sería infravalorar la línea.
• Tomamos el percentil 90 en vez de la media porque la media se hunde con un solo tropiezo momentáneo, mientras que un percentil alto describe la velocidad que la línea sostiene cuando funciona como debe.

Es una decisión declarada, no neutra: devuelve un número algo más optimista que la media aritmética de esas mismas muestras. Preferimos decirlo a esconderlo.

5. Subida

La subida es la parte difícil, sobre todo en móvil. Durante 9 segundos enviamos bloques de datos con estas precauciones:

• Bloques adaptativos: empiezan en 256 KB y se duplican mientras la red aguanta, hasta 8 MB. Si un bloque tarda demasiado, el tamaño se reduce a la mitad. Así una fibra no se mide con bloques demasiado pequeños ni una línea móvil se atasca con bloques demasiado grandes.
• Conexiones en paralelo: 3 en escritorio, 1 en móvil. En el teléfono, varias subidas en paralelo se estorban y el resultado empeora.
• Tolerancia a errores: cada envío tiene su propio límite de tiempo; si falla, se reintenta con un bloque menor. Un hueco de cobertura no tumba el test entero.

El valor final es el percentil 75 del último 60% de las muestras: más prudente que la descarga, porque la subida es por naturaleza más ruidosa. Si no logramos ni una muestra válida, la subida se declara no medida en lugar de estimarse: preferimos un dato ausente a uno inventado.

6. Los límites de esta medida

Esta es la sección que casi ningún test publica, y la más importante. Un resultado bajo no significa automáticamente que el operador te esté engañando: en la mayoría de los casos el cuello de botella está entre el router y tu dispositivo, no entre el router y el mundo.

• Wifi frente a cable. Es el factor número uno. En una línea de 1 Gbps, el wifi doméstico rara vez supera los 400-600 Mbps reales, y con un router de hace unos años se queda muy por debajo. Si quieres medir la línea, conecta el ordenador al router con un cable Ethernet. Si mides por wifi, estás midiendo el wifi.
• El dispositivo. Un portátil con tarjeta 802.11n no pasa de unos 150 Mbps reales haga lo que haga la línea. El puerto también cuenta: muchos ordenadores económicos llevan todavía puertos de 100 Mbps, que cortan el resultado justo ahí.
• El navegador. El test corre en JavaScript dentro del navegador, así que el navegador forma parte de la medida. Versiones muy antiguas, extensiones que filtran tráfico, modos de ahorro de energía y pestañas que consumen CPU bajan el resultado.
• Los demás aparatos de casa. Un televisor en 4K, una copia de seguridad en la nube o una cámara subiendo vídeo consumen ancho de banda mientras mides. La medida es correcta: sencillamente no es la capacidad total de la línea, es la que quedaba libre.
• La hora. Entre las 21 y las 23 la red de acceso va más cargada y la velocidad real puede bajar de forma apreciable. Un test de noche y otro de mañana cuentan dos cosas distintas, ambas ciertas.
• La VPN. Añade un salto intermedio: baja la velocidad y sube el ping. Desactívala antes de medir.
• Una medida es una foto. Dice cómo iba la línea en esos veinte segundos, desde ese aparato y en ese punto de la casa. No dice cómo se comporta el resto del día.

7. Cómo comparar el resultado con tu contrato

El número por el que pagas no es el número que debes esperar en pantalla. En los contratos españoles aparecen varios valores distintos y solo uno sirve para reclamar:

• Velocidad máxima — el "hasta 1 Gbps" del anuncio. Es el límite de la tecnología, no una promesa.
• Velocidad habitual disponible — la que el operador declara como típica.
• Velocidad mínima garantizada — la única sobre la que se puede construir una reclamación. Está en las condiciones del contrato, casi siempre bastante más abajo de lo que uno espera.

Para comparar con sentido: mide por cable Ethernet, con los demás dispositivos parados, repitiendo el test a distintas horas durante varios días, y apunta los resultados. Si te quedas de forma estable por debajo de la velocidad mínima garantizada, tienes un caso.

Una advertencia que te debemos: esta medida no tiene valor legal. Los operadores adheridos al Código de Buenas Prácticas para la medida de la velocidad se comprometen a informar de las velocidades reales, y si el problema no se resuelve puedes reclamar ante la Oficina de Atención al Usuario de Telecomunicaciones, tras haber reclamado antes al operador y conservado el número de referencia. RealMbps sirve para decidir si merece la pena iniciar ese camino y para descartar antes las causas domésticas.

8. Cuánta precisión tiene

Con honestidad: no hemos hecho una comparación sistemática entre RealMbps y las herramientas de los reguladores, así que no publicamos un margen de error certificado. Sería un número inventado.

Lo que sí podemos decir es cómo se comporta la medida: en condiciones controladas — cable, nada más funcionando, test repetidos — los resultados son repetibles y coherentes; la descarga es más estable que la subida, que oscila más por naturaleza; y la variación que verás entre un test y otro viene casi siempre de los factores del punto 6, no del algoritmo. Si repites el test tres veces por cable y obtienes números muy distintos, la causa está en tu red, y eso ya es información útil.

9. Cómo verificar lo que decimos

El código del test es JavaScript cargado por el navegador y no está ofuscado. Puedes leerlo:

• pulsa F12 para abrir las herramientas de desarrollo, abre la pestaña "Sources" y el archivo script.js;
• busca measureLatency(), measureDownload() y measureUpload(): son exactamente lo que describe esta página.

Si encuentras una diferencia entre esta página y el código, el error es nuestro: avísanos y lo corregimos. Las fuentes del resto de datos del sitio están en datos y fuentes.

10. En qué somos distintos

• Servidores neutros, no alojados dentro de la red de tu operador.
• Sin registro y sin guardar resultados, salvo que elijas publicar uno en la clasificación.
• Algoritmo pensado también para móvil, donde muchos test infravaloran o fallan la subida.
• Metodología declarada por completo, límites incluidos.