CDN Edge Coverage and TTFB: Why Distance Still Slows Your Site Down
The promise of a CDN is seductive and mostly true: put your content on a network of servers around the world, and every visitor gets served from one nearby, so distance stops mattering. Teams add a CDN, see their asset load times drop, and assume the distance problem is solved. Then they check their Time to First Byte and it’s still high — sometimes as high as before. The CDN didn’t fail. It just doesn’t do the thing they assumed it did. Here’s the distinction that clears it up.
Two Different Things Are Traveling to Your Visitor
When a browser loads a page, it fetches two categorically different kinds of content, and a CDN treats them differently:
- Static assets — images, CSS files, JavaScript, fonts. These are identical for every visitor, so a CDN can copy them to edge locations worldwide and serve them from the nearest one. This is what a CDN does brilliantly by default.
- The HTML document — the actual page. On many sites this is generated fresh per request (WordPress querying a database, an app rendering per user), which by default is marked uncacheable — so the CDN passes the request through to your origin server, wherever it is.
Time to First Byte measures that document response — the first thing that happens, before any asset loads. And if the document is coming from a distant origin, your TTFB pays the full distance cost even with a CDN sitting in front of your assets.
Why “I Have a CDN” Doesn’t Fix TTFB
Picture a visitor in Vancouver and an origin server in Frankfurt, with a CDN in between:
| Request | Served from | Distance cost |
|---|---|---|
| Hero image (static) | CDN edge near Vancouver | Low — nearby edge |
| Stylesheet (static) | CDN edge near Vancouver | Low — nearby edge |
| The HTML page (dynamic) | Frankfurt origin | High — transatlantic round trip |
The images and CSS fly in from down the street. The page itself — the thing whose arrival TTFB measures — still crosses an ocean. So the visitor sees fast assets attached to a slow first byte, and the CDN dashboard shows great asset numbers while the field data shows poor TTFB. Both are true. They’re measuring different things.
The Fix: Get the Document to the Edge Too
Solving TTFB means making the document itself servable from the edge, not just the assets. There are two ways there:
- Cache the HTML at the edge. If a page is the same for everyone, the CDN can be configured to cache and serve the document from edge locations too — not just assets. This requires the page to actually be cacheable, which dynamic per-request pages often aren’t without careful configuration.
- Make the site static in the first place. A static-first architecture pre-renders every page to an HTML file at build time. Because there’s no per-request generation, the document is trivially cacheable and can be served from the edge everywhere — the CDN treats your pages exactly like it treats your images. This is the cleanest path to a low TTFB regardless of where the visitor is.
The difference is architectural: a dynamic site fights to make its documents edge-servable; a static site is edge-servable by nature.
Edge Coverage: Not All CDNs Cover Your Audience Equally
There’s a second, subtler factor: where the edge locations actually are. “Global CDN” sounds comprehensive, but what matters is coverage density in your audience’s region. A network with hundreds of points of presence concentrated in the US and Europe may still leave users in a large, less-densely-served market being routed to a far-away edge.
This matters most for geographically large markets. A country spread across thousands of kilometres — with users in major cities and in rural and remote regions — is served well only by a CDN with genuine coverage across that spread, not just one edge in the biggest city. When evaluating a CDN, the useful question isn’t “how many locations does it have globally” but “how close is the nearest edge to my actual visitors.”
A Practical Checklist
- Separate the two numbers. Check asset load times and document TTFB independently — a CDN can make one great while the other stays poor.
- Find out if your HTML is edge-cached or origin-fetched. If every page request reaches your origin, that’s your TTFB ceiling.
- Prefer static or edge-cacheable pages so the document benefits from the edge, not just the assets.
- Evaluate coverage where your users are, not the global location count.
See Where Your TTFB Actually Stands
Our free tool measures your real document TTFB directly — the number a CDN’s asset-only setup won’t fix. If it’s high despite having a CDN, you’ve just found the reason your field-data performance lags your synthetic tests.
Want a Site That’s Fast Everywhere?
We build static-first sites whose pages — not just their assets — are servable from the edge, so TTFB stays low whether a visitor is in a major city or a remote region. If distance is still slowing your document response, that’s exactly the problem we fix.
Published by the Runkexpert Engineering Team. Last updated 2026-07-26.