Latency often appears late in infrastructure discussions. First, the focus is on price, capacity, cloud region, scalability, security, or managed services. Only after the application is in production do metrics arrive: pages taking longer to respond, abandoned carts, waiting APIs, unconverted mobile sessions, and users perceiving the service as slow even though the server “works fine.”
In markets like Argentina, this discussion has a very concrete interpretation. Hosting an application from local infrastructure is not the same as doing so from São Paulo, Miami, Virginia, Madrid, or Frankfurt. The difference may seem small when expressed in milliseconds, but it multiplies with each request, each TCP/TLS negotiation, API call, or dynamic resource that can’t be cached simply.
RTT is not a detail: it’s the distance turned into experience
When talking about network latency, RTT, or round-trip time, is usually used. It measures how long it takes for a packet to go from one point to another and back. It’s a simple metric but very useful to understand why physical infrastructure location still matters. Fiber optics don’t eliminate geography. They reduce, route, and optimize it, but each hop, international route, and exchange point adds time.
In a modern web application, a 100-millisecond difference doesn’t just affect a single request. It can involve DNS resolution, connection establishment, TLS handshake, initial HTML load, backend calls, blocking resources, payment endpoints, login, or microservice communication if the system is distributed across regions.
The following table uses Buenos Aires as a reference point and summarizes approximate RTT values published by public measurements between cities. These figures should not be read as performance guarantees, since each operator, route, transit provider, and time of day can change the result. They serve to visualize the order of magnitude.
| Infrastructure Location | Approximate RTT from Buenos Aires | Difference from local | Technical note |
|---|---|---|---|
| Argentina local | ~2-5 ms | Reference | Adequate for latency-sensitive loads and national users |
| Santiago de Chile | ~21-25 ms | +20 ms approx. | Good regional option if connectivity is sufficient |
| São Paulo | ~30-35 ms | +30 ms approx. | Nearby cloud region for many South American deployments |
| Miami | ~110-135 ms | +110-130 ms | Common link to US, but far for local experience |
| New York / Virginia | ~140-150 ms | +140-150 ms | Frequent default region in many cloud architectures |
| London | ~220-225 ms | +220 ms approx. | Strong for Europe, less efficient for Argentine users |
| Madrid | ~230-235 ms | +230 ms approx. | Good for Spain, not ideal for low latency in Argentina |
| Frankfurt | ~235-245 ms | +235-240 ms | Mature European region, but very distant for Argentine traffic |
Madrid is a good example to avoid a common misconception. As a European region, it can be an excellent location to serve users in Spain, Portugal, Southern Europe, or certain transatlantic interconnection scenarios. But if the end user is in Buenos Aires, Córdoba, Rosario, or Mendoza, Madrid is “not close.” Every interaction crosses the Atlantic, and this is reflected in RTT.
The technical cost of placing the server far away
The economic impact of latency has been often cited with two well-known references. Greg Linden, a former Amazon engineer, explained that internal tests introduced delays of 100 milliseconds, and even small delays caused significant revenue drops. The phrase has been summarized over the years as “an extra 100 ms can cost 1% of sales.” It’s useful to see this as a historical reference, not a universal formula.
The second reference comes from the study “Milliseconds Make Millions,” conducted by Deloitte for Google. The report observed that a 0.1-second improvement in various mobile speed metrics was associated with an 8.4% increase in retail conversions and 10.1% in travel. Again, this doesn’t guarantee that any web will replicate those numbers, but it confirms what performance teams have been seeing: when mobile experience improves, conversion tends to follow.
Applied to an e-commerce business with $1 million annual digital revenue, the simplified calculation based on Amazon’s reference would be:
| Location | Approximate additional latency compared to local | Estimated annual impact on $1M* |
|---|---|---|
| Argentina local | 0 ms | Reference |
| Santiago de Chile | +20 ms | ~$2,000 |
| São Paulo | +30 ms | ~$3,000 |
| Miami | +130 ms | ~$13,000 |
| New York / Virginia | +145 ms | ~$14,500 |
| London | +220 ms | ~$22,000 |
| Madrid | +230 ms | ~$23,000 |
| Frankfurt | +240 ms | ~$24,000 |
*Estimate based on the historical rule: 100 ms additional ≈ 1% less sales. Does not replace actual measurements with your own metrics.
The exact figure can vary greatly. It’s different for a site with massive mobile traffic than for a corporate portal, a financial API, a B2B SaaS, or a gaming platform. But the principle remains: the more interactive and transactional an application is, the more expensive it becomes to keep the backend close to the user.
Different problems: local, edge, CDN, and regional cloud do not solve the same issues
A CDN can clearly improve static content delivery: images, CSS, JavaScript, videos, fonts, or downloads. It can also reduce origin load and improve response times on cacheable resources. But not everything can be cached. Login, stock queries, payment operations, cart updates, personalized recommendations, or database calls need to reach the backend.
That’s where infrastructure location becomes central again. A design with frontend cached at the edge but dynamic backend in Virginia can deliver an acceptable initial load but still penalize each relevant user action. On mobile, this situation worsens due to network variability, packet loss, cell changes, and less stable connections.
| Layer | What improves | What it doesn’t solve alone |
|---|---|---|
| CDN | Static resources, cache, downloads, video, images | Dynamic, non-cacheable operations |
| Edge functions | Light logic near the user | Complex databases or transactional state far away |
| Nearby cloud region | Lower RTT than distant regions | Dependency on services available in that region |
| Local infrastructure | Low latency for domestic users | Requires good connectivity, operation, and resilience design |
| Multi-region | Resilience and proximity per market | Increased data complexity, consistency, and cost |
In Argentina, there’s an additional peculiarity: major hyperscalers do not show a complete public region in the country on their official maps. AWS lists a Local Zone in Buenos Aires, associated with the primary US East (N. Virginia) region, allowing certain resources to be closer to end users. But a Local Zone is not the same as a full region with the complete catalog of services. Azure, Google Cloud, and Oracle publish global region maps where coverage in Latin America is organized around other countries and locations.
Therefore, the decision should not be framed as “public cloud or local infrastructure,” but as a hybrid and realistic architecture. Some workloads fit well into global cloud regions: analytics, backup, disaster recovery, managed services, AI, development environments, or applications with distributed users. Others, especially those sensitive to latency and with users concentrated in a single country, can benefit from a local placement.
How to measure before migrating a workload
Latency shouldn’t be estimated solely from a table. Before migrating, it’s essential to measure from the points where actual users are located. For an Argentine ecommerce, that means testing from Buenos Aires, Córdoba, Rosario, Mendoza, Tucumán, and other relevant zones. For a B2B SaaS, it also matters which corporate networks clients connect from. For a financial API, measurements should include the app, PSPs, banks, anti-fraud services, and third-party providers.
A useful test should include, at minimum, RTT, jitter, packet loss, TTFB, p95 and p99 response times, TLS handshake, database query times, and mobile device performance. The average can be misleading. An app may have an acceptable average latency but suffer from 99th percentile queues that ruin the experience during critical moments.
It’s also important to differentiate processing latency from network latency. A slow server in Argentina may perform worse than an optimized backend in São Paulo. But when both are well designed, geography matters. No CPU tuning can fully compensate for a RTT of 230 ms if the user is in Buenos Aires and the main backend is in Madrid.
The technical conclusion is simple: latency doesn’t show up as a line item on the provider invoice, but it appears in metrics. It influences conversions, abandonment, TTFB, API response times, payment processes, and perceived quality. For many companies, choosing where an application runs can be as critical as choosing the platform itself.
Frequently Asked Questions
What is network latency?
It’s the time for data to travel between the user and the server. Usually measured as RTT, the round-trip time of a packet.
Why is it so important in ecommerce?
Because each delay can affect page load, search, cart, login, and payment. On mobile, small delays tend to be more noticeable due to network variability.
Does a CDN eliminate the latency problem?
Not entirely. It helps greatly with static content and cacheable resources but dynamic operations still depend on where the backend, database, and APIs are located.
Is Madrid a good location to serve users in Argentina?
Madrid can be excellent for Spain and Europe, but from Argentina, RTT is roughly over 230 ms. For latency-sensitive applications, a local or regional placement is usually more suitable.
