La latencia suele ser un tema que se discute tarde en las conversaciones sobre infraestructura. Al principio se enfocan en precio, capacidad, región en la nube, escalabilidad, seguridad o servicios gestionados. Solo cuando la aplicación ya está en producción, llegan las métricas: páginas que responden lentamente, carritos abandonados, APIs con 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 connotación muy concreta. No es lo mismo desplegar una aplicación desde infraestructura local que hacerlo desde São Paulo, Miami, Virginia, Madrid o Frankfurt. La diferencia puede parecer pequeña 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 solo con caché.
El RTT no es un detalle: es la distancia convertida en experiencia
Cuando hablamos de latencia de red, generalmente usamos el RTT, o round-trip time, que mide cuánto tarda un paquete en ir de un punto a otro y regresar. Es una métrica sencilla, pero muy útil para entender por qué la ubicación física de la infraestructura sigue siendo importante. 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ñaden tiempo.
En una aplicación web moderna, una diferencia de 100 milisegundos no afecta solo a una petición aislada. Puede influir en la resolución DNS, en el establecimiento de conexión, en la negociación TLS, en la carga inicial del HTML, en las llamadas al backend, en recursos bloqueantes, en endpoints de pago, en el login, o en la comunicación entre microservicios si el sistema está distribuido entre regiones.
La siguiente tabla usa Buenos Aires como referencia y muestra valores orientativos de RTT basados en mediciones públicas entre distintas ciudades. No se deben leer como garantías de rendimiento, ya que cada operador, ruta, proveedor de tránsito y hora del día pueden variar los resultados. Sirven para tener una idea del orden de magnitud.
| Ubicación de infraestructura | RTT aproximado desde Buenos Aires | Diferencia respecto a local | Lectura técnica |
|---|---|---|---|
| Argentina (local) | ~2-5 ms | Referencia | Apto 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 despliegues en Sudamérica |
| Miami | ~110-135 ms | +110-130 ms | Ruta habitual hacia EE. UU., menos eficiente para experiencia local |
| Nueva York / Virginia | ~140-150 ms | +140-150 ms | Región frecuente en arquitecturas cloud |
| Londres | ~220-225 ms | +220 ms aprox. | Óptimo para Europa, menos para usuarios argentinos |
| Madrid | ~230-235 ms | +230 ms aprox. | Buena para España y Europa, menos para baja latencia en Argentina |
| Frankfurt | ~235-245 ms | +235-240 ms | Región europea consolidada, pero muy distante para tráfico argentino |
Madrid es un ejemplo para evitar confusiones habituales. Como región europea, puede ser excelente para atender usuarios en España, Portugal y Europa sur, o en 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 refleja en el RTT.
El coste técnico de colocar el servidor lejos
El impacto económico de la latencia ha sido mencionado muchas veces con referencias conocidas. Greg Linden, ex ingeniero de Amazon, explicó que en pruebas internas introducían retrasos de 100 milisegundos, y que incluso esas pequeñas demoras provocaban caídas significativas en ingresos. La frase se ha popularizado como «100 ms adicionales pueden costar un 1 % de ventas», pero conviene entenderlo como una referencia histórica, no como una fórmula universal.
Otra referencia proviene del estudio «Milliseconds Make Millions» elaborado por Deloitte para Google. El informe detectó que una mejora de 0,1 segundos en métricas de velocidad móvil se asoció con un aumento del 8,4 % en conversiones minoristas y del 10,1 % en viajes. Esto no significa que todas las webs puedan replicar esos números, pero confirma algo que los equipos de rendimiento conocen desde hace tiempo: cuando la experiencia mejora en móvil, las tasas de conversión también responden.
Aplicando esto a un comercio electrónico con 1 millón de dólares anuales en ventas digitales, una estimación simple basada en Amazon sería la siguiente:
| Ubicación | Latencia adicional aproximada respecto 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 |
*Esta es una estimación orientativa basada en la regla histórica de 100 ms adicionales equivalentes a aproximadamente un 1 % menos en ventas. No reemplaza una prueba con métricas propias.
La cifra exacta puede variar mucho dependiendo del tipo de negocio: tiendas con mucho tráfico móvil, portales corporativos, APIs financieras, SaaS B2B o plataformas de gaming. Sin embargo, el principio se mantiene: cuanto más interactiva y transaccional sea una aplicación, mayor será el costo de alejar el backend del usuario.
Diferencias entre local, edge, CDN y regiones en la nube
Una CDN puede mejorar notablemente la entrega de contenido estático: imágenes, CSS, JavaScript, vídeos, fuentes o archivos descargables. También puede reducir la carga en el origen y mejorar los tiempos de respuesta en recursos cacheables. Pero no todo se puede cachear. Operaciones como login, consulta de stock, pagos, actualizaciones de carrito, recomendaciones personalizadas o llamadas a bases de datos necesitan llegar al backend.
Aquí es donde la ubicación de la infraestructura cobra protagonismo. Un diseño con frontend en el edge cacheado, pero backend dinámico en Virginia, puede ofrecer una carga inicial aceptable, pero penalizar cada interacción importante del usuario. En móvil, la situación se agrava por la variabilidad de la red, pérdida de paquetes, cambio de celda y menor estabilidad en algunas conexiones.
| Capa | Qué mejora | Qué no resuelve por sí sola |
|---|---|---|
| CDN | Recursos estáticos, caché, descargas, vídeos, imágenes | Operaciones dinámicas no cacheables |
| Funciones en el edge | Lógica ligera cerca del usuario | Bases de datos complejas o estado transaccional distante |
| Región en la nube cercana | Menor RTT que regiones lejanas | Dependencia de los servicios disponibles en esa región |
| Infraestructura local | Baja latencia para usuarios nacionales | Requiere buena conectividad, operación y resiliencia |
| Multi-región | Resiliencia y cercanía por mercado | Mayor complejidad en datos, consistencia y costo |
En Argentina, además, los grandes hiperescalares no muestran una región pública completa en el país en sus mapas oficiales. AWS, por ejemplo, lista una Local Zone en Buenos Aires vinculada a la región principal de EE. UU. Este (Virginia), lo cual permite acercar ciertos recursos, pero una Local Zone no equivale a una región completa con todo su catálogo de servicios. Azure, Google Cloud y Oracle publican mapas globales que muestran regiones en otros países y lugares en Latinoamérica, con mayor cobertura regional.
Por ello, la decisión no debería plantearse como «cloud pública o infraestructura local», sino como una arquitectura híbrida y adaptada a la realidad. Algunas cargas, como análisis, backups, recuperación ante desastres, servicios gestionados, IA, entornos de desarrollo o aplicaciones distribuidas, encajan bien en regiones en la nube global. En cambio, cargas 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
No hay que estimar la latencia solo con tablas o promedios. Antes de migrar, es recomendable 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 localidades relevantes. Para un SaaS B2B, también importa saber desde qué redes corporativas se conectan los clientes. Para APIs financieras, hay que medir entre la aplicación, los PSP, bancos, entidades antifraude y proveedores externos.
Una prueba efectiva debe incluir al menos RTT, jitter, pérdida de paquetes, TTFB, tiempos en p95 y p99, handshake TLS, tiempos de consulta a base de datos y rendimiento en dispositivos móviles. La media puede ser engañosa; una aplicación puede tener buena latencia promedio, pero sufrir picos en p99 que arruinan la experiencia en momentos críticos.
También es fundamental diferenciar entre latencia de red y procesamientos del servidor. Un backend en Argentina puede rendir peor que uno optimizado en São Paulo si la latencia de red es muy alta. Pero cuando ambos ambientes están bien diseñados, la geografía influye significativamente. Ningún ajuste de CPU compensa completamente un RTT de 230 ms si el usuario está en Buenos Aires y el backend en Madrid.
En definitiva, la latencia no se ve en la factura, pero sí en las métricas que impactan en la conversión, abandono, TTFB, APIs lentas, procesos de pago y percepción de calidad. Para muchas empresas, decidir dónde correr la aplicación es tan importante como elegir la plataforma misma.
Preguntas frecuentes
¿Qué es la latencia de red?
Es el tiempo que tarda un dato en viajar del usuario al servidor y viceversa, generalmente medido como RTT, el tiempo de ida y vuelta de un paquete.
¿Por qué es tan relevante en ecommerce?
Porque cada retraso afecta a la carga de páginas, búsquedas, carrito, login y pago. En móvil, estos pequeños retrasos se notan más por la variabilidad de la red.
¿Una CDN soluciona el problema de la latencia?
No completamente. Facilita mucho la entrega de contenido estático y recursos cacheables, pero las operaciones dinámicas —como login, pagos o consultas a bases de datos— siguen dependiendo de la ubicación del backend.
¿Madrid sirve para usuarios en Argentina?
Madrid es excelente para Europa, pero desde Argentina su RTT supera los 230 ms, siendo menos recomendable para aplicaciones sensibles a la latencia. En esos casos, una ubicación local o regional cercana es preferible.