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. 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 from the nearest copy
What edge caching absorbs
Cached responses come from the edge instead of round-tripping to one server, so a busy day never piles up anywhere it could bottleneck. If a site ever gets close to its traffic allowance, 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 fetch of the current file, which is then kept near the reader for the next visitor, so misses are rare and get rarer as a page settles.
Publish a change and the copies of anything that changed are refreshed 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.
250 GB a month per site. That is 250,000 MB, so a 2 MB page could be viewed roughly 125,000 times before you would approach it. Go over, and we email you before anything changes; there is no automatic overage charge.
The nearest location fetches the current file, serves it, and keeps a copy for the next request - misses get rarer as a page settles.
Publishing refreshes the copies, so the next request after a deploy gets the new version rather than a stale one.
Works the same whether you deploy by Git or the CLI. See the full numbers on pricing.