LL-HLS, published in the HLS Authoring Specification revision 2020 and refined every year since (current revision 2025-09), keeps HLS's HTTP-based model and adds four mechanisms to chase latency. Partial segments (EXT-X-PART) split a full segment into ~200 ms pieces so the player can fetch in-progress media. Preload hints (EXT-X-PRELOAD-HINT) tell the player the URL of the next part before it exists, so the request can be in flight when the segment lands. Blocking playlist reload lets the player send a _HLS_msn= query that waits server-side for the next manifest version. Rendition reports let the player anticipate ABR switches without parsing every variant playlist.
When all four work together, end-to-end latency drops to a fraction of standard HLS. A typical LL-HLS deployment runs 1-second segments with 200-ms partials, hits 2–4 s glass-to-glass over a CDN that supports HTTP/2 chunked transfer, and remains backward-compatible with non-LL-HLS players (which simply ignore the new tags and pull at HLS's normal latency).
The catch is operational. LL-HLS requires the entire chain — packager, origin, every CDN POP, and the player — to support partial-segment fetching, chunked transfer, and request coalescing. A misconfigured CDN that serves each partial as a separate cache entry kills the gains. Apple's reference implementation is the canonical test target; popular players (hls.js since 1.1, Shaka since 4.0, AVPlayer natively on iOS 14+) all support LL-HLS as of 2026.
