Netlify Edge Functions: Where the Waiting Really Happens

Key takeaways

• V8 isolates and Firecracker microVMs provide isolation at different layers and can work together.
• Response time includes network travel and data access as well as code execution.
• A function close to its users can still be far from its database.
• Attributing a speedup to the runtime requires separating its effects from routing, caching, and other changes.

An edge function can finish its code quickly and still leave the user waiting. Understanding Netlify Edge Functions performance means following the entire request: where it runs, where it gets its data, and where the milliseconds accumulate.

V8 and Firecracker operate at different layers

A V8 isolate separates execution state and memory within the JavaScript engine. Multiple isolates can live inside a single process. That makes an isolate a smaller unit of execution than a virtual machine running a full guest operating system.

A Firecracker microVM uses hardware virtualization to run a guest operating system and its applications. It strips down the features of a general-purpose virtual machine to reduce startup time and resource overhead.

These approaches can coexist. V8 can run inside a microVM.

So a description such as “we switched from isolates to microVMs” deserves a closer look. What actually changed? The JavaScript engine, the isolation around it, or the architecture handling requests?

The names alone don’t explain the performance difference. They describe parts of the system at different layers.

A response can be five times faster with identical code execution

Consider a hypothetical request. To keep the arithmetic simple, leave out startup costs and other overhead.

Initially, it spends:

• 90 ms on network travel and waiting for responses.
• 10 ms executing code.

Total response time: 100 ms.

Now change the execution location and connection path. Network time drops to 10 ms. Code execution still takes 10 ms.

The request now finishes in 20 ms—one-fifth of the original time. The code itself hasn’t become any faster.

That also explains how a runtime with higher startup overhead could still deliver a faster response overall. A sufficiently large reduction in network waiting can more than offset the added startup cost.

This is an illustration, not a Netlify benchmark. For any measured improvement, the useful question is which part of the request got shorter.

Your users and your database may live on different continents

“Close to the user” is an appealing promise. It describes only one relationship in the system.

Imagine a user in London reaching a nearby edge function. If that function needs data from a database in the US, completing the request still requires a transatlantic trip.

Sequential calls compound the wait. The function might check authentication, then retrieve order history. If the second operation depends on the first, their waiting times add up.

Moving the function closer to the database could reduce those internal delays. It could also increase the distance between the user and the function. The better placement depends on the work.

A simple redirect and a personalized page requiring several database lookups have different needs. For the redirect, proximity to the user may be especially useful. For the personalized page, repeated data access may determine much more of the response time.

The edge doesn’t repeal geography. You have to account for every connection the request needs.

Read the changed conditions before crediting the runtime

A runtime migration can involve several changes at once: execution regions, intermediate servers, connection reuse, or cache policies.

If performance improves after all of those change, the result belongs to the new configuration as a whole. Identifying the runtime’s contribution takes a more controlled comparison.

To assess the runtime, hold major conditions such as code and data location constant. To assess the network route, keep the runtime constant while comparing paths. Otherwise, a routing improvement can easily get credited to the execution environment.

The measurement itself matters, too. Separate cold starts, when the environment must first be prepared, from requests handled by an environment that is already ready.

Look beyond averages. p95 latency describes the time within which 95% of measured requests finish. It helps show how slow requests behave when an average might obscure them.

For Netlify Edge Functions, the useful starting point is a breakdown of where the request spends its time. That makes performance claims easier to interpret and deployment choices easier to defend. Before choosing a faster way to execute the code, find out how much of the wait is actually execution.