Test de Ping y Pérdida de Paquetes

Cómo funciona

1. Cierra otras descargas y transmisiones. Otro dispositivo o aplicación que consuma ancho de banda durante el test inflará el número de latencia bajo carga por motivos que no tienen nada que ver con el comportamiento real de tu conexión.
2. Prefiere Ethernet, o siéntate cerca del router. El Wi-Fi añade su propia latencia y jitter encima de lo que haga tu línea de internet — un cable aísla la medición a la línea en sí.
3. Pulsa Iniciar y deja la pestaña en primer plano. Los navegadores ralentizan las pestañas en segundo plano, lo que corrompería en silencio la medición de la que depende este test.
4. Observa primero la latencia en reposo, luego bajo carga. La primera fase mide tu conexión en reposo; la segunda inicia una descarga junto con las mismas sondas de latencia para ver cuánto se ralentiza mientras está ocupada.
5. Lee los contadores de estabilidad, no un porcentaje de pérdida. No existe uno — mira más abajo por qué — pero el número de sondas que nunca recibieron respuesta, y cuántas volvieron inusualmente lentas, te dice casi lo mismo.
6. Repítelo en horas punta. La latencia y el bufferbloat son más sensibles a la hora del día que la velocidad bruta — un resultado de noche puede verse muy distinto de uno de tarde.

Qué mide realmente este test (y por qué "ping" es un término algo impreciso aquí)

El comando `ping` envía un paquete ICMP en bruto y cronometra la respuesta. Una página web no puede hacer eso — los navegadores no tienen acceso a ICMP ni a sockets en bruto de ningún tipo, por las mismas razones de aislamiento (sandboxing) por las que una página web no puede leer tus archivos sin pedir permiso. Así que este test hace lo más honesto posible: cronometra una solicitud HTTPS normal a la red de Cloudflare y resta el tiempo de procesamiento que el propio servidor reporta, dejando solo el trayecto de ida y vuelta por la red.

• Es un trayecto de ida y vuelta real y medido — no una simulación ni una estimación, solo mediante HTTPS en lugar de ICMP.
• Suele leer unos pocos milisegundos más que un ping de terminal al mismo destino, porque un intercambio HTTP cifrado con TLS cuesta algo más que un simple eco ICMP, incluso tras restar el tiempo de procesamiento del servidor.
• Mide el trayecto hasta una ubicación de borde de Cloudflare, no hasta un servidor de juego, proveedor de llamadas o sitio web específico — trátalo como un indicador de "qué tan buena es mi conexión, en general", no como la cifra exacta que obtendrías hacia un destino concreto.

Por qué no hay un porcentaje de pérdida de paquetes en esta página

Vale la pena explicarlo claramente en lugar de simplemente omitir el número, porque su ausencia es una decisión deliberada, no una función que falta.

• TCP — el protocolo que hay debajo de cualquier solicitud web normal — retransmite los datos perdidos de forma automática e invisible. Un paquete perdido no falla; simplemente llega tarde, tras un reintento.
• Eso significa que una página web que cronometra solicitudes HTTP literalmente no puede ver un paquete perdido como pérdida — ve una respuesta lenta, indistinguible a simple vista de una congestión normal.
• Una herramienta que calculara "0% de pérdida de paquetes" a partir de esos datos no estaría reportando una tasa baja de pérdida — estaría reportando que no pudo detectar pérdida alguna, algo muy distinto para alguien que intenta diagnosticar una conexión inestable.
• Medir la pérdida de paquetes real requiere un protocolo que no oculte la pérdida — ICMP o UDP en bruto — que es precisamente lo que un navegador no tiene permitido enviar.

Lo que este test reporta en su lugar: cuántas sondas de latencia no recibieron ninguna respuesta dentro de un plazo generoso, y cuántas volvieron mucho más lentas que la sonda típica en tu conexión — una señal de que probablemente hubo una retransmisión, aunque no se pueda contar directamente. Ninguno de los dos números es pérdida. Ambos son la evidencia más cercana que un navegador puede reunir realmente.

Latencia, jitter y el peor caso: qué significa cada número

El test reporta tres números relacionados pero distintos de su fase de latencia en reposo.

• Latencia (ms): el tiempo típico de ida y vuelta — técnicamente la mediana de todas las sondas, que resiste ser distorsionada por un solo valor atípico lento, a diferencia de una media.
• Jitter (ms): cuánto varía ese tiempo de ida y vuelta de una sonda a otra, no lo alto que sea en promedio. Una conexión puede tener una latencia media decente y aun así sentirse entrecortada en una llamada si el jitter es alto.
• Peor caso (ms): el trayecto de ida y vuelta en el percentil 95 — cercano al número que realmente notarías en una llamada o partida, ya que un solo momento muy lento destaca mucho más que el típico.

