When users are distributed globally, latency becomes a product feature, not just a metric. A 100ms increase in page load time reduces conversion rates by 7% according to Akamai research, and Google reports that 53% of mobile users abandon pages that take longer than 3 seconds. Reducing latency for a global audience requires layered architecture decisions across region placement, CDN configuration, caching strategy, and continuous observability. No single tool solves the problem; the system must work together.
---
Understanding Latency Sources
Before optimizing, you need to know where latency originates. A typical HTTP request crosses multiple boundaries, each adding delay:
| Latency Source | Typical Delay | Optimization Lever |
| DNS resolution | 20-120ms | DNS provider with Anycast |
| TCP handshake | 1 RTT (10-200ms) | Edge termination |
| TLS negotiation | 1-2 RTT (20-400ms) | TLS 1.3 + session resumption |
| Server processing | 5-500ms | Code and query optimization |
| Data transfer | Size / bandwidth | Compression + CDN caching |
| Client rendering | 50-2000ms | Bundle optimization |
For a user in Tokyo accessing a server in Virginia, the physical speed of light alone adds roughly 85ms each way. You cannot optimize physics, but you can move compute and data closer to users.
Region Strategy
Placing compute near your top user clusters is the most impactful latency reduction. Measure before you deploy.
How to Choose Regions
Active-Active vs Active-Passive
| Pattern | Latency Benefit | Complexity | Best For |
| Single region | None | Low | Early-stage, single-market apps |
| Active-passive | Failover only | Medium | DR requirements |
| Active-active | Full latency reduction | High | Global user base |
For most teams starting out, a single primary region plus CDN edge caching delivers 80% of the latency benefit at 20% of the complexity. Active-active becomes worthwhile when you have significant user populations on multiple continents.
<h1>Example region configuration for a global SaaS</h1>
regions:
primary:
location: us-east-1
role: active
services: [api, worker, database-primary]
secondary:
location: eu-west-1
role: active
services: [api, worker, database-replica]
edge:
location: ap-northeast-1
role: read-replica
services: [api-read, cache]
routing:
strategy: geoproximity
health_check_interval: 10s
failover_threshold: 3
Keep cross-region synchronous calls off the critical request path. If your Tokyo API server must wait for a database write in Virginia before responding, you have negated the benefit of the edge deployment. Use asynchronous replication for reads and queue-based patterns for writes that must reach the primary.
CDN and Edge Design
A CDN reduces latency by terminating TLS and serving cached content from edge locations close to users. The configuration matters as much as the CDN vendor.
TLS Optimization
<h1>Nginx TLS configuration for low latency</h1>
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
<h1>OCSP stapling eliminates an extra round trip</h1>
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;
<h1>Early hints (103) for critical resources</h1>
add_header Link "</css/main.css>; rel=preload; as=style" always;
TLS 1.3 reduces the handshake from 2 round trips to 1, and with 0-RTT resumption, returning visitors experience near-zero TLS overhead. Combined with HTTP/2 or HTTP/3, multiplexing eliminates head-of-line blocking.
Cache-Control Headers
Every response from your origin should include explicit cache-control directives:
<h1>Static assets: cache aggressively with immutable</h1>
Cache-Control: public, max-age=31536000, immutable
<h1>API responses with shared caching</h1>
Cache-Control: public, max-age=60, stale-while-revalidate=300
<h1>Private user-specific data</h1>
Cache-Control: private, no-store
Multi-Layer Caching Model
Effective caching operates at four layers, each with different TTL strategies and invalidation patterns:
Layer 1: Browser Cache
Assets with content-hashed filenames get `immutable` cache headers. HTML documents get short TTLs or `no-cache` with ETag validation. Service workers can add offline capability and pre-caching for known navigation paths.
Layer 2: CDN Edge Cache
The CDN edge is your highest-impact cache layer for static and semi-dynamic content. Configure surrogate keys or cache tags for granular invalidation:
<h1>Tag-based purging example</h1>
curl -X POST https://cdn.example.com/purge \
-H "Authorization: Bearer $CDN_TOKEN" \
-d '{"tags": ["product-catalog", "pricing-page"]}'
Layer 3: Application Cache (Redis)
Use Redis for computed results, session data, and database query results that are expensive to regenerate:
<h1>Cache-aside pattern with TTL and jitter</h1>
import random
import redis
cache = redis.Redis(host="redis.internal", port=6379)
async def get_product(product_id: str):
cache_key = f"product:{product_id}"
cached = cache.get(cache_key)
if cached:
return json.loads(cached)
product = await db.fetch_product(product_id)
# Add jitter to prevent thundering herd
ttl = 300 + random.randint(0, 60)
cache.setex(cache_key, ttl, json.dumps(product))
return product
Layer 4: Database and Index Tuning
Even with upper cache layers, your database should be tuned for the queries that miss cache. Cover indexes for your hottest read paths and monitor slow query logs continuously.
Use event-driven invalidation over broad cache flushes. When a product is updated, invalidate that specific cache key rather than flushing the entire product cache.
Observability for Latency Control
You cannot improve what you do not measure. Instrument every layer and track latency from the user perspective, not just the server perspective.
Key Metrics to Track
| Metric | Target | Measurement Point |
| TTFB (Time to First Byte) | < 200ms | CDN edge / origin |
| LCP (Largest Contentful Paint) | < 2.5s | Browser (RUM) |
| API p95 response time | < 500ms | Load balancer |
| API p99 response time | < 1000ms | Load balancer |
| Cache hit ratio (CDN) | > 90% | CDN analytics |
| Cache hit ratio (Redis) | > 85% | Redis INFO stats |
| Regional error rates | < 0.1% | Per-region monitoring |
Alerting Strategy
Define SLOs and alert on error budget burn rate, not static thresholds:
<h1>SLO definition example</h1>
slos:
- name: api-latency
description: "API p95 response time under 500ms"
target: 99.5%
window: 30d
alert_burn_rate:
fast: 14.4x # 2% budget in 1 hour
slow: 6x # 5% budget in 6 hours
- name: availability
description: "Successful responses (non-5xx)"
target: 99.9%
window: 30d
This approach prevents alert fatigue. A brief latency spike that self-resolves does not page anyone, but a sustained degradation burning through error budget triggers an alert before users are meaningfully affected.
Architecture Decision Record
When implementing a global low-latency architecture, document your decisions using this template:
<h2>ADR: Global Latency Architecture</h2>
Status: Accepted
Date: 2026-04-01
Context: 40% of users are in APAC, 35% in NA, 25% in EU.
Current p95 TTFB from APAC is 1.2s (server in us-east-1).
Decision: Deploy read-replica API in ap-northeast-1,
CDN edge caching for all static + semi-dynamic content,
async replication for writes back to us-east-1 primary.
Expected outcome: APAC p95 TTFB < 200ms.
Review date: 2026-07-01.
Explore architecture options on the Cloud Computing page and review available deployment targets in the Services Overview. For rollout planning and support, visit Contact to discuss your specific traffic patterns and region requirements.
Frequently Asked Questions
What is the most effective way to reduce global latency?
Place compute and cached data close to your largest user clusters. CDN edge caching delivers the best cost-to-latency-reduction ratio for most applications. Active-active multi-region deployments provide the lowest latency but require significant operational investment in data replication and conflict resolution.
How many regions do I need for a global application?
Most applications achieve acceptable latency with 2-3 regions plus CDN edge coverage. Start with one primary region and a CDN, measure real user latency from each continent, and add regions only where CDN caching alone cannot meet your latency targets. Over-deploying regions increases operational complexity and cost without proportional benefit.
Should I use HTTP/2 or HTTP/3?
HTTP/2 is the safe default with broad support. HTTP/3 (QUIC) provides meaningful improvements on lossy mobile networks and reduces connection setup time. If your CDN supports HTTP/3, enable it. The protocol negotiation is automatic, so clients that support HTTP/3 use it while others fall back to HTTP/2.
How do I handle database writes in a multi-region setup?
Route all writes to a single primary region and replicate asynchronously to read replicas in other regions. For applications that require multi-region writes, use conflict-free replicated data types (CRDTs) or last-writer-wins strategies with causal ordering. Most applications do not need multi-region writes.
What cache hit ratio should I target?
A CDN cache hit ratio above 90% is a strong target for content-heavy sites. API-heavy applications may see 60-80% depending on personalization. If your hit ratio is below 50%, audit your cache-control headers, cache key design, and content segmentation before adding more edge nodes.
Final Takeaway
Low-latency global delivery is a systems discipline. Region placement, CDN configuration, multi-layer caching, and continuous observability must work together. Start with CDN edge caching and a single well-placed region, measure real user latency, and add complexity only where the data justifies it.