Skip to main content
Delivery Optimization

Best practices for caching HLS segments on a CDN

HTTP Live Streaming (HLS) was explicitly designed to leverage standard HTTP caching. When deployed successfully, an edge network can absorb 99% of stream traffic, dramatically lowering origin costs while improving playback startup times. However, if headers are misconfigured, viewers may experience freezing video, infinite buffering, or stale live streams.

Updated September 8, 2026 Maintained by M3U8 Free Player Online 8 minute read

Scaling video delivery demands more than just putting a CDN in front of an origin server. HLS relies on dynamic manifests acting as signposts for immutable chunks of video data. Caching them effectively requires distinguishing between content that changes constantly and content that is static forever.

Why HTTP caching matters for video

An average 1080p stream pulls down segments every 2 to 6 seconds. If ten thousand viewers are watching a live event, that equates to thousands of HTTP requests per second hitting the infrastructure. An origin server would buckle under this load without a CDN intercepting requests at edge nodes. Proper caching not only prevents origin collapse but ensures users stream video from the closest geographic node, minimizing packet loss and latency.

The fundamental rule: Playlists vs. Segments

The core philosophy of HLS caching is straightforward: Media segments are immutable and should be cached for as long as possible. Playlists are dynamic and require short-lived or conditional caching.

  • Master Playlists (e.g., master.m3u8): Highly static. Lists available bitrates and audio tracks.
  • Media Playlists (e.g., 720p.m3u8): Dynamic during live events; static for Video on Demand (VOD).
  • Media Segments (e.g., segment_001.ts, .m4s): 100% immutable. Never changes once written.

Caching Master Playlists

The master playlist describes the variant streams available for a piece of content. Because it only points to child media playlists and doesn't change during a typical session, it can be cached aggressively.

Cache-Control: max-age=3600, s-maxage=86400

For VOD workflows, you can safely set the Time-To-Live (TTL) for a master playlist to several days or weeks. For live events, it is generally safe to cache it for hours, as new renditions are rarely added mid-stream.

Caching Media Playlists

Media playlists contain the actual sequence of video segments. Caching rules here depend entirely on whether the stream is VOD or Live.

VOD Playlists

VOD media playlists are static. The list of segments from start to finish is fixed. You can cache these heavily (e.g., max-age=86400). Browsers won't need to request them more than once.

Live Playlists

Live playlists are constantly updated with new segment URLs as the encoder generates them. Caching these for too long causes players to stall because they cannot "see" new segments. Set the TTL to match the segment duration (e.g., if target duration is 4s, max-age=2 or max-age=4).

For live playlists, consider relying on Cache-Control: max-age=1 or even standard ETag/Last-Modified conditional requests to ensure the edge always fetches the freshest manifest from the origin while reducing bandwidth.

Caching Media Segments

Media segments—whether MPEG-TS (.ts) or Fragmented MP4 (.m4s)—are the bulk of your bandwidth. They represent a specific chunk of time in the video timeline. Once encoded and published, a segment never changes. If a segment needs to be updated (e.g., due to a re-encoding error), it should be published under a new filename.

Cache-Control: public, max-age=31536000, immutable
Applying the immutable directive prevents modern browsers from issuing unnecessary If-None-Match revalidation requests when scrubbing back and forth in a video player.

Configure your CDN to cache .ts, .m4s, and .aac files for 1 year (or the maximum allowed by your provider). A high cache hit ratio on segments is the single most critical factor in driving down egress costs.

Advanced CDN Configurations

To maximize CDN offload, engineering teams must look beyond standard HTTP headers. Here are expert-level configurations for HLS caching:

1. Ignore Query Strings for Segments

If your players append tracking parameters or session IDs to segment requests (e.g., segment_001.ts?session=abcd), the CDN will treat each unique query string as a separate cache key. This causes cache misses and overwhelms the origin. Configure the CDN edge to strip or ignore query strings when evaluating the cache key for video segments.

2. Implement Origin Shielding

When thousands of edge nodes globally experience a cache miss for a newly generated live segment simultaneously, they will all request it from your origin (a "thundering herd"). An Origin Shield (or Tiered Caching) adds a mid-tier caching layer. Edge nodes request the segment from the shield, and only the shield asks the origin, collapsing thousands of requests into one.

3. Manage CORS and Vary Headers

Web video players require Access-Control-Allow-Origin headers to fetch segments via JavaScript. If your origin responds with Vary: Origin, the CDN might cache a separate copy of the segment for every referring domain, destroying cache efficiency. Instead, ensure the CDN caches the segment once and dynamically applies the correct CORS headers at the edge.

Troubleshooting Cache Misses

If your origin bandwidth is higher than expected, use cURL to inspect the response headers from your CDN.

curl -I -H "Origin: https://example.com" https://cdn.domain.com/video/segment.ts

Look for headers like X-Cache: HIT or CF-Cache-Status: HIT. If you see MISS repeatedly on the same segment, check for:

  • Inconsistent query strings in the URL.
  • Accidental Set-Cookie headers from the origin (which forces CDNs to bypass the cache).
  • Cache-Control: no-cache or private accidentally applied to segments by an application framework.

Summary

Scaling HLS delivery is a matter of respecting the immutability of segments while carefully timing the expiry of live playlists. By utilizing long TTLs for media chunks, origin shielding for live events, and stripping query parameters from cache keys, broadcasters can achieve 99%+ offload rates—guaranteeing flawless playback even during massive viral spikes.