What “edge network” means in practice, and what it does not fix
Serving from many places instead of one helps in a specific, narrow way. Where the remaining time actually goes, and why we will not turn a first-byte measurement into a promise about page loads.
What "edge network" means in practice
"Edge" is the most overused word in hosting, and it is usually deployed to end an argument rather than to describe a mechanism. Here is the mechanism, and then the part it does not cover.
What it means, concretely
Your site is served from many places rather than from one building. Our edge network spans 330+ cities, and anycast routing means every one of those locations announces the same addresses: a visitor's request arrives at whichever healthy node is nearest them, without anybody having to look up where that is.
Three consequences are real:
- Cached responses are served close to the visitor. Static assets with
hashed filenames can be cached hard, because a changed file gets a new name. See also: caching and content versions on tenant sites.
- Dynamic responses take a shorter path. A request that must be rendered
still travels to a nearby node first instead of crossing an ocean to reach us.
- Failure has somewhere to go. Health matters as much as distance: a node
that is unhealthy stops being the nearest one.
What it does not fix
The honest part, which is most of the useful part.
Distance and the visitor's own connection dominate. "Nearest node" is a round trip the visitor's ISP still has to make, on their device, on their network. A visitor on congested mobile data is not waiting on us; they are waiting on a radio link between two places we do not control. Geography sets a floor that no amount of infrastructure removes.
Origin-side work still costs real time. A cache hit is a cached render. A cache miss is a render: the page is built, the rows are read, the HTML is produced. That work happens somewhere, and it takes exactly as long as it takes, regardless of where the visitor is standing. Edge proximity cannot make a slow database query fast; it can only stop adding travel time on top of it.
Round trips are still round trips. A DNS lookup, a connection setup, a redirect, a font, an analytics tag, a chat widget, a tag manager that then loads six more things — each is another round trip on the visitor's connection. A page that pulls a dozen third-party scripts is slow for reasons that have nothing to do with where our servers are.
Bytes are still bytes. An uncompressed hero image costs the same to transfer from a nearby node as from a distant one, minus the travel time. Shipping megabytes of it is a content decision, and it is usually the biggest one on the page.
| Symptom | Where the time actually goes |
|---|---|
| First byte arrives quickly, page feels slow | Everything after the first byte — images, scripts, layout |
| Every page is slow, including a nearly empty one | A round trip per request, or a runtime doing real work |
| Slow for one visitor, fine for you | Their network, their device, their distance |
| Slow on the first load, fast after | A cache miss followed by hits |
The measurement, and the promise we refuse to make
We publish a median time to first byte, measured from our own probes to the nearest node. Read what that sentence excludes: it is our probes, not your visitors; it is the nearest node, not the whole page; and it is the first byte, not the last one.
We are not going to turn it into a promise about how fast your site loads. A fast first byte followed by two megabytes of unoptimised images is a slow page, and quoting the first number to imply the second is the oldest move in this category. If our measurement looks good and your site feels slow, the work is almost always on your side of that first byte.
What actually makes your pages fast
- Send fewer bytes. Compressed, correctly sized images beat any amount of
infrastructure.
- Send fewer requests. Every third-party tag is a round trip you agreed to.
- Let pages be cacheable. A page that is the same for everyone is served
from memory near the visitor; a page that is personalised has to be built.
- Keep the render cheap. On App Hosting, a plugin doing synchronous work on
every request costs more than the network ever will.
If you want to know how your site actually performs, measure it from where your visitors are, on a real device, and read the whole waterfall rather than the first line of it. We will tell you what our network does. We are not going to tell you it makes an unoptimised page fast.