Global CDN
Your site is kept close to the people reading it, all over the world, so a page opens quickly in Manchester and Manila alike — and holds up on the day something takes off.
Every site here sits behind a content delivery network — which is just a lot of servers spread around the world, each holding a copy of your files. A visitor's request gets answered by whichever one of those copies is physically closest to them, instead of every request worldwide converging on one machine in one location. That's edge caching in a sentence: keep a copy near the reader, not just near the writer.
What a request actually does
A visitor's browser talks to the nearest edge location, not to one server on the other side of the map. If that edge already has the file cached, the answer comes straight back — nothing gets assembled on the fly, and nothing has to wake up first. That's the entire difference between a cached page and one served from a single origin: less distance to travel, and nothing standing between the file and the wire.
GET /index.html visitor → nearest edge location cache check… HIT 200 OK · served without contacting origin
What edge caching absorbs
250 GB is 250,000 MB — a 2 MB page could be viewed roughly 125,000 times before you'd approach it, and because cached responses come from the edge instead of round-tripping to one server, that traffic doesn't concentrate anywhere it could bottleneck. Go over, and we email you before anything changes; there's no automatic overage charge.
What it means for speed
A page waiting at the edge skips the two things that usually slow a site down. Standard on every site here, and it works the same after a restore from daily backups.
The page is already sitting there, ready. It gets handed straight to the browser that asked for it.
The page was finished when you published it. What's waiting at the edge is exactly what your reader gets.
It looks and loads the same whoever asks, whenever they ask, and from wherever they happen to be.
The moments it isn't cached yet
Caching only works once something's actually been cached — here are the two moments where that isn't true yet.
The first visitor to a page — or one after the cached copy expired — triggers a quick trip back to origin to fetch the current file. That answer is then cached at the edge for the next visitor, so misses are rare and get rarer as a page settles.
Publish a change and the edge copies of anything that changed are invalidated automatically, so the next request pulls the new version instead of serving a stale one for hours. You don't flip a cache-clearing switch — it's just part of what a deploy does.
A CDN isn't a plan you upgrade into here — it's how every site is served, always.
Plenty of companies sell edge delivery as a paid tier, or leave you to wire up an account elsewhere and work out the caching rules yourself. There's nothing here to configure and no setting to turn on — every site, from the very first publish, goes out across the same edge network as every other one. Speed isn't the upgrade; it's the floor.
Worth knowing
No — it's how every site is served by default, included at every price point, not a separate product.
The edge makes a quick round trip back to origin, serves that answer, and caches it for the next request — misses get rarer as a page settles.
Changed files are invalidated at the edge as part of publishing, so the next request after a deploy gets the new version rather than a stale cached one.
Works the same whether you deploy by Git or the CLI. See the full numbers on pricing.