Standard HLS has ~20-30 sec end-to-end latency. Low-Latency HLS (LL-HLS), introduced by Apple in 2019, brings this down to 2-5 sec by serving sub-second 'partial segments' as soon as they're encoded — without breaking compatibility with regular HLS clients.
Why standard HLS is slow
HLS requires a complete 6-second segment to be encoded, packaged, uploaded, and indexed before the client can fetch it. With 3-segment buffer at the player, you're 18-24 sec behind live. Worse on bad networks.
Partial segment trick
LL-HLS splits each 6-sec segment into 12 partial segments of 500ms each. The server publishes each partial as soon as it's ready. The client fetches partials in real time, only waits for the next chunk it actually needs.
Blocking playlist reload
Standard HLS clients poll the playlist every few seconds. LL-HLS uses HTTP/2 server-push or 'blocking reload' (long-polling) so the server holds the request until the next partial is ready, then responds immediately. Eliminates polling delay.
HTTP/2 push and preload hints
The server sends EXT-X-PRELOAD-HINT in the playlist telling the client to start fetching the next partial before its URL is even known. Combined with HTTP/2 priority, this cuts another RTT.
End-to-end latency budget
| Component | Standard HLS | LL-HLS |
|---|---|---|
| Encoder→origin | 6 s | 0.5 s |
| Origin→CDN | 1-2 s | ~0.1 s |
| Player buffer | 18 s | 2 s |
| Total | 25-30 s | ~2.5 s |