Global CDN
Your files sit behind Cloudflare's edge network, so a visitor's browser talks to whichever location is nearest to them — not to one server clear across the map.
Every site here sits behind a content delivery network — Cloudflare's, specifically — 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 Cloudflare edge 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
Files cached at the edge skip the two things that usually slow a page down. Standard on every static hosting plan, and it works the same after a restore from daily backups.
There's no server process to spin up before it can answer. A cached file is simply handed over.
Nothing gets assembled per request. What's cached is exactly what gets served.
Static output doesn't vary by server load or by which location picked up the request.
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 hosts sell edge caching as a paid tier, or leave you to wire up your own account elsewhere and figure out the caching rules yourself. There's no separate product to configure and no setting to turn on — every site, from the first deploy, is served through the same edge network as every other one, because building a static host that skipped this would genuinely be more work, not less.
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.