Test de ping y latencia

Qué mide esta página exactamente (y qué no)

Casi todos los test de ping de internet enseñan un número y se callan de dónde sale. Este empieza por ahí, porque el número no se entiende sin saber qué se ha medido.

El ping de verdad —el del comando ping del sistema— usa un protocolo llamado ICMP, que vive en un nivel de la red al que un navegador no tiene acceso: por seguridad, ninguna página web puede mandar un paquete ICMP. Así que lo que hace esta herramienta, y lo que hacen todos los test de ping web sin excepción, es otra cosa: pedir un archivo diminuto por HTTP y cronometrar lo que tarda en empezar a llegar. En nuestro caso, un archivo llamado eco.txt que pesa cuatro bytes y está en esta misma carpeta.

Ese número es perfectamente válido para lo que la gente quiere saber —si la conexión va fina o va pastosa—, pero es algo mayor que el del ping del sistema, porque incluye el rato que el servidor tarda en localizar el archivo y empezar a mandarlo. Si comparas los dos y no coinciden, no es que uno mienta: es que miden trayectos ligeramente distintos, y además a destinos distintos.

Las cuatro decisiones que hacen que el número valga algo

Medir latencia desde un navegador es fácil de hacer mal. Estas son las trampas y cómo se esquivan aquí:

• No vale un cronómetro alrededor del fetch. Restar dos marcas de tiempo antes y después mete dentro el trabajo del propio JavaScript, y el resultado sale inflado. Aquí el número sale de PerformanceResourceTiming, la contabilidad interna del navegador, y en concreto de responseStart − requestStart: desde que la petición sale hasta que asoma el primer byte de la respuesta.
• La caché arruina la medición. Si el navegador contesta con su propia copia guardada, salen 0 ms y parece que la conexión es de fibra óptica cuántica. Por eso cada petición lleva un parámetro único en la dirección y además va marcada como no-store.
• Las primeras no cuentan. Aquí hay un matiz que casi nadie cuenta bien: abrir la conexión —resolver el DNS, el saludo TCP, negociar el cifrado— ocurre antes del tramo que se cronometra, así que no ensucia la cifra. Aun así se descartan tres, porque la primera petición de una conexión recién abierta sigue siendo más lenta por su cuenta: TCP arranca despacio a propósito y el servidor tiene que despabilarse. Y el coste de abrir la conexión se enseña aparte, porque es un dato interesante por sí mismo: es lo que de verdad tardas en llegar a un servidor la primera vez.
• La mediana, nunca la media. Es la más importante de las cuatro y tiene su propio apartado aquí abajo.

Por qué la mediana y no la media

Imagina ocho muestras: 12, 14, 13, 60, 12, 11, 13 y 12 milisegundos. Siete de ellas están entre 11 y 14; una se fue a 60 porque el wifi tosió, o porque el recolector de basura del navegador se paró a limpiar medio milisegundo de más.

La media de esas ocho es 18,4 ms. Es un número que no describe ningún instante real de tu conexión: ni el de las siete veces que fue a 12, ni el de la vez que fue a 60. Es el promedio de una cosa habitual y un accidente, y no sirve para nada. La mediana —el valor de en medio al ordenarlas— es 12,5 ms, que es exactamente lo que notas casi todo el rato.

Por eso la cifra grande de esta página es la mediana, y por eso el máximo va justo al lado en letra pequeña: el pico no se esconde, se enseña donde corresponde, sin dejar que contamine la cifra principal. Y la gráfica lo enseña mejor todavía, porque ahí se ve si el pico fue uno solo o si van cayendo cada dos segundos.

El jitter: el número que nadie mira y el que más se nota

El jitter es cuánto varía la latencia de una medición a la siguiente. En esta página se calcula como la media de la diferencia absoluta entre muestras consecutivas —es decir, el tamaño típico del salto entre una petición y la siguiente—. Conviene decirlo porque hay páginas que llaman jitter a la desviación típica, que mide otra cosa: la dispersión respecto a la media, sin importar el orden en que llegaron las muestras.

