¿Qué es la latencia? Diferencia con el ping y cómo reducirla

Una videollamada en la que la gente acaba hablando a la vez, una página web que se queda en blanco un momento, una API que responde en 40 ms casi siempre y en 900 ms de vez en cuando. Los tres son problemas de latencia, y un plan de internet más rápido no arregla ninguno. La latencia es el tiempo de espera antes de que lleguen los datos, y se comporta de forma distinta a la velocidad de descarga que anuncia un proveedor.

A continuación: qué es la latencia, de dónde viene, en qué se diferencia del ping y del ancho de banda, cómo medirla con ping y curl (salida real de nuestro equipo de pruebas), qué valores son buenos, cómo reducirla y qué cambia un proxy.

¿Qué es la latencia?#

La latencia es el retraso entre el envío de unos datos y su llegada, o entre una petición y su respuesta. Se mide en milisegundos; 1.000 ms equivalen a un segundo. Cuando haces clic en un enlace, la petición viaja hasta un servidor y la respuesta vuelve, y cada tramo añade espera antes de que la página pueda empezar a aparecer.

La latencia en un sentido (one-way) es solo el viaje de A a B; es difícil de medir, porque los relojes de los dos equipos tendrían que coincidir al milisegundo. El tiempo de ida y vuelta (RTT, round-trip time) es el viaje de ida y de vuelta, medido con el propio reloj del emisor. El RFC 2681, la métrica de retardo de ida y vuelta del IETF, lo define como el tiempo que pasa desde que se envía un paquete de prueba hasta que la respuesta ha llegado por completo. El ping, las pruebas de velocidad y la mayoría de las herramientas informan del RTT, así que en el uso diario «latencia» significa un viaje de ida y vuelta.

¿Qué causa la latencia?#

Cinco factores se suman en la latencia que mides, y el primero fija un mínimo que ningún ajuste puede eliminar.

1. Distancia. Una señal en fibra óptica viaja a unos dos tercios de la velocidad de la luz en el vacío. La recomendación de planificación G.114 de la UIT cuenta 5 microsegundos por kilómetro de fibra: 5 ms por cada 1.000 km en un sentido y 10 ms de ida y vuelta, antes de que ningún equipo añada su parte. Los cables rara vez van en línea recta, así que las rutas reales son más largas que la distancia en el mapa. Para un enlace por satélite geoestacionario, la G.114 indica unos 260 ms en un sentido solo por el trayecto a través del espacio.
2. Saltos y enrutamiento. Entre tú y un servidor hay una cadena de routers, y cada uno es un salto (hop). La ruta decide cuánto viaja un paquete, y el tráfico entre dos ciudades cercanas puede desviarse por un punto de intercambio lejano. ¿Qué es traceroute? explica cómo listar los saltos y ver dónde crece el tiempo.
3. Colas en enlaces saturados. Un router que recibe paquetes más rápido de lo que puede reenviarlos los guarda en un búfer, una cola de espera. Cuando una copia de seguridad en la nube o una subida grande llena tu conexión, todos los demás paquetes esperan detrás. La latencia que solo sube mientras la línea está ocupada se llama bufferbloat.
4. Wi-Fi y radio móvil. El Wi-Fi es un canal de radio compartido: tus dispositivos y las redes vecinas se turnan para usarlo, y las tramas (frames) que se pierden por interferencias se vuelven a enviar. Cada espera y cada reintento añaden un retraso que cambia de un momento a otro. Los datos móviles suman su propio enlace de radio hasta la antena de telefonía.
5. Tiempo del servidor. El servidor tiene que preparar la respuesta: leer una base de datos, generar la página, llamar a otros servicios. Ese tiempo es latencia para ti, y nada de tu lado lo acorta.

Una conexión nueva a un sitio web cuesta además varios viajes de ida y vuelta antes de que se mueva ningún contenido: una consulta DNS para convertir el nombre en una dirección (salvo que esté en caché), la conexión TCP, la negociación TLS que protege HTTPS y, por último, la propia petición. Por eso, una conexión HTTPS nueva a un servidor que está a 100 ms necesita al menos tres viajes de ida y vuelta, unos 300 ms, antes de que llegue el primer byte.

Latencia frente a ancho de banda, tasa de transferencia, jitter y pérdida de paquetes#

Estos términos describen caras distintas de una misma conexión: la latencia es cuánto esperan los datos, el ancho de banda cuántos podrían fluir, la tasa de transferencia (throughput) cuántos fluyen de verdad, el jitter cuánto varía la latencia y la pérdida de paquetes cuántos no llegan nunca.

