What Is Edge Routing? (And Why It's 10× Faster Than a Reverse Proxy)

If you've ever set up a reverse proxy to serve multiple services under one domain, you know the setup: an nginx configuration file, a VPS somewhere in a data center, SSL certificate renewal via Certbot, and the quiet anxiety of knowing that VPS is a single point of failure for your entire routing layer.

This architecture works. It's served the web for decades. But it has a fundamental latency problem that most teams don't think about — and it becomes very visible in your Core Web Vitals once you start looking.

This post explains what edge routing is, why it's faster by a factor of 10 or more for non-US users, and what that means in practice for a site serving a global audience.

The geography problem with traditional reverse proxies

A VPS is in a data center. Data centers are in cities. When a user in London requests content from an nginx proxy in us-east-1 (AWS's North Virginia region), the request travels:

1. London → transatlantic cable → Virginia (physical distance: ~5,600km)
2. SSL handshake at the Virginia server (~80ms round trip)
3. nginx processes the request and forwards to your origin server
4. Origin server responds to nginx in Virginia
5. Virginia → transatlantic cable → London

The speed of light in fiber optic cable is approximately 200,000 km/s. London to Virginia is about 5,600km. The theoretical minimum one-way latency is 28ms — in practice, with routing overhead, it's 70–90ms each way.

For a London user hitting a us-east-1 nginx proxy, the SSL handshake alone adds ~160ms of latency. The total time from request to first byte (TTFB) easily reaches 300–400ms before your origin server has even started generating a response.

Now consider a user in Singapore, or São Paulo, or Cape Town. The distances are longer. The latency compounds.

What edge routing is

An edge network is a distributed system of data centers placed geographically close to end users. Cloudflare — which Furl is built on — operates 310 data center locations globally as of early 2026, covering every major population center on earth.

When a user in Singapore requests yourcompany.com/blog, an edge network doesn't route that request to a server in Virginia. It routes it to a Cloudflare data center in Singapore (or Kuala Lumpur, if that's closer). The request never crosses an ocean.

Edge routing means the routing logic runs at this geographically proximate node. The SSL handshake happens locally — the user in Singapore is connecting to a server ~15km away, not 15,000km away. The TTFB for the initial connection drops from 300ms to 15–30ms.

The origin server (your WordPress instance, your Webflow site, your Wix site) still lives wherever it lives. But the routing and initial connection overhead — which is the slow part for global users — happens at the edge.

Real latency measurements

We ran a controlled benchmark comparing three configurations:

1. Direct to origin: User connects directly to WordPress running on a DigitalOcean Droplet in nyc3
2. Nginx on VPS: nginx reverse proxy on a $40/mo DigitalOcean Droplet in nyc3 sitting in front of the same WordPress origin
3. Furl edge routing: Furl routing to the same WordPress origin, measured from the same test cities

Test methodology: WebPageTest, 5 runs per location per configuration, median TTFB measured. All tests run to a single WordPress blog post page (warm cache, no heavy JS). January 2026.

Time to First Byte (TTFB) — milliseconds

The pattern is clear: for users in the same region as the origin server (New York), the difference is modest. For everyone else — which is most of the world's internet users — edge routing is dramatically faster.

The average speedup across all non-US test cities in our benchmark: 8.5×.

Why the speedup is so large

Several factors compound:

1. SSL handshake distance

A TLS 1.3 handshake requires 1 round trip (TLS 1.2 requires 2). Each round trip from Singapore to Virginia is ~200ms. Edge routing means the TLS handshake completes in ~10ms (local Singapore data center), not ~200ms.

TLS 1.3 is supported by all modern clients and Cloudflare's edge. The nginx VPS in our benchmark was also running TLS 1.3 — but the physical distance still imposed its latency penalty.

2. TCP connection establishment

Before TLS, TCP requires a 3-way handshake. Same geography penalty. Singapore → Virginia TCP setup: ~200ms. Singapore → local Cloudflare node: ~10ms.

3. DNS resolution

DNS resolution for edge-served domains is handled at Anycast infrastructure. The DNS query for yourcompany.com resolves to the nearest Cloudflare IP — which is geographically proximate to the user. For a VPS setup, DNS resolves to the single VPS IP — users in Singapore get the same IP as users in New York.

4. HTTP/2 and HTTP/3

Cloudflare's edge nodes support HTTP/3 (QUIC) for all connections. HTTP/3 eliminates the head-of-line blocking problem of TCP and reduces connection latency further. A VPS nginx setup can support HTTP/3 but requires manual configuration and is not enabled by default.

What this means for Core Web Vitals

Google's Core Web Vitals include Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP). TTFB directly affects LCP — the time until the largest visible element on the page loads.

Google's LCP threshold:

• Good: LCP under 2.5 seconds
• Needs improvement: 2.5–4 seconds
• Poor: Over 4 seconds

For a server-rendered page (WordPress, for example), LCP is heavily influenced by TTFB because the browser can't start rendering until it receives the HTML. A 200ms TTFB for a Singapore user might look fine in isolation — but add render time, font loading, and image loading, and you're comfortably past 2.5 seconds.

In our benchmark, moving from the nginx VPS baseline to Furl edge routing reduced median LCP for Singapore users from 3,840ms to 890ms on the same WordPress blog post. That's the difference between a "Poor" Core Web Vitals rating (>4s) and a "Good" rating (<2.5s) for a substantial portion of global traffic.

The nginx VPS approach: what it's good for

We're not arguing nginx is bad. For US-centric sites, the latency difference is modest. And nginx has significant advantages in some contexts:

When nginx makes sense:

• You have full control requirements (complex rewrite rules, custom Lua modules, auth middleware)
• Your audience is primarily in the same geographic region as your VPS
• You need to keep the routing layer entirely on your own infrastructure for compliance reasons
• Your traffic is very low and you want maximum cost control

When edge routing makes more sense:

• You have significant traffic outside your VPS's region
• You don't want to maintain server infrastructure
• Your Core Web Vitals are limited by TTFB for non-local users
• You need instant global routing changes (Furl route updates propagate globally in under 1 second)

How edge routing handles the origin connection

A common question: if the routing happens at the edge, how does the edge node connect to your origin? Isn't that still a slow cross-ocean connection?

Yes — but it's optimized in two ways:

Argo Smart Routing: Furl uses Cloudflare's Argo Smart Routing, which finds the fastest path from the edge node to your origin server using Cloudflare's private backbone network. Instead of routing through the public internet (with its congestion and unpredictable routing), requests from the Singapore edge node to your us-east-1 WordPress server travel over Cloudflare's private, optimized network.

Cloudflare reports that Argo Smart Routing reduces origin connection latency by an average of 33% compared to public internet routing.

Edge caching: For cacheable content (static blog posts, documentation pages, product pages), the edge node serves the response from cache. The origin connection is only needed for the first request (or after the cache TTL expires). Cache hit rate for most content-focused sites is 70–90%, meaning the majority of requests never need to reach the origin server at all.

For a Singapore user requesting a cached blog post with Furl edge routing: TTFB is ~8ms (serving from Singapore edge cache). The origin server in New York is not contacted at all.

Furl's specific architecture

Furl is built on Cloudflare Workers — Cloudflare's V8-based serverless runtime that runs in every Cloudflare data center globally. When you configure a route in Furl, the routing logic is deployed to all 310 Cloudflare edge locations simultaneously.

The routing logic itself (path matching, header manipulation, link rewriting) runs in V8 isolates — not in containers or VMs. V8 isolates have cold start times measured in microseconds (not milliseconds like container cold starts). There's no "spinning up" a worker for your request — the routing logic is always warm and ready.

The link rewriting (replacing wordpress.com URLs with your domain) runs as a streaming HTML transformation in the same V8 isolate — the HTML is rewritten as it streams from the origin, without buffering the entire response. This means the user starts receiving rewritten HTML immediately, not after Furl has downloaded the full page and processed it.

export default {
async fetch(request, env) {
  // Match route from configuration
  const route = matchRoute(request.url, env.ROUTES);
  if (!route) return new Response("Not found", { status: 404 });

  // Fetch from origin
  const originResponse = await fetch(route.destination, {
    headers: rewriteRequestHeaders(request.headers, route),
  });

  // Stream-rewrite the response body
  // HTMLRewriter processes the HTML as it arrives — no buffering
  return new HTMLRewriter()
    .on("a[href]", new LinkRewriter(route))
    .on("link[rel=canonical]", new CanonicalRewriter(route))
    .on("meta[property='og:url']", new OgUrlRewriter(route))
    .transform(originResponse);
},
};

The HTMLRewriter API is a Cloudflare-specific extension to the Workers runtime. It uses a streaming HTML parser (written in Rust) that processes HTML in a single pass, adding minimal overhead compared to raw proxy throughput.

The consistency argument

Beyond raw latency, there's a consistency argument for edge routing. A VPS is a single point of failure. If your $40/mo DigitalOcean Droplet goes down at 2am, your routing layer is down — every platform it serves becomes unreachable.

Cloudflare's edge network has published 100% uptime for Workers since 2019 (with one exception — a June 2022 incident lasting approximately 2 hours). The network has multiple layers of redundancy — if one data center has issues, requests automatically route to the next nearest node.

For a routing layer (which sits in front of everything else), reliability is arguably more important than raw performance. A slow VPS degrades user experience. A down VPS takes down your entire stack.

Practical implication: who benefits most

The businesses that benefit most from edge routing vs a VPS proxy are those with:

Global audiences — any company with meaningful traffic outside North America and Europe sees the largest TTFB improvements. SaaS companies typically have global customer bases, even if headquartered in San Francisco.

Content-heavy sites — blog posts, documentation, and resource pages are highly cacheable. Edge caching eliminates origin round trips for the majority of requests, pushing TTFB down to ~8–15ms globally.

Core Web Vitals concerns — if your Google Search Console shows "Poor" LCP for any segment of your traffic, TTFB is the first thing to investigate. Edge routing is often the fastest path to improvement.

Teams without DevOps resources — running nginx reliably requires monitoring, patching, SSL renewal, and capacity management. Edge routing is fully managed infrastructure — there's nothing to maintain.

The numbers, summarized

For most teams building content-driven products with global audiences, the performance difference isn't marginal — it's a qualitative shift. The difference between 220ms TTFB and 22ms TTFB for Singapore users is the difference between a page that feels slow and a page that feels instant.