Bufferbloat: por qué tu conexión se vuelve lenta justo cuando empieza una descarga

Este es el número que la mayoría de los tests de velocidad omiten por completo, y a menudo es la explicación real de "mi conexión va bien hasta que alguien más empieza a descargar algo".

• La mayoría de routers y módems ponen en cola los datos de salida en un búfer antes de enviarlos — una idea razonable que sale mal cuando ese búfer está sobredimensionado para la conexión.
• Cuando una descarga o subida grande llena ese búfer, cualquier otro paquete — incluidas las sondas de latencia de este test, y cualquier paquete de una llamada o partida — tiene que esperar en la cola detrás de él.
• El resultado: una latencia que va bien cuando la conexión está inactiva puede saltar de 20ms a 300ms o más en el instante en que algo satura la línea, y volver a bajar cuando termina.
• Este test mide exactamente eso: ejecuta una descarga saturante en segundo plano mientras sigue enviando sondas de latencia, y luego compara la latencia antes y durante.

Las notas van de A+ a F, según cuánto aumente la latencia bajo carga — A+ es un incremento de apenas unos milisegundos, F son cientos de milisegundos, el tipo de pico que hace que una llamada se corte justo cuando el móvil empieza una copia de seguridad en la nube en la misma conexión.

Cómo se ven los buenos números, por actividad

No hay un único número "bueno" — lo que importa depende por completo de lo que estés haciendo en la conexión.

• Llamadas de voz: cómodas por debajo de unos 200ms de ida y vuelta con jitter bajo; la mayoría de códecs VoIP tienen suficiente búfer como para suavizar más que el vídeo.
• Videollamadas: latencia por debajo de 150ms y jitter por debajo de 30ms se siente sólido; una nota de bufferbloat C o peor suele ser la causa real de una llamada que se corta cada vez que alguien más está en línea.
• Gaming online: por debajo de 50ms con jitter ajustado es excelente para cualquier cosa competitiva; 50-100ms está bien para la mayoría de partidas casuales.
• Cloud gaming: el caso más estricto — por debajo de 40ms con jitter muy bajo, porque todo el fotograma de vídeo hace el trayecto de ida y vuelta, no solo una entrada.
• Navegación, streaming, descargas: aquí la latencia apenas importa — consulta el test de velocidad de internet para las cifras que realmente rigen esto.

Por eso este test muestra directamente un veredicto para cada una de estas actividades, en lugar de dejarte interpretar tres números en bruto por tu cuenta.

Wi-Fi, VPNs y otras cosas que inflan el resultado

Antes de asumir que un mal resultado significa una mala línea de internet, descarta lo que más probablemente esté añadiendo latencia por su cuenta.

• Wi-Fi: añade su propia latencia y, especialmente en una banda de 2,4GHz congestionada o en un edificio con docenas de redes solapadas, su propio jitter — a menudo más de lo que aporta la propia línea de internet.
• Una VPN: enruta cada paquete a través de un servidor adicional, con frecuencia uno lejano, añadiendo distancia real de ida y vuelta encima del coste de cifrado.
• Un router sobrecargado: un router antiguo o con poca potencia puede añadir latencia de procesamiento bajo carga, independientemente de tu conexión real a internet — esto se ve idéntico al bufferbloat desde fuera.
• Apps en segundo plano: la sincronización en la nube, las actualizaciones automáticas y otros dispositivos en la misma red pueden estar saturando silenciosamente la conexión durante lo que creías que era un test en reposo.

La forma más rápida de aislar la causa: ejecuta el test por cable con todo lo demás pausado, y luego otra vez por Wi-Fi con tu carga de fondo normal — la diferencia entre ambos te dice dónde está realmente el problema.

Cuándo el resultado sí apunta a un problema

La mayoría de los resultados irregulares tienen una de las explicaciones anteriores. Un conjunto más pequeño de patrones sí merece plantearse a tu proveedor.

• Una nota de bufferbloat D o F en una conexión por cable, confirmada en más de una ejecución — esto suele poder arreglarse por parte del ISP con gestión moderna de colas (comercializada como SQM o fq_codel) si la admiten.
• Latencia en reposo muy por encima de 100ms hacia una ubicación cercana de Cloudflare en una conexión por cable, de forma constante a distintas horas del día — eso apunta a un problema de enrutamiento o congestión aguas arriba, no a nada en tu casa.
• Un número alto de sondas sin respuesta en una conexión por cable sin VPN activa — vale la pena reproducirlo y reportarlo con una captura de pantalla, ya que puede indicar un problema real en la red del proveedor.
• Números que van bien a las 3 de la madrugada pero que son malos de forma constante cada noche — congestión de red local, un patrón concreto que merece la pena plantear directamente a tu ISP.

Preguntas frecuentes