Why Global Apps Need 330 Edge Locations, Not 20 Regions

A user in Jeddah opens your app. The nearest server is in Frankfurt, 4,500 kilometres away. Light travels through fibre optic cable at roughly two-thirds the speed of light in a vacuum. Physics alone adds 25 milliseconds of round-trip latency before a single byte of your application loads.

But physics is the optimistic scenario. Real-world routing adds hops. TCP handshakes add round trips. TLS negotiation adds more. By the time your user sees a response, 150-300 milliseconds have passed. For a static marketing page, that is acceptable. For an interactive dashboard loading images, data, and dynamic content, it is the difference between "fast" and "waiting."

This is not a theoretical problem. It is a geography problem. And the solution is not faster servers. It is closer servers.

Regions vs Edge Locations: The Difference That Matters

The hosting industry uses two terms that sound similar but mean fundamentally different things.

A region is a data centre cluster, typically operated by AWS, Google Cloud, or Azure. AWS has roughly 33 regions worldwide. Each region contains multiple availability zones with full compute, storage, and networking capabilities. Regions are designed for running databases, processing jobs, and hosting applications that need the full stack of cloud services.

An edge location (sometimes called a Point of Presence or PoP) is a lightweight compute node deployed in a city. Its purpose is to be close to users. Edge locations run code, serve content, and terminate connections. They do not typically host databases or heavy processing workloads. What they lack in depth, they make up in density and proximity.

Cloudflare operates 330+ edge locations across more than 120 countries. AWS CloudFront (used by Vercel) has approximately 600+ edge locations for CDN caching, but Vercel's serverless functions only run in roughly 20 regions. This distinction is critical.

When Vercel serves a static asset, it uses CloudFront's CDN -- your images and CSS files reach users quickly from a nearby cache. But when Vercel runs a serverless function, an API route, or server-side rendering, that computation happens in one of approximately 20 regions. The gap between "where your static files are" and "where your code runs" is where latency hides.

Why Density Changes Perceived Performance

Google's research on web performance consistently shows that Time to First Byte (TTFB) is one of the strongest predictors of user experience. TTFB measures how long the browser waits before the first byte of content arrives. Every millisecond of TTFB delays every subsequent metric: First Contentful Paint, Largest Contentful Paint, and Time to Interactive.

For static content served from a CDN, TTFB is typically 10-50ms regardless of the user's location. The CDN cache is nearby. Content is pre-built.

For dynamic content -- server-rendered pages, API responses, authenticated data -- TTFB depends on where the server-side code runs. And that depends on how many locations your platform supports for compute, not just for caching.

Here is what the latency difference looks like for a server-rendered page:

The pattern is obvious: users near a region get good performance on both architectures. Users far from a region pay a heavy latency tax. And "far from a region" describes most of the world's population.

Of the 8 billion people on earth, roughly 5 billion live in Asia, Africa, the Middle East, and South America -- regions where cloud provider coverage is thinnest. A hosting platform with 20 compute regions is optimised for North America and Western Europe. A platform with 330+ compute locations is optimised for earth.

The Image-Heavy Application Problem

Latency matters for every application. It matters disproportionately for applications that serve large assets.

Consider an application that displays 20 high-resolution images on a gallery page. Each image is 500KB. The total payload is 10MB. On a modern connection, bandwidth is rarely the bottleneck. Latency is.

Here is why: HTTP/2 multiplexing allows multiple images to download simultaneously over a single connection. But the connection must first be established to the server, which requires a TCP handshake (1 round trip) and a TLS handshake (1-2 round trips). Each round trip is affected by the distance between the user and the server.

For a user 5ms from an edge location:

• TCP + TLS handshake: ~15ms
• First image byte arrives: ~20ms
• All 20 images loaded (parallel): ~200-400ms

For a user 150ms from a region:

• TCP + TLS handshake: ~450ms
• First image byte arrives: ~600ms
• All 20 images loaded (parallel): ~1,200-2,000ms

The user near the edge sees a fully loaded gallery in under half a second. The user far from the region waits two seconds. According to research from Akamai, a 100-millisecond delay in load time can decrease conversion rates by 7%. Two seconds of additional load time increases bounce rates by 103%.

For any application where visual content is the product -- photography platforms, e-commerce, real estate, media galleries, construction monitoring, medical imaging -- edge density is not a performance optimisation. It is a business metric.

When 20 Regions IS Enough

Honesty requires acknowledging when edge density does not matter.

US-only or EU-only applications. If every user lives within 2,000 kilometres of a major AWS region, the latency difference between 20 regions and 330 edge locations is negligible. For a B2B SaaS product serving US companies, the user in San Francisco and the user in New York both get good performance from US regions.

Text-heavy, low-asset applications. If your application primarily serves small JSON payloads and text content, the absolute latency difference is small. A 50ms vs 5ms TTFB matters less when the total page weight is 50KB. The user perceives both as instant.

