Publicamos el método entero porque un número sin método no vale nada. Si algo no se puede medir bien desde un navegador, lo decimos en lugar de rellenar el hueco.

Qué mide exactamente esta prueba

Se mide el rendimiento del camino completo entre tu navegador y nuestro servidor: tu dispositivo, tu Wi-Fi o tu cable, el router, la red de tu proveedor y la ruta de Internet hasta nosotros. No se mide «la velocidad de tu plan» en abstracto, sino lo que de verdad llega hoy, en este dispositivo y en este momento.

Ping

Se hacen varias peticiones HTTP muy pequeñas a un endpoint que responde sin cuerpo (código 204). Se cronometra el tiempo de ida y vuelta de cada una.

Las primeras respuestas se descartan: incluyen resolución DNS, apertura de la conexión TCP y negociación TLS.
Las peticiones son secuenciales, nunca en paralelo: dos peticiones simultáneas compiten entre sí y falsean el número.
Cada URL lleva un parámetro único y las cabeceras exigen Cache-Control: no-store, para que ninguna caché intermedia responda por el servidor.
Se reportan promedio, mínimo y máximo.

Límite honesto: esto no es un ping ICMP como el de una terminal. Es latencia HTTP, y suele salir unos milisegundos por encima. A cambio, es la latencia que realmente notas al usar la web, que es de lo que se trata.

Jitter

El jitter es la variación entre mediciones consecutivas de latencia. Lo calculamos como la media de las diferencias absolutas entre medidas seguidas:

jitter = ( Σ |tᵢ − tᵢ₋₁| ) ÷ (n − 1)

Una conexión puede tener buen ping medio y aun así cortarse en llamadas si el jitter es alto, porque los paquetes llegan a un ritmo irregular.

Descarga

El navegador abre varias conexiones simultáneas contra nuestro endpoint de descarga, que devuelve bloques de bytes aleatorios. Los bytes se cuentan según van llegando, no al terminar cada bloque.

Sin caché: todas las respuestas van con Cache-Control: no-store y URL única.
Sin compresión: los datos son aleatorios y el endpoint declara Content-Encoding: identity. Comprimir datos de prueba inflaría el resultado varias veces.
Varias conexiones: una sola conexión TCP rara vez satura un enlace moderno. Con 2–6 flujos se alcanza el techo real.
Descarte de arranque: los primeros ~750 ms no cuentan. Durante el slow start de TCP la velocidad sube desde casi cero y meterlo en la media la hunde.
Duración fija: la fase dura unos segundos y se corta con AbortController; se miden los bytes realmente recibidos en ese tiempo.

Subida

El navegador genera datos aleatorios en memoria y los envía por POST. No se sube ningún archivo tuyo ni ningún dato personal, y el servidor los descarta sin guardarlos.

Hay una trampa clásica aquí: el evento de progreso de subida avisa cuando el sistema operativo acepta los bytes, no cuando llegan al servidor. Calcular con eso infla el resultado, porque parte de los datos siguen en el búfer de salida. Por eso el número final sólo usa bloques cuya respuesta HTTP ya volvió del servidor. La barra de progreso usa el evento (más fluido); el resultado usa las confirmaciones (más honesto).

La fórmula

Mbps = bytes × 8 ÷ segundos ÷ 1 000 000

Megabits por segundo, no megabytes. Un byte son 8 bits, así que una conexión de 100 Mbps descarga como mucho unos 12,5 MB por segundo. Los proveedores anuncian en Mbps y los navegadores muestran las descargas en MB/s: de ahí viene casi toda la confusión.

Pérdida de paquetes: por qué decimos «No disponible»

Un navegador no tiene acceso a ICMP ni a sockets crudos. No puede enviar paquetes y comprobar cuáles se perdieron, porque TCP retransmite por debajo y esconde esa información. Cualquier «porcentaje de pérdida» calculado desde una página web es una estimación indirecta y poco fiable.

Preferimos mostrar «No disponible» antes que un número que suena técnico y no significa nada. Para medir pérdida de paquetes de verdad hace falta una herramienta de sistema (ping, mtr) o una aplicación nativa.

Qué puede alterar tu resultado

Wi-Fi: distancia al router, paredes, interferencia de vecinos, banda de 2,4 GHz saturada.
El dispositivo: un equipo antiguo o con la CPU al límite no procesa el tráfico lo bastante rápido.
Aplicaciones abiertas: actualizaciones, copias de seguridad, streaming o descargas en segundo plano.
Otros dispositivos de la casa usando la misma conexión durante la prueba.
VPN o proxy: añaden latencia y suelen recortar la velocidad.
Congestión: a las horas pico la red del proveedor va más cargada.
Distancia al servidor de prueba: cuanto más lejos, mayor latencia y menor rendimiento máximo.

Qué guardamos

Si el resultado se guarda para generar un enlace compartible, se almacenan las métricas, el proveedor detectado, la ciudad aproximada y datos técnicos del navegador. La dirección IP nunca se guarda completa: se recorta (por defecto /24 en IPv4 y /48 en IPv6) y aparte se guarda un hash irreversible con sal que sólo sirve para frenar abusos. En la página pública de un resultado no se muestra IP alguna ni ubicación exacta.

El detalle completo está en la política de privacidad.

Por qué no coincide con otros medidores

Cada servicio usa sus propios servidores, su número de conexiones, su duración y su forma de descartar el arranque. Diferencias del 10–20 % entre medidores son normales. Lo útil no es el número absoluto de un único test, sino repetir la medición en el mismo sitio y comparar con tu propio historial.

Cómo medimos