Latencia desde Perú a un servidor en Europa: medir antes de optimizar
"Se siente lento" es de los reportes más difíciles de atender, porque invita a optimizar lo primero que uno sospecha: la consulta, el índice, el framework. Antes de tocar código conviene responder una pregunta más simple: ¿dónde se va el tiempo? En mis sistemas, alojados en un servidor en Europa y usados desde Perú, la respuesta sorprendió.
Los tres tramos de una respuesta
Una petición lenta tiene al menos tres tramos que se miden por separado:
- Del usuario al servidor: DNS, conexión TCP, negociación TLS y el viaje de ida y vuelta.
- Del servidor a servicios externos: APIs de terceros que el backend llama para responder.
- Del servidor a su base de datos: el tiempo real de procesamiento.
curl permite medir el primer tramo con precisión usando su
opción de formato de salida, que desglosa cada fase de la conexión. Los
otros dos se miden desde el propio servidor.
Lo que mostró la medición
Desde Perú, cada petición pagaba alrededor de 250 ms de ida y vuelta, y hasta 660 ms en frío, cuando además hay que negociar TLS. Desde el servidor, la API externa que se consultaba respondía en unos 120 ms, y la base de datos en 5 ms. El backend casi nunca era el problema: la distancia se llevaba la mayor parte del tiempo.
Si no mides los tramos, vas a optimizar consultas de 5 ms mientras el océano se lleva 250.
Lo que se arregla sin mover nada: UI optimista
La latencia de red no se puede eliminar desde el código, pero sí se puede dejar de hacerla esperar. En una bandeja de mensajes, al enviar, la interfaz pinta el mensaje al instante como pendiente y reconcilia cuando el servidor responde. Si falla, retira lo provisional y le devuelve al usuario el texto que había escrito, para que no lo pierda.
La UI optimista introduce una complicación: ahora hay dos fuentes de verdad. Si la pantalla consulta al servidor cada pocos segundos y reemplaza la lista entera con la respuesta, puede borrar el mensaje optimista que todavía no llegó. Hay que preservar los pendientes al refrescar y deduplicar por identificador cuando el servidor confirma.
Otras mejoras de bajo costo
- Conexiones reutilizadas: el costo en frío de TLS se paga una vez; mantener la conexión viva evita repetirlo.
- Menos idas y vueltas: un endpoint que devuelve lo que la pantalla necesita en una sola respuesta vale más que tres llamadas encadenadas.
- Endpoints livianos para sondeo: preguntar "¿hay algo nuevo?" con una respuesta mínima, en vez de traer la lista completa cada vez.
- Estáticos con caché larga: el HTML, CSS y JavaScript no deberían viajar en cada visita.
Cuándo sí hay que mover el servidor
La solución estructural es acercar el servidor a los usuarios. Un servidor en São Paulo o Miami baja esos 250 ms a un rango de 30 a 80. No siempre es urgente: mientras el uso sea moderado y la interfaz no haga esperar, un hosting lejano y económico es razonable. Se vuelve prioridad cuando hay personas atendiendo clientes en tiempo real y cada acción acumula ese retraso decenas de veces por hora.
La regla práctica queda así: medir los tres tramos, optimizar el que domina, esconder la latencia con UI optimista mientras tanto, y mover la infraestructura cuando el uso real lo justifique.