Preload hint replaces the discarded HTTP/2 server-push mechanism in LL-HLS. The packager, knowing what the next partial segment's URL will be (deterministic from segment template), writes a #EXT-X-PRELOAD-HINT tag at the end of the current media playlist pointing to that URL. The player sees the hint, sends a GET to that URL, and the origin holds the response open until the partial actually exists, then streams it back via chunked transfer.
The mechanism turns the round-trip cost of "discover the partial exists → fetch it" into "fetch it preemptively → wait for it to exist". On a typical CDN path the savings are 100–300 ms per partial fetch, which over a 5-partial second of media translates to 0.5–1.5 s of glass-to-glass latency saved versus a naive LL-HLS implementation.
Preload hints work best when the CDN supports request coalescing — multiple players hinting the same URL must share one origin connection rather than each opening their own. Without coalescing, a popular live stream can hammer the origin with thousands of identical hint requests, all waiting for the same partial. Apple's reference implementation, Akamai's LL-HLS support, CloudFront, and Cloudflare all support coalescing as of 2025.
The book · Volume 2 of 7
Video Streaming: A Complete Guide to Video Delivery: From Network Protocols and Transport to Ingest, HLS, and MPEG-DASH
A preload hint lets an LL-HLS player request the next partial segment before it exists, and a CDN that does not hold that request open quietly adds latency. This volume covers the preload hint in detail as part of LL-HLS, with blocking playlist reloads, partial segments, CMAF packaging and the glass-to-glass latency budget. Written by Nikolay Sapunov, CEO at Fora Soft.
LL-HLS latency creeping up because preload hints are not honoured end to end?
We will trace one LL-HLS request path from packager to player and send back a preload hint audit with the CDN and origin settings that cut the lost time. 250+ video products shipped since 2005.
