Ping, jitter y 0 ms: cómo leer el test de latencia
Interpreta la latencia y el jitter del navegador, entiende los 0 ms y las conexiones reutilizadas, y por qué HTTP/3 usa QUIC en lugar de TCP. Tests gratis.
Interpreta juntos la mediana, el rango y el jitter
La herramienta de latencia registra ocho tiempos de respuesta HTTP consecutivos después de una solicitud de calentamiento. La mediana es el valor central de las mediciones ordenadas; el rango muestra la más baja y la más alta. Aquí, el jitter es la variación media absoluta entre muestras consecutivas, no una medición a nivel de paquetes.
Ejemplo con ocho muestras: 20, 30, 10, 40, 20, 30, 10, 40 ms. Al ordenarlas, la pareja central es 20 y 30, por lo que la mediana es 25 ms. Los siete cambios consecutivos suman 140 ms; al dividirlos entre siete, la variación es 20 ms. El rango es de 10 a 40 ms. Son datos ilustrativos del cálculo, no mediciones de la conexión de un visitante.
Qué significa 0 ms o un tiempo ausente
Las muestras de tiempo de respuesta y el desglose del establecimiento de conexión son mediciones independientes. Una conexión reutilizada puede transportar una nueva solicitud sin otra consulta DNS ni otra negociación (handshake).
| Texto mostrado | Significado | Siguiente paso |
|---|---|---|
| En caché o conexión reutilizada | No se midió una nueva fase de DNS para esta solicitud | No lo interpretes como la velocidad de consulta del resolver DNS |
| Sin nuevo establecimiento (conexión reutilizada) | La entrada de Resource Timing no contiene un nuevo intervalo de establecimiento de conexión | Compara los tiempos de respuesta de las solicitudes en lugar de tomar el establecimiento como latencia de ida y vuelta |
| TCP no usado (HTTP/3 · QUIC) | Esta solicitud usó HTTP/3, cuyo transporte es QUIC | Consulta el RTT de QUIC si el servidor perimetral lo informó |
| No informado | El tiempo necesario faltaba o no se podía usar | Considéralo desconocido; no es un cero medido |
| 0 ms informado (precisión no disponible) | El servidor perimetral devolvió cero sin precisión suficiente para interpretarlo más | No deduzcas de este campo que no hay retardo físico ni que la conexión se reutilizó |
Compara de forma justa Wi-Fi, datos móviles o un VPN
Usa el mismo dispositivo y el mismo navegador para hacer una comparación sencilla. El resultado es una observación para diagnosticar problemas, no una medición calibrada de toda tu conexión a internet.
- Pausa las descargas, el streaming y cualquier otro tráfico intenso; luego ejecuta la herramienta de latencia y anota la mediana, el rango y la variación.
- Cambia solo la red o la configuración del VPN que quieres comparar, espera a que se estabilice y repite la prueba.
- Registra varias ejecuciones y la hora de cada prueba. Si cambia el servidor perimetral o la ruta observados, interpreta el resultado como una comparación de las rutas completas.
- Usa el test TLS para ver el protocolo HTTP y el RTT que informa el servidor perimetral. Esos metadatos pertenecen a su propia solicitud de inspección, así que no tienen por qué coincidir con una muestra de latencia.
Lleva un registro de comparaciones que explique un cambio
En cada ejecución, anota la hora, el nombre de la red, la configuración del VPN, la mediana, el rango y la variación. Si quieres comparar un VPN, no cambies el Wi-Fi ni el dispositivo. Si quieres comparar el Wi-Fi con los datos móviles, no cambies la configuración del VPN. Una mediana más alta después de cambiar dos cosas a la vez no revela cuál de los cambios la causó.
Compara el ejemplo con ocho muestras de exactamente 25 ms: ambas medianas son 25 ms, pero la secuencia constante tiene un rango de 25–25 ms y una variación consecutiva de 0 ms. Medianas iguales pueden ocultar diferencias de estabilidad. Estos ejemplos sintéticos aíslan el cálculo; la planificación real del navegador añade ruido. Repite las ejecuciones inesperadas y anota las etiquetas de establecimiento de conexión. No sumes el RTT del edge al tiempo total de la solicitud del navegador: los valores pueden solaparse y proceder de solicitudes distintas.
Por qué el ping del navegador difiere del ping del juego
Una solicitud HTTP incluye el trabajo del navegador y del servidor, además del tiempo de red. Un juego se comunica con otro servidor y puede usar otro protocolo. Un resultado de un servidor de Cloudflare cercano no permite predecir la latencia hacia un servidor de juegos concreto, y esta herramienta no mide el ping ICMP, la pérdida de paquetes ni la velocidad de descarga.
Si tu objetivo es alojar un juego, usa la página IP para juegos para preparar una dirección y revisar las pistas de la WAN del router. Si tienes lag mientras juegas, revisa también las estadísticas de red del propio juego y repite las pruebas cuando ocurra el problema. Las pistas de CGNAT y la latencia alta son observaciones distintas; una no demuestra la otra.
Preguntas frecuentes
¿Por qué el RTT de TCP aparece como “no usado” con HTTP/3?
HTTP/3 usa QUIC en lugar de TCP. El campo TCP no se aplica a esa solicitud. IPNixa muestra el RTT de QUIC por separado cuando el servidor perimetral lo informa.
¿0 ms significa que mi conexión no tiene retardo?
No. En una conexión reutilizada puede omitirse una fase de establecimiento, o un servidor puede indicar un cero sin precisión suficiente para interpretarlo. Esos casos se etiquetan por separado de los valores ausentes.
¿La latencia del navegador es lo mismo que un ping ICMP?
No. Estas muestras miden el tiempo de pequeñas solicitudes HTTP a IPNixa, incluido el procesamiento del navegador y del servidor de destino. ICMP, los juegos y otros destinos usan mediciones distintas.
¿Esta prueba detecta pérdida de paquetes o bufferbloat?
No. Ocho solicitudes HTTP pequeñas no miden la pérdida de paquetes ni la latencia bajo una carga controlada de subida o de descarga. Usa una herramienta diseñada para esas mediciones.