CDN Time to First Byte Optimization: Sub-100ms TTFB at Global Scale

Time to First Byte (TTFB) is the most unforgiving web performance metric. It measures the entire network path before a single byte of content arrives — and it dictates everything that follows. If you can consistently deliver sub-100ms TTFB from edge PoPs worldwide, you win Core Web Vitals, SEO, and user experience. Here is how to engineer it.

What Sub-100ms TTFB Actually Means

TTFB is defined as the duration from the browser's navigation start to receiving the first byte of the response. Per the Navigation Timing API, it includes DNS lookup, TCP handshake, TLS negotiation, request send, and server response time. Google's Core Web Vitals guidance treats TTFB as the foundation for Largest Contentful Paint (LCP) — a slow TTFB guarantees a slow LCP.

For a global audience, sub-100ms TTFB does not mean 100ms from your origin in Virginia. It means 100ms from the edge node closest to the user in São Paulo, Singapore, or Berlin. Without a CDN, physics makes this impossible: light in fiber travels ~200km per millisecond round-trip. A 9,000km origin distance already costs 90ms in propagation alone, before any handshake.

We categorize TTFB into three tiers:

• Edge HIT (cached): 15–60ms target. Served directly from PoP RAM/SSD. This should be >85% of requests for static and semi-static assets.
• Edge MISS / Parent HIT: 70–140ms target. Requires tiered cache fetch, but avoids origin.
• Dynamic / Origin HIT: 100–220ms target. Requires route optimization, connection reuse, and Argo-style smart routing.

If your p75 TTFB for cached assets exceeds 120ms in any major region, you have an architecture problem, not a tuning problem.

Anatomy of TTFB: Where Milliseconds Go

Every TTFB can be decomposed into sequential phases. Understanding this waterfall is critical because each phase has a different optimization lever.

The largest wins are not from faster origin code, but from eliminating round trips. A standard HTTPS connection requires 3 RTTs before the request is even sent: DNS → TCP SYN/ACK → TLS handshake. At 40ms RTT, that is 120ms overhead. A CDN with Anycast, TLS 1.3, and QUIC can reduce this to 0–1 RTT for returning visitors.

1. Edge Architecture: Anycast and PoP Density

Your CDN is only as fast as its closest Point of Presence. Two architectural decisions dominate TTFB: routing and density.

Anycast vs. DNS-based routing: Traditional DNS-based CDNs return an edge IP based on the resolver's location, not the user's. Anycast advertises the same IP from every PoP and relies on BGP to route the user to the topologically nearest node. This cuts 15–40ms of DNS latency and avoids misrouting from centralized resolvers like 8.8.8.8. For sub-100ms TTFB, Anycast is non-negotiable.

PoP density and peering: Measure TTFB by ASN, not just by country. A PoP in Frankfurt does not guarantee low TTFB in rural Poland if the last-mile ISP peers poorly. Leading CDNs maintain 300+ PoPs with direct peering at IXPs and inside eyeball networks. Validate with real-user monitoring segmented by network. Our monitoring and observability guide details how to instrument TTFB by PoP, cache status, and ASN.

Also enable DNS prefetch and preconnect hints, and ensure your authoritative DNS has a low TTL with DNSSEC without adding latency. Use a managed DNS with <15ms global resolution time.

2. Eliminate Handshakes: TLS 1.3, Session Resumption, and HTTP/3

Handshake optimization is the highest-ROI TTFB lever for dynamic content where caching cannot help.

TLS 1.3 and 0-RTT

TLS 1.3 reduces the handshake from 2-RTT to 1-RTT, and with session resumption via PSK, to 0-RTT for repeat connections. Combined with TCP Fast Open, you can send the HTTP request with the initial ClientHello. This alone saves 60–90ms on high-latency links. Enforce TLS 1.3 at the edge and enable 0-RTT with anti-replay protection for safe GET requests.

QUIC and HTTP/3

QUIC merges transport and cryptography, eliminating TCP head-of-line blocking and enabling connection migration. For mobile users switching from Wi-Fi to 5G, QUIC preserves the connection instead of re-handshaking. As detailed in our HTTP/2 vs HTTP/3 analysis, QUIC's 0-RTT and improved loss recovery consistently deliver 20–30% lower p95 TTFB than HTTP/2 over TCP.

Enable HTTP/3 at the edge, advertise via Alt-Svc, and ensure your origin supports QUIC to the shield. Keep TCP+TLS as fallback, but prioritize QUIC.

# Verify TTFB and handshake efficiency from edge
curl -w "dns:%{time_namelookup} tcp:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" -o /dev/null -s https://www.example.com/

# Expected for optimized edge HIT:
# dns:0.008 tcp:0.018 tls:0.032 ttfb:0.045

