CDN Edge Caching, Explained: Why Some Streams Start Instantly and Others Don't
The difference between a video that plays in half a second and one that buffers for ten often comes down to a single caching decision made thousands of kilometers away.
Two streaming sites, same video resolution, same evening, same Wi-Fi. One starts in half a second. The other spins for eight. Viewers blame their internet. Nine times out of ten, the real culprit is geography — specifically, whether the video file is sitting in a cache twenty kilometers away or being hauled across an ocean on every single play.
The Physics of a Play Button
When you press play, your device requests a playlist file, then a chain of video segments. Each request travels from your phone to a server and back. If that server sits in a Virginia data center and you’re on a sofa in Chiang Mai, every round trip costs 180–250 milliseconds before a single byte of video moves. Buffer three segments at that distance and you’ve burned a second on physics alone.
A content delivery network fixes this by caching copies of the video at “edge” points of presence — small server clusters inside ISP networks and regional hubs. With a Bangkok edge node, that same round trip drops to 5–15 milliseconds. That’s the entire trick: closer storage, shorter physics.
Cache Hit vs. Cache Miss: The Two Kinds of Stream
Here’s where it gets interesting. An edge node only helps if the segment you want is already sitting there.
Viewer request ──► Edge node (Bangkok)
│
┌────────────┴────────────┐
│ Cache HIT │ Cache MISS
▼ ▼
Serve instantly (~10 ms) Fetch from origin (~200 ms+)
then cache for next viewer
Popular content on a healthy CDN lives permanently at the edge — the first viewer of the day pays the origin fetch, everyone after them gets the cached copy. Obscure content is the opposite: you’re always the “first viewer,” so you eat the full trans-Pacific fetch every time.
This explains a pattern we see constantly in testing: a site’s homepage hero content plays instantly while a three-year-old catalog title buffers like it’s being faxed. Same site, same plan, completely different caching reality. We log hit/miss behavior in our streaming infrastructure notes because it’s one of the most honest signals of how much a platform actually invests in delivery.
What Separates Good CDN Strategy from Bad
Peering, not just presence. A CDN can claim “a node in Thailand” while its traffic still routes through Singapore because it lacks peering agreements with local ISPs. True’s network talking directly to an edge cache is a different experience than bouncing through three transit providers to reach it.
Playlist vs. segment caching. Clever setups cache video segments aggressively but fetch playlists fresh — necessary for live streams, pointless latency for static VOD where the playlist never changes.
TTL tuning. Cache time-to-live is a balancing act: too short and the edge never warms up, too long and updated content (fixed encodes, corrected subtitles) serves stale. Good ops teams set different TTLs per content class; lazy ones set one number globally.
What You Can Do as a Viewer
- Slow start, smooth afterwards? That’s one cache miss at the beginning, then warmup — normal on unpopular titles.
- Consistently slow at peak hours only? The CDN edge is congested or under-peered — a site problem, not yours.
- Fast on Wi-Fi, slow on mobile data (or vice versa)? Different ISP peering paths. The site has uneven coverage across carriers.
Bottom Line
“Fast streaming” is mostly a logistics story — content staged near viewers, agreements with local networks, and caches kept warm. Sites that invest in it feel instant. Sites that cheap out make your perfectly good internet look bad, and they’ll never put that in the FAQ.