Understanding HLS Latency (and How to Reduce It)
Why HLS Has Built-in Delay
HLS packages media into segments. A segment usually must be complete before viewers can fetch it, and players buffer multiple segments. That architecture is great for scale and reliability — and it adds seconds of delay compared with real-time protocols.
What Adds Up to Total Latency
- Encoding / packaging time.
- Segment duration (longer segments = more delay).
- Playlist refresh interval.
- CDN/origin propagation.
- Player buffer target.
Classic HLS vs LL-HLS
| Mode | Typical latency | How |
|---|---|---|
| Classic HLS | ~15–30s | Full segments + conservative buffering |
| Tuned HLS | ~6–12s | Shorter segments, leaner buffer |
| LL-HLS | ~2–5s | Partial segments, blocking playlist reload, etc. |
Practical Ways to Reduce Latency
- Use shorter target durations (with CDN/player support).
- Avoid oversized player buffers for live.
- Enable LL-HLS if your packager and players support it.
- Keep origin close / CDN well configured.
- For true interaction, consider WebRTC instead (HLS vs WebRTC).
Trade-offs
Lower latency can mean more requests, less error tolerance, and harder operations. Not every product needs sub-5s delay. Sports betting and chat-interactive shows care more than on-demand movies.
Frequently Asked Questions
Is 20 seconds normal for HLS?
Yes for classic setups.
Can HLS match phone-call latency?
Not usually — use WebRTC for that class of delay.
Does shorter segment length always help?
It helps, but increases overhead and can hurt efficiency.
How do I measure latency?
Compare wall-clock event time to player playhead for live.