When “Closer to the User” Slows Things Down

Edge computing’s central promise is that running code near the end user cuts latency. Cloudflare’s global network puts Workers within about 50ms of 95% of the world’s connected population. But that logic inverts when your application talks to a centralized database or third-party API sitting in a single region. If the Worker has to cross the globe multiple times to reach that backend, the round trips—not the distance to the user—become the bottleneck.

That’s the problem Smart Placement addresses for Workers and Pages Functions. Now in open beta for all customers, it lets Cloudflare automatically decide where a Worker should execute, without requiring you to specify a region or any other configuration. The placement engine weighs the latency path between the user, Cloudflare’s data centers, and your backend, then picks the location that minimizes total request duration.

The Shift Toward Stateful Serverless

Serverless was originally positioned for lightweight, stateless tasks. That’s changing. Developers are replacing traditional origin-server architectures with full applications built on Workers and Pages Functions. Those applications need state: user profiles, shopping carts, read-progress markers—all of which live in relational databases, key-value stores, blob storage, or external APIs.

Cloudflare has its own storage portfolio (Workers KV, Durable Objects, D1, R2) and is designing those systems to coordinate with Worker placement automatically. But today, the primary use case for Smart Placement is when you connect a Worker to non-Cloudflare services, which are typically centralized. A global user base and a global compute layer hitting a single-region backend means repeated transcontinental requests. Replication and caching help, but they introduce consistency trade-offs and cost.

One Test Case: Sydney to Frankfurt

As a concrete example, consider a user in Sydney accessing a Worker that makes three round trips to a database in Frankfurt. The Worker runs close to the user, but every request to the database traverses the globe. Moving the Worker to a data center closer to the database eliminates that penalty on each subrequest.

Cloudflare tested this scenario with 3,500 requests from Sydney to a Worker doing three round trips to an Upstash instance in eu-central-1. With Smart Placement enabled, the Worker ran near Frankfurt, and application performance improved by 4–8x compared to the default user-adjacent placement.

How Placement Decisions Get Made

Smart Placement is enabled per Worker under the Settings tab or in your wrangler.toml file. Once active, the algorithm analyzes the fetch (subrequest) calls your Worker makes in real time and compares them against latency data Cloudflare’s network has aggregated. If the Worker consistently makes more than one subrequest to a particular backend, Cloudflare automatically invokes it from the optimal data center.

Some services are deliberately excluded from the optimization:

  • Globally distributed services—Geo-distributed backends don’t benefit from moving compute close to one location, so they’re ruled out automatically.
  • Analytics and logging services—These shouldn’t sit in the request’s critical path. Use waitUntil() to avoid blocking the user response; since waitUntil() doesn’t add to perceived request duration, the algorithm ignores these services.

A full list of unsupported backends is in the developer documentation.

Seeing the Impact

Once Smart Placement is active, a new “Request Duration” tab appears on your Worker. Cloudflare continually routes 1% of traffic without Smart Placement enabled, so you can compare the baseline against the optimized path. The effect is visible immediately—no manual tuning or placement hints required.

Roadmap

Smart Placement is an initial release, and Cloudflare is planning several extensions:

  • Optimal placement when an application uses multiple backends
  • Fine-grained placement per request path, rather than per Worker
  • Support for TCP-based connections