Amazon calculated that every 100ms of added costs them 1% in sales revenue. At their scale, that is billions of dollars per year. Google found that adding 500ms of latency to search results reduced traffic by 20%. Walmart discovered that for every 1 second of page load improvement, conversions increased by 2%.
Network latency is often the dominant component of total response time, especially for globally distributed applications. Your server-side processing might take 5ms, but if the network round trip from a user in Mumbai to your server in Virginia adds 200ms, that is what the user actually feels.
Unlike server-side optimization (where you hit diminishing returns after profiling a few hot paths), network latency optimization can yield dramatic improvements with relatively straightforward changes. Moving your servers closer to users, reducing protocol round trips, compressing payloads, and choosing the right transport protocols can cut perceived latency by 50-80% without touching a single line of application code.
The physics are non-negotiable: light travels at roughly 200 km/ms in fiber optic cable. A round trip from New York to London (11,000 km of cable) takes at minimum 55ms just for photons. You cannot optimize past physics. But you can stop making it worse.
1. Geographic placement (biggest single impact): Deploy servers close to users. Us-east-1 to Mumbai = 200ms round trip. Ap-south-1 to Mumbai = 5ms. For a global application, deploy in 3-5 regions and route users to the nearest one via GeoDNS or anycast.
2. for static and dynamic content: CloudFront, Cloudflare, and Fastly cache content at 200-400+ edge locations worldwide. A user in Tokyo loads images from Tokyo, not Virginia. Cloudflare even caches dynamic API responses at the edge with their Cache API, serving personalized content in under 10ms.
3. Reduce protocol round trips:
| Technique | What It Saves | How |
|---|---|---|
| /2 multiplexing | Multiple connections | One connection handles all requests in parallel |
| HTTP/3 (QUIC) | TCP handshake + TLS handshake | Combined 1-RTT handshake, 0-RTT for returning visitors |
| TCP Fast Open | 1 RTT on repeat connections | Data sent with SYN packet |
| prefetching | 1 DNS lookup per domain | Browser resolves domains before clicking |
Cloudflare Argo Smart Routing: Instead of routing traffic over the public internet (which follows BGP least-cost paths, not lowest- paths), Argo routes through Cloudflare's private backbone, choosing the fastest path between edge and origin. Cloudflare reports Argo reduces time-to-first-byte by 30% on average and over 40% for long-distance routes.
Google's Global Software (GSLB): Google runs their own global fiber backbone connecting 40+ data centers. When you search on Google, your request hits the nearest edge PoP, gets routed over Google's backbone to the optimal data center (based on both latency and capacity), and the response returns the same way. No public internet hop between PoPs.
Amazon Route 53 Latency-Based Routing: Route 53 measures latency between regions and client locations, then returns answers pointing to the region with the lowest measured latency. Combined with CloudFront for static assets, this gives users the feeling of local servers even for dynamic content.
Stripe's API latency SLA: Stripe commits to p99 API latency under 200ms for payment processing. They achieve this through aggressive connection pooling, regional API endpoints (api.stripe.com resolves to the nearest region), and precomputed payment method eligibility checks that avoid synchronous calls to card networks during checkout.
3 questions - Score 80% to pass
Which single optimization typically has the LARGEST impact on latency for a global application?
Why does TLS 1.3 reduce latency compared to TLS 1.2?
Why does Cloudflare's Argo Smart Routing reduce latency compared to standard internet routing?
| Preconnect hints |
| TCP+TLS setup |
| Browser establishes connection before first request |
| Early hints (103) | Server think time | Send preload headers before the response is ready |
4. Compress everything: Brotli compression reduces HTML/CSS/JS by 15-25% more than gzip. At Google's scale, switching from gzip to Brotli saved 1-2 PB of daily . Smaller payloads transfer faster, especially on mobile networks where bandwidth is the bottleneck.
5. TLS optimization: TLS 1.3 reduced the handshake from 2 round trips to 1 round trip. On a 100ms connection, that saves 100ms on every new connection. OCSP stapling eliminates an extra round trip for certificate verification. Session resumption skips the full handshake for returning visitors.
Cloudflare measured TLS 1.3 adoption across their network and found it reduced connection setup time by 40% compared to TLS 1.2.
6. Connection pooling between services: A new TCP+TLS connection between microservices costs 2-3 round trips (handshake). In a data center with 0.5ms RTT that is 1-1.5ms. At 10,000 requests per second, creating new connections for each request wastes 10-15 seconds of cumulative setup time per second. Connection pooling (HTTP keep-alive, persistent channels) eliminates this entirely.
7. Protocol choice for service-to-service: gRPC over HTTP/2 with protobuf serialization is 3-10x faster than REST over HTTP/1.1 with JSON for service-to-service communication. The gains come from binary serialization (smaller payloads), multiplexed streams (no head-of-line blocking), and header compression (HPACK).