Piensa en una autopista: el ancho de banda es el número de carriles, la latencia el tiempo de viaje, y más carriles no acortan el trayecto. Un icono diminuto y un vídeo grande esperan la misma latencia para su primer byte; solo el resto de la transferencia depende del ancho de banda. Nuestra guía sobre el ancho de banda cubre el lado de la capacidad.

¿Cuál es la diferencia entre ping y latencia?#

La latencia es el retraso en sí; ping es una herramienta que mide un tipo de latencia. El comando ping envía pequeñas solicitudes de eco ICMP (ICMP es el protocolo de internet para mensajes de control y de error) y cronometra cada respuesta de eco. Las pruebas de velocidad tomaron prestado el nombre, así que «Ping 12 ms» significa una latencia de ida y vuelta de 12 ms.

El ping mide la ruta de red y poco más. Un navegador también espera al DNS, al establecimiento de la conexión, a TLS y al servidor, así que una página tarda varias veces lo que marca el ping. Algunos servidores ignoran por completo las solicitudes de eco y siguen sirviendo páginas con normalidad.

¿Cómo se mide la latencia?#

Dos comandos que vienen con Windows, macOS y Linux cubren casi todo: ping para el viaje de ida y vuelta por la red y curl para la petición completa, etapa por etapa. Ejecútalos varias veces contra el servidor que usas de verdad.

Mide el viaje de ida y vuelta con ping#

En Windows, escribe cmd en el cuadro de búsqueda de la barra de tareas, abre Símbolo del sistema y ejecuta:

ping example.com

Nuestro equipo de pruebas con Windows 11 imprimió esto el 15 de noviembre de 2026:

Pinging example.com [104.20.23.154] with 32 bytes of data:
Reply from 104.20.23.154: bytes=32 time=11ms TTL=50
Reply from 104.20.23.154: bytes=32 time=10ms TTL=50
Reply from 104.20.23.154: bytes=32 time=12ms TTL=50
Reply from 104.20.23.154: bytes=32 time=11ms TTL=50

Ping statistics for 104.20.23.154:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 10ms, Maximum = 12ms, Average = 11ms

Cada valor time= es un viaje de ida y vuelta; un Windows en español escribe tiempo=. Windows envía cuatro solicitudes por defecto; -n 20 envía 20, y -t sigue hasta que pulses Ctrl+C. Los tiempos son cortos porque example.com se sirve desde una red de distribución de contenidos, que responde desde un servidor cercano al visitante. En un Mac o en Linux, ejecuta ping -c 4 example.com en Terminal; sin -c, ping sigue hasta que pulses Control-C.

Mira en qué se va el tiempo con curl#

curl descarga una dirección web y, con la opción -w, informa de cuánto tardó cada etapa. Viene con Windows 10 y 11, macOS y la mayoría de los sistemas Linux. En el Símbolo del sistema:

curl -o NUL -s -w "dns lookup:  %{time_namelookup}\nconnect:     %{time_connect}\ntls:         %{time_appconnect}\nfirst byte:  %{time_starttransfer}\ntotal:       %{time_total}\n" https://example.com

En un Mac o en Linux, escribe -o /dev/null en lugar de -o NUL y pon el texto que sigue a -w entre comillas simples; en Windows PowerShell, escribe curl.exe, porque allí curl es el nombre de otro comando. Una de nuestras ejecuciones imprimió:

dns lookup:  0.005060
connect:     0.017101
tls:         0.036621
first byte:  0.056354
total:       0.056403

Los valores son segundos, contados cada uno desde el inicio de la petición, tal como los define el manual de curl. Resta cada línea de la siguiente para ver una sola etapa:

• Consulta DNS (dns lookup), 5 ms. Encontrar la dirección; es corta porque el nombre se acababa de consultar.
• Conexión (connect), 12 ms más. La conexión TCP, un viaje de ida y vuelta, cerca del ping.
• TLS, 20 ms más. La negociación que establece el cifrado para HTTPS.
• Primer byte (first byte), 20 ms más. La petición, el trabajo del servidor y el primer byte de vuelta.

Solo los últimos 20 de los 56 ms fueron para la petición en sí; el resto fue preparación de la conexión.

p50 y p95: por qué una sola medición no basta#

La latencia cambia de una petición a otra, así que una sola cifra dice poco. Ejecutamos la misma petición de curl 20 veces y ordenamos los tiempos de «first byte». La mediana, o p50, fue de 70 ms: la mitad de las peticiones fueron más rápidas y la otra mitad, más lentas. El p95, el valor por debajo del cual se queda el 95 % de las peticiones, fue de 91 ms, el 19.º de los 20 valores ordenados. La más lenta tardó 199 ms y subió la media hasta 76 ms.

