Low-Latency HLS (LL-HLS)
Low-latency HLS shortens HLS delivery to roughly 2–5 seconds by splitting segments into smaller parts, keeping HLS compatibility and CDN economics while tightening real time.
What actually changed?
The core idea is sending parts of a segment while it's still being produced, instead of waiting for the whole one — and having the player buffer less. The delivery path is still HLS, so existing CDNs and player support carry over.
How far does latency drop?
Typically to 2–5 seconds. That's inside the range where chat Q&A feels natural, which covers most live commerce — but it can still be too slow for auctions or first-come drops, where order decides the outcome.
What do you check when adopting it?
Whether your encoder can produce short parts, whether your CDN supports the mode, and what latency actually measures in real viewing conditions. Enable the setting without measuring and you get low latency in name only.
Frequently Asked Questions
Q. Why choose LL-HLS over WebRTC?
Cost and stability at scale. WebRTC gets under a second, but resource demand climbs with every viewer. Reserving WebRTC for the broadcasts where real time is decisive and running LL-HLS otherwise is the common split.
Q. Can't you just shorten segments in normal HLS?
Shortening alone raises request volume and the risk of stalls. LL-HLS defines partial delivery and player behavior together, so imitating it with one setting produces a different result.
Q. Does latency differ per viewer?
Yes — by network, device, and player implementation. That's why first-come rewards and bids should be judged on the order the server received them, not on what each screen showed.
Related terms
Learn more
Last updated