# Check HTTP/3 and 0-RTT support
curl --http3 -I https://www.example.com -v 2>&1 | grep -E "Alt-Svc|QUIC|TLS 1.3"
alt-svc: h3=":443"; ma=86400, h3-29=":443"

Other critical edge optimizations: OCSP stapling (saves 50–150ms on first connection), strict keep-alive (120s+), connection coalescing for HTTP/2/3, and 103 Early Hints to start preloading before origin response.

3. Caching Strategy: The Only Way to Guarantee Sub-100ms

No amount of routing can beat serving from memory at the edge. Your cache hit ratio (CHR) directly predicts your TTFB distribution.

* 0ms for reused QUIC/TLS session, 15ms for new TLS 1.3 handshake on nearby PoP.

To push CHR above 92%:

• Separate cache keys intelligently: Strip marketing query params (utm_*, fbclid) and normalize Accept-Language variants. Use Vary: Accept-Encoding only.
• Extend TTLs with stale-while-revalidate: Serve stale for 1–7 days while revalidating asynchronously. This hides origin latency from users.
• Cache more than you think: Cache 404s for 60s, redirects for hours, and API responses with s-maxage. Even dynamic HTML can be cached for 5–30s at the edge with stale-while-revalidate for anonymous users.
• Use Cache-Control correctly: public, max-age=31536000, immutable for versioned assets; s-maxage=60, stale-while-revalidate=600 for HTML.

# Optimal edge cache headers for HTML
Cache-Control: public, s-maxage=60, stale-while-revalidate=300, stale-if-error=86400
CDN-Cache-Control: max-age=60
Surrogate-Key: page-home html
Vary: Accept-Encoding

# Purge via surrogate key on deploy — instant global invalidation
curl -X POST https://api.cdn.example/purge -H "Authorization: Bearer $TOKEN" -d '{"surrogate_keys":["page-home"]}'

For image-heavy sites, pair this with image optimization at the edge — converting to AVIF/WebP and resizing at the PoP avoids origin fetches for derivatives entirely.

4. Tiered Caching and Origin Shield

Without tiered caching, a cache MISS from 50 edge PoPs results in 50 origin hits (thundering herd). With tiered caching, those 50 misses collapse to 1 origin hit via a regional shield PoP.

Configure a two-tier hierarchy: global edge (300+ PoPs) → regional parent (e.g., Ashburn, Frankfurt, Singapore) → shield → origin. The parent is chosen for proximity to origin and dense interconnect. This reduces MISS TTFB by 60% and origin load by 85–95%.

Complement this with origin keep-alive and connection pooling. Maintain warm, reused HTTP/2 or HTTP/3 connections from shield to origin with 60–90s idle timeout. Cold origin TCP+TLS adds 80–150ms per MISS. Also enable Argo / dynamic acceleration for uncacheable routes: smart routing over private backbone avoids congested public internet, cutting dynamic TTFB by 25–40%.

Finally, protect TTFB under attack. A DDoS flood that saturates origin will spike TTFB to seconds. Always front origin with DDoS protection and rate limiting at the edge so malicious traffic never reaches the shield.

5. Measure What Matters: RUM and Synthetic

You cannot optimize what you do not measure by cache status and geography.

• Segment TTFB by: cache_status (HIT/MISS/PASS), PoP colo, country, ASN, HTTP version, and device class. Aggregate averages hide regional regressions.
• Use both RUM and synthetic: RUM shows real p75/p95 by network; synthetic (Catchpoint, WebPageTest) gives controlled waterfall analysis.
• Monitor TTFB budget alerts: Alert if p75 HIT TTFB >80ms or MISS ratio >10% in any region for 10 minutes.

// Capture TTFB with cache status in RUM
const nav = performance.getEntriesByType("navigation")[0];
const ttfb = nav.responseStart - nav.requestStart;
fetch("/analytics/ttfb", {
  method: "POST",
  body: JSON.stringify({
    ttfb: Math.round(ttfb),
    cache: response.headers.get("x-cache"), // HIT, MISS, BYPASS
    colo: response.headers.get("cf-ray")?.slice(-3),
    h3: navigator.connection?.effectiveType
  })
});

Expose Server-Timing headers from edge to debug: Server-Timing: edge;dur=4, parent;dur=22, origin;dur=48 lets you pinpoint whether TTFB is edge, parent, or origin bound.

Consistent sub-100ms TTFB is not a single trick — it is the compound effect of Anycast routing, 0-RTT handshakes, QUIC, aggressive but correct caching, tiered shielding, and relentless measurement. Start with handshake elimination and cache hit ratio; those two alone typically move global p75 TTFB from 280ms to under 90ms.