Definición
La latencia es el tiempo que transcurre entre pedir algo y empezar a recibirlo.
La confusión habitual es con el ancho de banda, y la analogía de la tubería lo aclara: el ancho de banda es lo gruesa que es; la latencia es lo larga que es. Una tubería muy gruesa y muy larga mueve mucha agua, y la primera gota tarda igual.
Por eso una conexión de fibra muy rápida no hace que una web lejana cargue rápido: mover los datos es veloz, y cada ida y vuelta sigue costando lo que cuesta.
De ahí la regla que gobierna casi todo el rendimiento de red: lo caro no es el tamaño, es el número de viajes. Ver consulta N+1, que es exactamente ese problema dentro de la base de datos.
Dónde se acumula
Una petición web suma latencias de varias fuentes:
- Resolución del nombre. Traducir el dominio a una dirección. Ver DNS.
- Establecer la conexión, incluido el saludo cifrado de HTTPS.
- Distancia física. Insalvable: la información no viaja más rápido que la luz. Madrid–Nueva York son decenas de milisegundos, siempre.
- Trabajo del servidor. Consultas, cálculos, llamadas a terceros. Ver TTFB.
- Vuelta y pintado en el navegador.
Cada recurso adicional que la página necesite y que abra una conexión nueva vuelve a pagar buena parte de esa cuenta.
Ejemplo práctico
Un dato de rendimiento sin percentiles es un dato incompleto.
Lo que aprendí mirando tiempos de respuesta reales: la media miente. Si el 90 % de las peticiones responden en 100 milisegundos y el 10 % tardan 3 segundos, la media sale en unos 390 milisegundos y suena aceptable. Y hay un 10 % de usuarios teniendo una experiencia mala — que además suelen ser los que más datos manejan, es decir, tus mejores clientes.
Por eso lo que hay que mirar es el percentil 95: el tiempo por debajo del cual quedan el 95 % de las peticiones. Ese número describe la experiencia del peor tramo, que es el que genera las quejas.
El segundo aprendizaje, sobre cómo se reduce de verdad: no se reduce haciendo cada viaje más rápido, se reduce haciendo menos viajes. Las cuatro palancas, por orden de eficacia:
Agrupar peticiones. Una que trae cien cosas en lugar de cien que traen una.
Caché. El viaje más rápido es el que no se hace.
Acercar los datos. Un CDN reduce la distancia física, que es la única parte que no se puede optimizar de otra forma.
No esperar cuando no hace falta. Si tres llamadas son independientes, lánzalas a la vez en lugar de una tras otra. Ver concurrencia.
Y una advertencia sobre medir desde donde no toca: probar la velocidad desde la misma red que el servidor, o desde una máquina de desarrollo, da números que no existen para nadie. Hay que medir desde donde están los usuarios, con su tipo de conexión y su distancia. Es la razón de que tantas webs vayan «perfectas» en la oficina y regular en casa de un cliente.
Errores comunes
- Confundir latencia con ancho de banda.
- Fijarse solo en la media.
- Muchas peticiones pequeñas en vez de agrupar.
- Encadenar llamadas independientes que podían ir en paralelo.
- Medir desde la propia red.
- Ignorar la distancia física y culpar al código.
- No medir nada y optimizar por intuición.
Cuándo revisarlo
Al integrar cualquier servicio externo, al diseñar una API y siempre que alguien diga que «va lento» — porque esa frase casi nunca señala dónde.
La comprobación que ordena el diagnóstico: cuenta cuántas idas y vueltas hace tu operación. Si son más de las necesarias, ahí está la mejora, y suele ser mucho mayor que cualquier ajuste de servidor.