Importa porque las aplicaciones de voz y vídeo funcionan con un búfer de unas pocas decenas de milisegundos: guardan un poquito de audio para reordenar los paquetes que llegan desordenados y entregarlos seguidos. Si el retardo salta más que ese margen, el búfer se queda vacío y la voz se entrecorta. De ahí una conclusión que sorprende a mucha gente: una conexión con 60 ms clavados se oye mejor que una que va saltando entre 20 y 90 ms, aunque la segunda tenga mejor media.

Las referencias que usa esta página: por debajo de 5 ms el jitter es bajo; entre 5 y 20 ms es aceptable y no vas a notar nada; entre 20 y 30 ms está en el límite y en una llamada larga es probable que algo se corte; por encima de 30 ms los cortes son esperables. El wifi es, con diferencia, la causa más común de un jitter alto.

Por qué esta herramienta no mide megas

Es la pregunta obvia y la respuesta es honesta: para medir megas hay que mover megas. Un test de velocidad de verdad descarga decenas de megabytes contra cada visitante, y eso significa un servidor sirviendo archivos grandes a todo el que entre. Calculoteca funciona sin servidor de cálculo —todo lo demás se resuelve dentro de tu navegador— y el ancho de banda de un test de velocidad cuesta bastante más de lo que paga la publicidad de una página como esta.

La latencia, en cambio, se mide bien con peticiones de cuatro bytes. Así que se hace lo que se puede hacer bien y se dice claramente lo que no se hace, en vez de montar un medidor de megas malo que dé cifras inventadas. Si lo que necesitas son los megas contratados, el test de tu operador o el del regulador es lo que buscas.

Por qué aquí no verás «pérdida de paquetes»

Porque desde un navegador no se puede medir, y sin embargo la enseñan muchos test. Las peticiones web viajan sobre TCP, un protocolo que detecta los paquetes perdidos y los pide otra vez por debajo, sin que el navegador llegue a enterarse de que se perdió nada. Lo único que se nota desde arriba es que esa petición tardó un poco más. Un test web que dice «pérdida de paquetes: 2 %» está enseñando otra cosa con una etiqueta que no le corresponde.

Lo que sí se puede contar, y es lo que cuenta esta página, son las peticiones fallidas: las que dieron error o agotaron el tiempo de espera de dos segundos. Con una conexión sana deberían ser cero. Que aparezcan una o dos indica que algo se está cortando de verdad, y eso sí es información útil. Pero se llaman por su nombre.

Cómo bajar la latencia, por orden de lo que más se nota

• Cable en vez de wifi. Es lo que más cambia, y no tanto por la latencia media como por el jitter: un cable de red quita de golpe casi toda la variación. Si juegas o teletrabajas desde una habitación fija, es la mejor inversión de veinte euros que existe.
• Si no hay cable, acércate y usa los 5 GHz. La banda de 5 GHz tiene menos alcance pero muchísimo menos ruido de vecinos que la de 2,4. Una pared menos entre tú y el router también se nota.
• Para lo que esté descargando. Copias de seguridad en la nube, actualizaciones del sistema, torrents o alguien viendo vídeo en 4K en otra habitación: todo eso llena la cola de subida del router y dispara la latencia de todo lo demás. Muchos routers tienen una opción de QoS o «gaming» que precisamente sirve para esto.
• Reinicia el router si lleva meses encendido. Poco glamuroso, ocasionalmente eficaz.
• Cambiar de tecnología es lo único que mueve el suelo. De ADSL a fibra hay una diferencia estructural que ningún ajuste compensa. Del satélite ni hablamos: la señal tiene que subir 36.000 km y bajar, y eso son 500 ms que no los arregla nadie.

Y una advertencia final sobre el número: es la latencia contra nuestro servidor. El servidor de tu juego, el de tu videollamada o el de tu oficina pueden estar mucho más cerca o mucho más lejos, y el número contra ellos será distinto. Lo que esta herramienta mide bien es el estado de tu conexión, que es la parte del camino que depende de ti.