Por eso las herramientas de supervisión y los objetivos de las API usan percentiles: el p50 muestra el caso típico, y el p95 y el p99, lo lenta que se vuelve la cola de peticiones lentas.

¿Qué es una buena latencia?#

No hay una cifra única; los pocos umbrales publicados se aplican cada uno a un uso concreto.

• Llamadas de voz y videollamadas. La ITU-T G.114 dice que, por debajo de 150 ms de retardo en un sentido, la mayoría de las aplicaciones, de voz o no, se perciben como esencialmente interactivas, y trata 400 ms en un sentido como límite superior para la planificación de redes. Ese presupuesto cubre toda la cadena del micrófono al altavoz, así que la parte de la red debe ser menor.
• Páginas web. La guía de Google sobre el tiempo hasta el primer byte (TTFB, time to first byte), el mismo momento que el «first byte» de curl, da 0,8 segundos o menos como objetivo aproximado para la mayoría de los sitios y considera deficiente más de 1,8 segundos.
• API y otros servicios. No existe un estándar general. Los equipos fijan su propio objetivo como percentil, por ejemplo «p95 por debajo de un número determinado de milisegundos», y reciben una alerta cuando no se cumple.
• Terminales de trading, escritorios remotos y aplicaciones en la nube. Cuanto más baja y estable, mejor; el jitter importa tanto como la media.

Por lo demás, interpreta un ping comparándolo con tu propio historial: si un servidor que ayer respondía en 11 ms hoy tarda 60 ms, algo ha cambiado en la ruta.

¿Cómo se reduce la latencia?#

La distancia no se puede vencer, pero sí puedes quitar el retraso que añades tú y reducir el número de viajes de ida y vuelta. Los primeros pasos no cuestan nada.

1. Usa un cable en el dispositivo que importa. Un cable Ethernet saca del camino los turnos y los reintentos del Wi-Fi; si no puedes, acércate al router.
2. Mantén la línea libre de subidas pesadas. Las copias de seguridad en la nube y las subidas grandes llenan la cola y suben la latencia de todos. Páusalas durante las llamadas o activa el ajuste de prioridad de tráfico que muchos routers llaman QoS (calidad de servicio).
3. Usa servidores cercanos a tus usuarios. Una red de distribución de contenidos guarda copias de un sitio cerca de sus visitantes, así que la mayoría de las peticiones recorren poca distancia; nuestra guía sobre CDN explica cómo.
4. Revisa tu resolutor DNS. Un resolutor lento retrasa cada nombre nuevo; si las consultas son lentas en todos los sitios, otro resolutor puede ayudar.
5. Haz menos viajes de ida y vuelta. El keep-alive de HTTP envía una petición tras otra por una misma conexión abierta, y HTTP/2, definido en el RFC 9113, lleva muchas peticiones a la vez por una sola conexión. Cuando curl descargó example.com dos veces por una misma conexión, la segunda petición se saltó DNS, TCP y TLS, y su primer byte llegó a los 21 ms en lugar de a los 71 ms.
6. Dale pruebas a tu proveedor. Si la latencia sigue alta con cable y sin nada más en marcha, envía los resultados de ping y traceroute al soporte.

¿Cómo afecta un proxy a la latencia?#

Un proxy añade una parada: tu petición va al servidor proxy, que abre la conexión con el sitio y te reenvía la respuesta. Cuánto cuesta eso depende sobre todo de dónde está la salida y de cómo usas la conexión.

• Elige una salida en el camino, no un desvío. Cada petición viaja de ti al proxy, de ahí al sitio y de vuelta. Una salida en el país o la ciudad del sitio mantiene corto el último tramo; una en un tercer continente añade dos tramos largos a cada viaje de ida y vuelta.
• Reutiliza las conexiones. Cada conexión HTTPS nueva a través de un proxy repite la preparación: la conexión con el proxy, el túnel hasta el sitio y la negociación TLS. El keep-alive y HTTP/2 pagan ese coste una sola vez, y una sesión fija mantiene la misma salida durante el tiempo que elijas, de 1 a 60 minutos.
• Cuenta con más variación en líneas domésticas y móviles. Las salidas residenciales y móviles están en conexiones reales de consumidores, así que su latencia varía más que la de las salidas en centros de datos.

Para medirlo, ejecuta el comando de curl a través del proxy con -x y compáralo con una ejecución directa:

curl -x http://user:pass@pr.proxynet.io:8000 -o NUL -s -w "connect: %{time_connect}  tls: %{time_appconnect}  first byte: %{time_starttransfer}\n" https://example.com

