La latencia suele aparecer tarde en las conversaciones sobre infraestructura. Primero se habla de precio, capacidad, región cloud, escalabilidad, seguridad o servicios gestionados. Después, cuando la aplicación ya está en producción, llegan las métricas: páginas que tardan más en responder, carritos abandonados, APIs que acumulan esperas, sesiones móviles que no convierten y usuarios que perciben el servicio como lento aunque el servidor «funcione bien».
En mercados como Argentina, esta discusión tiene una lectura muy concreta. No es lo mismo servir una aplicación desde infraestructura local que hacerlo desde São Paulo, Miami, Virginia, Madrid o Frankfurt. La diferencia puede parecer pequeña cuando se expresa en milisegundos, pero se multiplica en cada petición, en cada negociación TCP/TLS, en cada llamada a una API y en cada recurso dinámico que no puede resolverse con una simple caché.
El RTT no es un detalle: es la distancia convertida en experiencia
Cuando se habla de latencia de red suele usarse el RTT, o round-trip time, que mide el tiempo que tarda un paquete en ir desde un punto a otro y volver. Es una métrica sencilla, pero muy útil para entender por qué la ubicación física de la infraestructura sigue importando. La fibra óptica no elimina la geografía. La reduce, la encamina y la optimiza, pero cada salto, cada ruta internacional y cada punto de intercambio añade tiempo.
En una aplicación web moderna, una diferencia de 100 milisegundos no afecta solo a una petición aislada. Puede aparecer en la resolución DNS, el establecimiento de conexión, la negociación TLS, la carga inicial del HTML, las llamadas a backend, los recursos bloqueantes, los endpoints de pago, el login o la comunicación entre microservicios si parte del sistema está distribuido entre regiones.
La siguiente tabla usa Buenos Aires como punto de referencia y recoge valores orientativos de RTT publicados por mediciones públicas entre ciudades. No deben leerse como una garantía de rendimiento, porque cada operador, ruta, proveedor de tránsito y hora del día puede cambiar el resultado. Sirven para visualizar el orden de magnitud.
| Ubicación de la infraestructura | RTT aproximado desde Buenos Aires | Diferencia frente a local | Lectura técnica |
|---|---|---|---|
| Argentina local | ~2-5 ms | Referencia | Adecuado para cargas sensibles a latencia y usuarios nacionales |
| Santiago de Chile | ~21-25 ms | +20 ms aprox. | Buena opción regional si la conectividad acompaña |
| São Paulo | ~30-35 ms | +30 ms aprox. | Región cloud cercana para muchos despliegues en Sudamérica |
| Miami | ~110-135 ms | +110-130 ms | Enlace habitual con EE. UU., pero lejos para experiencia local |
| Nueva York / Virginia | ~140-150 ms | +140-150 ms | Región frecuente por defecto en muchas arquitecturas cloud |
| Londres | ~220-225 ms | +220 ms aprox. | Potente para Europa, poco eficiente para usuarios argentinos |
| Madrid | ~230-235 ms | +230 ms aprox. | Buena ubicación para España, no para baja latencia en Argentina |
| Frankfurt | ~235-245 ms | +235-240 ms | Región europea madura, pero muy distante para tráfico argentino |
Madrid es un buen ejemplo para evitar una confusión habitual. Como región europea, puede ser una ubicación excelente para servir usuarios en España, Portugal, sur de Europa o ciertos escenarios de interconexión transatlántica. Pero si el cliente final está en Buenos Aires, Córdoba, Rosario o Mendoza, Madrid no es «cerca». Cada interacción atraviesa el Atlántico, y eso se nota en el RTT.
El coste técnico de colocar el servidor lejos
El impacto económico de la latencia se ha citado muchas veces con dos referencias conocidas. Greg Linden, antiguo ingeniero de Amazon, explicó que en pruebas internas se introducían retrasos de 100 milisegundos y que incluso pequeñas demoras provocaban caídas relevantes de ingresos. La frase se ha resumido durante años como «100 ms adicionales pueden costar un 1 % de ventas». Conviene tratarla como una referencia histórica, no como una fórmula universal.
La otra referencia procede del estudio «Milliseconds Make Millions», elaborado por Deloitte para Google. El informe observó que una mejora de 0,1 segundos en varias métricas de velocidad móvil se asoció con un aumento del 8,4 % en conversiones retail y del 10,1 % en travel. De nuevo, no significa que cualquier web vaya a replicar esos números, pero confirma algo que los equipos de rendimiento llevan años viendo: cuando la experiencia mejora en móvil, la conversión suele responder.
Aplicado a un comercio electrónico con 1 millón de dólares anuales de facturación digital, el cálculo simplificado basado en la referencia de Amazon quedaría así:
| Ubicación | Latencia adicional aproximada frente a local | Impacto anual estimado sobre 1 M$* |
|---|---|---|
| Argentina local | 0 ms | Referencia |
| Santiago de Chile | +20 ms | ~2.000 $ |
| São Paulo | +30 ms | ~3.000 $ |
| Miami | +130 ms | ~13.000 $ |
| Nueva York / Virginia | +145 ms | ~14.500 $ |
| Londres | +220 ms | ~22.000 $ |
| Madrid | +230 ms | ~23.000 $ |
| Frankfurt | +240 ms | ~24.000 $ |
*Estimación orientativa usando la regla histórica de 100 ms adicionales ≈ 1 % menos de ventas. No sustituye a una prueba real con métricas propias.
La cifra exacta puede variar mucho. No es lo mismo una tienda con tráfico móvil masivo que un portal corporativo, una API financiera, un SaaS B2B o una plataforma de gaming. Pero el principio se mantiene: cuanto más interactiva y transaccional es una aplicación, más caro resulta alejar el backend del usuario.
Local, edge, CDN y cloud regional no resuelven el mismo problema
Una CDN puede mejorar de forma clara la entrega de contenido estático: imágenes, CSS, JavaScript, vídeo, fuentes o descargas. También puede reducir carga sobre el origen y mejorar tiempos de respuesta en recursos cacheables. Pero no todo se puede cachear. Un login, una consulta de stock, una operación de pago, una actualización de carrito, una recomendación personalizada o una llamada a una base de datos necesitan llegar al backend.
Ahí es donde la ubicación de la infraestructura vuelve al centro. Un diseño con frontend cacheado en edge, pero backend dinámico en Virginia, puede ofrecer una primera carga aceptable y, aun así, penalizar cada acción relevante del usuario. En móvil la situación se agrava por la variabilidad de la red, la pérdida de paquetes, el cambio de celda y la menor estabilidad de algunas conexiones.
| Capa | Qué mejora | Qué no resuelve por sí sola |
|---|---|---|
| CDN | Recursos estáticos, caché, descargas, vídeo, imágenes | Operaciones dinámicas no cacheables |
| Edge functions | Lógica ligera cerca del usuario | Bases de datos complejas o estado transaccional distante |
| Región cloud cercana | Menor RTT que regiones lejanas | Dependencia de servicios disponibles en esa región |
| Infraestructura local | Baja latencia para usuarios nacionales | Requiere buen diseño de conectividad, operación y resiliencia |
| Multi-región | Resiliencia y cercanía por mercado | Más complejidad de datos, consistencia y coste |
En Argentina la situación tiene además una particularidad: los grandes hiperescalares no muestran una región pública completa en el país en sus mapas oficiales de regiones. AWS sí lista una Local Zone en Buenos Aires, asociada a la región principal US East (N. Virginia), lo que permite acercar ciertos recursos a usuarios finales, pero una Local Zone no equivale a una región completa con todo el catálogo de servicios. Azure, Google Cloud y Oracle publican sus mapas globales de regiones, donde la cobertura en Latinoamérica se organiza alrededor de otros países y ubicaciones.
Por eso la decisión no debería formularse como «cloud pública o infraestructura local», sino como una arquitectura híbrida y realista. Hay cargas que encajan bien en regiones cloud globales: analítica, backup, disaster recovery, servicios gestionados, inteligencia artificial, entornos de desarrollo o aplicaciones con usuarios distribuidos. Otras cargas, sobre todo las más sensibles a la latencia y con usuarios concentrados en un país, pueden beneficiarse claramente de una ubicación local.
Cómo medir antes de mover una carga
La latencia no debería estimarse solo desde una tabla. Antes de migrar, conviene medir desde los puntos donde están los usuarios reales. Para un ecommerce argentino, eso implica probar desde Buenos Aires, Córdoba, Rosario, Mendoza, Tucumán y otras zonas relevantes. Para un SaaS B2B, también importa desde qué redes corporativas se conectan los clientes. Para una API financiera, hay que medir entre la aplicación, los PSP, bancos, antifraude y proveedores externos.
Una prueba útil debería incluir, al menos, RTT, jitter, pérdida de paquetes, TTFB, tiempos p95 y p99, handshake TLS, tiempos de consulta a base de datos y rendimiento desde dispositivos móviles. La media puede engañar. Una aplicación puede tener una latencia media aceptable y sufrir colas en el percentil 99 que arruinan la experiencia en momentos críticos.
También es importante separar latencia de procesamiento y latencia de red. Un servidor lento en Argentina puede rendir peor que un backend muy optimizado en São Paulo. Pero cuando ambos entornos están bien diseñados, la geografía pesa. Ningún ajuste de CPU compensa por completo un RTT de 230 ms si el usuario está en Buenos Aires y el backend principal está en Madrid.
La conclusión técnica es sencilla: la latencia no aparece como una línea visible en la factura del proveedor, pero aparece en las métricas. Está en la conversión, en el abandono, en el TTFB, en las APIs que tardan, en los procesos de pago y en la percepción de calidad. Para muchas empresas, elegir dónde corre una aplicación puede ser tan importante como elegir sobre qué plataforma corre.
Preguntas frecuentes
¿Qué es la latencia de red?
Es el tiempo que tarda un dato en viajar entre el usuario y el servidor. Normalmente se mide como RTT, el tiempo de ida y vuelta de un paquete.
¿Por qué importa tanto en ecommerce?
Porque cada retraso puede afectar a la carga de páginas, búsquedas, carrito, login y pago. En móvil, pequeños retrasos suelen notarse más por la variabilidad de la red.
¿Una CDN elimina el problema de la latencia?
No del todo. Ayuda mucho con contenido estático y recursos cacheables, pero las operaciones dinámicas siguen dependiendo de dónde estén el backend, la base de datos y las APIs.
¿Madrid es una buena ubicación para servir usuarios en Argentina?
Madrid puede ser una ubicación excelente para España y Europa, pero desde Argentina implica un RTT aproximado de más de 230 ms. Para aplicaciones sensibles a latencia, una ubicación local o regional cercana suele ser más adecuada.
