Global Delivery: Minimizing Latency Across Continents

The goal is straightforward: every user, regardless of whether they are in Tokyo, London, or São Paulo, gets a sub-100ms experience. Achieving this requires abandoning the single-origin model and embracing three core strategies that work together.

Stale-While-Revalidate: The Foundation

The most impactful latency optimization is also the simplest: serve cached content immediately while fetching fresh content in the background. This pattern, codified in the HTTP stale-while-revalidate Cache-Control directive, eliminates the perception of latency entirely.

When a user requests a page, the edge cache returns the previously cached version instantly (even if it is minutes old) and simultaneously fetches a fresh version from the origin. The user sees content immediately; the next request gets the updated version. This works because most content—blog posts, product pages, documentation—does not need to be real-time.

Edge Rendering: Compute Where the User Is

Caching handles read-heavy workloads, but dynamic content—personalized dashboards, authenticated pages, real-time data—must be computed per request. Edge rendering solves this by executing application code at the data center closest to the user.

Next.js with the edge runtime, Hono, and Astro all support deploying server-rendered pages to Cloudflare Workers. The Worker receives the request, fetches the necessary data from D1 or KV, renders the HTML, and returns it—all within milliseconds because every hop stays within Cloudflare's network.

Data Locality: Move Data, Not Requests

Even with edge rendering, fetching data from a centralized database undermines the benefit. Each storage product must be globally distributed for the architecture to work. D1's global SQLite replicates data to multiple regions. KV is globally distributed by design. R2 serves objects from its worldwide network.

The pattern: hot data (session tokens, feature flags, cached queries) lives in KV for instant access. Warm data (user profiles, recent posts) lives in D1 with global distribution. Cold data (archived records, raw uploads) lives in R2. Each layer optimized for its access pattern and geographic requirements.

Eliminating Geographic Distance

When all three layers work together, the user's geographic location becomes irrelevant. A visitor in Tokyo hits a Worker in Tokyo, reads from a KV cache in Tokyo, and renders HTML in Tokyo. The origin might be in Virginia, but the user never touches it.

The result: P50 response times of 20–40ms and P95 response times under 100ms, regardless of continent. Speed is not a feature you optimize for later—it is a property of the architecture from day one.