A través de un proxy, «connect» es la conexión con el propio proxy, «tls» incluye también la apertura del túnel del proxy hasta el sitio, y la consulta DNS baja casi a cero porque es el proxy quien resuelve el nombre; lo comprobamos con un proxy de prueba local. Las cifras reales dependen de la salida que elijas, así que compara las medianas de 20 ejecuciones.

Los Proxies residenciales te permiten elegir el país y la ciudad de salida, así que puedes colocar la salida cerca del sitio con el que trabajas.

Para tiempos estables desde direcciones fijas, como comprobar una API desde un mismo lugar cada pocos minutos, los Proxies de centro de datos mantienen sus salidas en redes de servidores.

Dónde importa la latencia#

• Páginas web y tiendas online: cada conexión nueva y cada archivo que bloquea la carga añaden viajes de ida y vuelta antes de que aparezca la página.
• Videollamadas y llamadas por internet: el retraso hace que la gente hable a la vez; el jitter entrecorta el audio.
• API: un clic puede iniciar una cadena de llamadas, y sus latencias se suman.
• Terminales de trading: el tiempo que pasa entre un cambio de precio y la llegada de la orden al mercado.
• Escritorios remotos y aplicaciones en la nube: cada pulsación de tecla hace un viaje de ida y vuelta.
• Web scraping y supervisión: miles de peticiones multiplican cada viaje de ida y vuelta.

Errores frecuentes#

• Contratar un plan más rápido para arreglar el retraso. Más Mbps rara vez cambian la latencia; la causa suele ser el Wi-Fi, una línea ocupada o la distancia.
• Juzgar por un solo ping. Ejecuta 20 o más y compara la mediana con los valores más lentos.
• Medir contra el servidor equivocado. Una prueba de velocidad elige un servidor cercano a ti; el sitio que usas puede estar lejos.
• Tomar un ping sin respuesta por una caída. Algunos servidores ignoran las solicitudes de eco y siguen sirviendo páginas.

Guía de decisión#

Preguntas frecuentes#

¿Qué es una buena latencia de internet?#

Depende del uso. Para llamadas, la ITU-T G.114 dice que la mayoría de las aplicaciones se perciben como esencialmente interactivas por debajo de 150 ms en un sentido, de extremo a extremo, así que un ping muy por debajo de esa cifra deja margen para los dispositivos. Para páginas web, Google propone un tiempo hasta el primer byte de 0,8 segundos o menos. Sobre todo, compara con tus propios valores de referencia.

¿Qué significa baja latencia?#

Baja latencia significa que los datos llegan con poca espera, así que las respuestas parecen inmediatas. Lo que cuenta como bajo depende de la tarea y de la distancia, y una conexión merece ese nombre solo cuando el retraso es corto y estable.

¿Más ancho de banda reduce la latencia?#

Normalmente no. El ancho de banda decide cuántos datos caben por segundo; la latencia viene de la distancia, el enrutamiento, las colas y el servidor. La excepción es una línea que suele estar llena: ahí, la capacidad extra acorta las colas.

¿Qué son la latencia en reposo, de descarga y de subida en una prueba de velocidad?#

La latencia en reposo (idle) se mide antes de la prueba, mientras la línea está tranquila. La latencia de descarga y la de subida se miden mientras la prueba llena la línea en cada sentido. Una gran diferencia entre el valor en reposo y los valores con carga apunta a bufferbloat.

¿Por qué tengo más latencia por Wi-Fi que con cable?#

El Wi-Fi es un canal de radio compartido: los dispositivos se turnan y reenvían las tramas perdidas por interferencias, lo que añade retraso y lo hace variar. La distancia, las paredes y las redes vecinas saturadas lo empeoran; un cable elimina esa parte del camino.

¿Un proxy o una VPN aumentan la latencia?#

Normalmente un poco, porque el tráfico hace una parada extra. El aumento es pequeño cuando la salida está cerca del destino y crece con un desvío; ejecuta el mismo comando de curl con y sin el proxy o la VPN para ver la diferencia.

En resumen#

La latencia es el tiempo que esperan los datos por el camino, normalmente expresado como un viaje de ida y vuelta en milisegundos. La causan la distancia, el enrutamiento, las colas, el Wi-Fi y el servidor, y el ancho de banda no la cura. Mídela con ping y curl -w, fíjate en la mediana y el p95 en lugar de en un solo valor, y redúcela con un cable, servidores cercanos y menos viajes de ida y vuelta. Cuando tus peticiones tengan que salir desde un país o una ciudad concretos, compara las opciones de salida en nuestra página de productos proxy.