Cómo usar la herramienta
- Mantén la pestaña visible y evita otra prueba de transferencia. Pulsa Iniciar para enviar 20 solicitudes HTTP pequeñas al sitio, con una pausa breve entre solicitudes.
- Espera a que termine la secuencia o pulsa Detener para cancelarla. Las solicitudes fallidas o canceladas no cuentan como lecturas de cero milisegundos.
- Consulta los tiempos individuales junto a la media y la variación. Repite en condiciones similares para comparar observaciones de este servidor.
Método de cálculo
Cada muestra incluye la solicitud HTTP y su respuesta consumida y validada. El RTT medio es la suma de los tiempos válidos dividida por su cantidad. La variación es la diferencia absoluta media entre solicitudes consecutivas correctas: suma de |siguiente − anterior| ÷ parejas válidas. Se excluyen las parejas que cruzan una solicitud fallida.
Ejemplo de cálculo
Con 40, 60 y 50 ms, el RTT medio es 50 ms. Los cambios consecutivos son 20 y 10 ms, con una variación absoluta media de 15 ms. Tres lecturas de 40 ms tienen variación cero, aunque el retraso medio sigue siendo 40 ms.
Elegir la ruta de la prueba
Los tiempos corresponden a la ruta desde este navegador hasta el servidor de este sitio. Incluyen la conexión local, el trayecto por Internet, la respuesta del servidor y el trabajo del navegador. El destino aparece durante la ejecución. No hay un selector para probar un servidor de juegos, una aplicación de reuniones o el router. Un resultado estable aquí puede coincidir con problemas en otro destino.
Anota el dispositivo, el tipo de conexión, el estado de la VPN y la hora aproximada. Mantén esos datos al comparar ejecuciones. Probar Ethernet y Wi-Fi puede ayudar a investigar la parte local, pero cambiar también el dispositivo impide atribuir la diferencia a una sola causa. La herramienta no localiza un salto defectuoso ni certifica toda la red del proveedor.
Iniciar una serie limitada de solicitudes
Abrir la página no inicia las mediciones. Lee el consentimiento, marca la casilla y pulsa Iniciar. La prueba envía veinte solicitudes HTTP pequeñas y consecutivas al servidor del mismo sitio, con una espera de 250 ms entre intentos. Cada respuesta válida contiene 32 bytes de prueba. Las cabeceras y el establecimiento de la conexión añaden tráfico; multiplicar veinte por 32 no calcula los datos facturados.
Mantén la página visible. Ocultarla detiene la ejecución. Hay un límite para cada solicitud y otro para toda la prueba, de modo que una respuesta pendiente no prolonga el proceso indefinidamente. Detener cancela la solicitud activa. Restablecer borra los resultados y el consentimiento. Una nueva ejecución sustituye las muestras anteriores; copia el registro antes de comparar otra condición.
Separar tiempos válidos y solicitudes fallidas
El mínimo y el máximo son las duraciones menor y mayor de las respuestas completadas. La media suma esas duraciones y divide por su cantidad. La mediana ordena los valores y toma el central; con una cantidad par promedia los dos centrales. Una solicitud fallida conserva su fila de error y nunca se sustituye por un tiempo de cero milisegundos.
Una diferencia grande entre media y mediana puede señalar una respuesta especialmente lenta. Revisa el orden de las muestras para identificarla. La primera solicitud permanece en el cálculo; no se descarta una fase de calentamiento. El inicio de la conexión puede influir en el resumen. Son tiempos HTTP observados por el cliente, no latencia en un solo sentido, ping ICMP ni tiempo de transmisión de radio.
Calcular los cambios entre muestras consecutivas
La variación mostrada promedia las diferencias absolutas entre muestras válidas adyacentes, conservando el orden original. Con 20, 30 y 50 ms, los cambios son 10 y 20 ms: su media es 15 ms. La duración media es aproximadamente 33,333 ms y la mediana, 30 ms. El retraso medio y su variación responden a preguntas distintas.
Ahora considera 20 ms, 30 ms, una solicitud fallida, 50 ms y 70 ms. Solo cuentan los pares de 20 a 30 y de 50 a 70; el cambio medio sigue siendo 15 ms. No se enlaza 30 con 50 saltando el error. Las cuatro respuestas válidas tienen media de 42,5 ms y mediana de 40 ms. El valor ausente permanece ausente.
La segunda fila corresponde a la secuencia con el tercer intento fallido descrita arriba. Enumera solo las duraciones válidas; los pares dependen de las posiciones originales.
| Tiempos válidos (ms) | Media (ms) | Mediana (ms) | Cambio adyacente (ms) |
|---|---|---|---|
| 20 / 30 / 50 | 33,333 | 30 | 15 |
| 20 / 30 / 50 / 70 | 42,5 | 40 | 15 |
Distinguir cero y valor no disponible
Una sola respuesta válida permite calcular mínimo, máximo, media y mediana, pero no contiene un par consecutivo. Dos respuestas separadas por un error tampoco forman un par válido. En ambos casos, una variación no disponible no significa variación cero. Dos tiempos adyacentes iguales sí dan cero: no hubo cambio observado en ese par, sin demostrar una entrega perfectamente constante de paquetes.
Cuando fallan todas las solicitudes no hay resumen de tiempos. Un tiempo agotado o un servidor no disponible no demuestra que todo Internet esté caído. También pueden intervenir la carga del servidor, restricciones de conexión o la ejecución del navegador. Copiar solicita acceso al portapapeles y muestra un error cuando no está disponible. Imprimir abre el diálogo normal; estas acciones no realizan otra medición.
Investigar picos con comparaciones controladas
Repite primero en las mismas condiciones y después cambia una sola variable. Compara el mismo dispositivo con una conexión por cable permitida y en su posición habitual con Wi-Fi. Anota descargas o subidas simultáneas mediante los controles normales de cada aplicación. Una mejora repetida orienta el siguiente paso, pero no identifica por sí sola interferencias, un canal ocupado ni un cable dañado.
Para juegos y llamadas, consulta también sus propios datos de retrasos e interrupciones. Los protocolos y destinos pueden comportarse de forma diferente. Aquí no hay fases de carga y reposo ni marcas de tiempo de paquetes multimedia. Esta diferencia HTTP no es el estimador suavizado de llegada RTP definido en RFC 3550. Los errores HTTP tampoco son un porcentaje medido de pérdida UDP; ningún umbral garantiza la calidad de una aplicación.
Guardar un registro útil
Copia las muestras junto al destino, la hora, el tipo de conexión y el síntoma concreto. Conserva la etiqueta de incompleta en una ejecución detenida o fallida. Describe patrones repetidos en lugar de elegir únicamente el mejor resultado. Una consulta de soporte no necesita contraseñas, identificadores completos de cuenta ni capturas con información personal ajena al problema.
Usa la prueba de velocidad para estudiar la transferencia de datos, una cuestión distinta. El comprobador de retrasos en juegos ayuda a separar baja tasa de fotogramas, retraso de entrada y síntomas de red. Ninguna herramienta convierte estas muestras en un diagnóstico. Una ruta HTTP tranquila es una observación útil; los problemas que continúan en la aplicación necesitan comprobaciones de su propio trayecto.
Cómo interpretar el resultado
La ejecución del navegador, la reutilización de conexiones, el servidor y la ruta afectan a los tiempos. La variación necesita al menos dos lecturas consecutivas válidas. Los errores HTTP no miden pérdida de paquetes IP. Los resultados no determinan jitter unidireccional, jitter RTP ni latencia hacia un servidor de juego o llamada. Las solicitudes llegan al sitio y exponen los metadatos habituales de conexión.
Preguntas habituales
¿Es igual que el comando ping?
No. El comando ping suele usar ICMP. Esta prueba cronometra solicitudes HTTP e incluye trabajo del navegador y del servidor.
¿Variación cero significa retraso cero?
No. Los tiempos iguales tienen cambio cero, aunque cada solicitud tarde un tiempo considerable.