Applications with heavy database dependencies. If every request requires a round trip to a centralised database, edge compute does not eliminate the database latency. Running your function in Jeddah does not help if it then queries a database in Virginia. Edge compute shines when the function can respond from cache, from local state (Durable Objects), or from a globally replicated data layer.

Infrequently accessed internal tools. If your application has 50 users who access it a few times per day, the latency difference is real but the business impact is minimal. Optimise for features and reliability first, edge density second.

The Cold Start Multiplier

Edge density interacts with another performance factor: cold starts.

On traditional serverless platforms (AWS Lambda, which powers Vercel's functions), a cold start occurs when a function has not been invoked recently. The platform must allocate a container, load the runtime, initialise the function, and then process the request. Cold starts on AWS Lambda typically add 250-500ms for Node.js functions and 1-3 seconds for larger runtimes.

On edge platforms using V8 isolates, cold starts are measured in single-digit milliseconds. The isolate model is lighter. There is no container to spin up, no operating system to initialise. The function loads and executes almost immediately.

Now combine cold starts with geographic distance:

• 20 regions + 250ms cold start + 150ms geographic latency = 400ms+ before the user sees anything
• 330 locations + 2ms cold start + 5ms geographic latency = 7ms before the user sees anything

The cold start tax is paid on the first request after a period of inactivity. For applications with uneven traffic patterns -- spikes during business hours, quiet periods overnight -- cold starts are not edge cases. They are the experience for the first user each morning, in each time zone, on each function.

With 20 regions, cold starts affect all users in a geographic band simultaneously. With 330 locations, a cold start in Lagos does not affect a user in Nairobi. The blast radius of a cold start shrinks with edge density.

What Edge Density Enables

Beyond raw performance, having compute in 330+ locations enables architectural patterns that are not practical with 20 regions.

Geographic Data Compliance

GDPR, data sovereignty laws, and industry regulations increasingly require data to be processed within specific jurisdictions. With 20 regions, you choose the closest compliant region. With 330 locations, you can process data in-country for most nations. The function that handles a German user's request runs in Germany. The function that handles a Brazilian user's request runs in Brazil. Compliance becomes a platform feature rather than an architectural challenge.

Latency-Sensitive Automations

Business automations that run at the edge benefit directly from proximity. A webhook that processes a payment notification, updates a dashboard, and sends an alert completes faster when every step runs close to the trigger source. For platforms where serverless functions have business context, edge density means that context-aware operations execute with minimal latency anywhere in the world.

Real-Time Features Without Centralisation

WebSocket connections and real-time data streams benefit from edge density because the persistent connection terminates at the nearest location. A live dashboard in Tokyo connects to a nearby edge node, not a distant region. The perceived real-time experience is genuinely real-time, not "mostly real-time with occasional lag."

The Decision Framework

Ask these questions about your application:

1. Where are your users? If they are concentrated in one country or region, 20 compute regions may be sufficient. If they span multiple continents, edge density directly affects their experience. Pull your analytics. Map the distribution. The data will answer the question.

2. What does your application serve? Text and small JSON payloads are latency-tolerant. Images, media, and rich interactive content are latency-sensitive. The heavier your average response, the more edge density matters.

3. How dynamic is your content? Fully static content benefits from CDN caching regardless of compute locations. Personalised, authenticated, or real-time content requires compute at the edge. If most of your pages are server-rendered, the compute location determines the user experience.

4. What are your growth markets? If you plan to expand into Africa, the Middle East, Southeast Asia, or South America, evaluate your platform's coverage in those regions now. Replatforming after you have users in 40 countries is harder than choosing the right platform before.

5. What is your latency budget? Google recommends TTFB under 800ms as a baseline, with good performance under 200ms. If your TTFB from underserved regions exceeds 200ms, edge density is a direct path to improvement.

The Bottom Line

Twenty compute regions is enough for applications that serve users in well-connected markets and deliver lightweight content. It is the industry standard. Most applications built in the last decade were designed around this constraint.

Three hundred and thirty compute locations changes the constraint. Server-rendered pages load in single-digit milliseconds from almost anywhere on earth. Cold starts disappear as an observable phenomenon. Image-heavy applications feel instant in markets where they previously felt sluggish. And the cost of serving global users drops because bandwidth is not metered and compute is not centralised.

The question is not whether edge density is better. Physics answers that. The question is whether your application and your users benefit enough to make it a platform selection criterion.

For a US-only SaaS dashboard, probably not. For a global application serving images, media, or real-time data to users across 50+ countries, the difference is not marginal. It is the product experience.

Build for where your users are. Not where your servers happen to be.

---

Ready for global edge performance? WaymakerOS Host runs on 330+ edge locations worldwide, with zero-bandwidth pricing and sub-millisecond cold starts. Explore Host or see the full platform comparison.

---

Related reading: Understand the hidden cost of serverless cold starts, see how edge platforms skip the bandwidth meter, or read the complete deployment platform vs business platform comparison.