
Screen sharing latency shows up as a specific, annoying pattern: the presenter says something, gestures at a point on the slide, and the audience sees the gesture land on the wrong content because the video is still a beat behind the audio. It is rarely one single cause. It is usually two or three small things stacking up.
- Latency usually comes from encoding, network path, keyframe waits or a resolution mismatch, not one single cause.
- Change one variable at a time, codec then resolution then bitrate, to find what actually fixes it.
- A relayed connection through a firewall adds latency but keeps the session working rather than stalling it.
Where the delay actually comes from
Screen sharing latency in a hybrid meeting or event comes from four places, roughly in order of how often each one is the actual culprit:
Encoding overhead
Turning a screen capture into a compressed video stream takes real processing time, more on some codecs than others.
Network path
A direct connection is fast; a relayed connection through a fallback server adds a hop, and a congested network adds queuing delay on top of that.
Keyframe waits
Some systems only send a full frame periodically, so a viewer joining mid-stream can be looking at stale or frozen video for a few seconds until the next one arrives.
Resolution and bitrate mismatch
Pushing 4K video down a connection that can barely sustain 1080p forces frames to queue or drop.
Fix 1: pick the right codec for the situation
Cliqer's screen sharing supports VP8, VP9, H.264/AVC and AV1, and the choice matters more than people expect:
| Codec | Strength | Trade-off |
|---|---|---|
| VP8 | Maximum compatibility, works everywhere | Larger file size for the same quality |
| VP9 | About 20% better compression than VP8 at the same quality | Slightly more encoding overhead |
| H.264/AVC | Hardware-accelerated on most devices | Best pick for lower CPU use and corporate networks |
| AV1 | Best compression, ideal on limited bandwidth | Needs hardware encoder support, falls back automatically if unavailable |
If viewers are on corporate networks or older devices, H.264 is usually the safest default because it is hardware-accelerated almost everywhere. If bandwidth is the binding constraint and the presenting machine supports it, AV1 gives the most headroom.

Fix 2: match resolution and bitrate to the actual connection
Higher resolution is not free. Each preset has a realistic bandwidth range:
| Preset | Resolution | Recommended bandwidth |
|---|---|---|
| HD | 1280x720 | 1 to 3 Mbps |
| Full HD | 1920x1080 | 3 to 6 Mbps |
| 2K | 2560x1440 | 6 to 10 Mbps |
| 4K | 3840x2160 | 10 to 20 Mbps |
If a presenter's upload speed cannot comfortably clear the bandwidth for their chosen resolution, that is the fix, not a mysterious network issue. Dropping from 1080p to 720p, or from Auto bitrate to a custom 2 to 4 Mbps setting, resolves stutter far more often than people expect from something that feels like a downgrade.
Fix 3: understand what keyframes are doing to your join times
A screen share that looks frozen for a second or two right when someone joins is usually a keyframe problem, not a connection problem. Cliqer's approach sends a keyframe on the very first frame and then avoids forced periodic keyframes, while giving new subscribers a cached keyframe immediately on join so they see video within milliseconds instead of waiting for the next scheduled one. If you are evaluating other tools, ask specifically how they handle this, because the difference between "instant" and "up to three seconds" on every late join is entirely a keyframe strategy decision, not a networking limitation.
Fix 4: get past restrictive firewalls without adding lag
Corporate and conference-venue networks are a common latency culprit, not because the internet connection is slow but because a direct peer-to-peer path is blocked and every packet has to detour through a relay. Cliqer's connections attempt a direct path first over STUN and fall back to a TURN relay automatically when that is blocked, including relaying over port 443 on networks that only allow standard web ports. That fallback adds some latency compared to a direct connection, but it is what keeps the session working at all rather than stalling entirely. Corporate firewalls and presentation tools and TURN servers explained go deeper on how that routing decision gets made.

A field-tested troubleshooting order
When latency shows up live, work through causes in this order rather than guessing:
- Lower resolution first, try 720p instead of 1080p or higher.
- Lower bitrate, a custom 2 to 4 Mbps setting is a reasonable test value.
- Switch codec to H.264, which usually has the best hardware support on the presenting machine.
- Check whether the network is forcing a relayed connection, which points at a firewall issue rather than a screen sharing setting.
This same order applies whether the root cause is screen sharing specifically or a clicker feeling sluggish; see clicker latency in milliseconds for the equivalent breakdown on the control side rather than the video side. If your current tool feels slow by default rather than only under bad network conditions, screen sharing four times faster is worth reading for what a faster baseline actually looks like.
We have chased this exact class of problem at the infrastructure level too. Why we moved off Cloudflare is the story of tracking down connections that dropped for reasons that had nothing to do with any single user's network, and it is a useful read if you have ever been told a dropped connection was "just your Wi-Fi" and were not convinced.
Corporate firewalls and presentation tools
Why corporate networks block direct connections and how relaying gets you through.
FAQ
Usually because a direct peer-to-peer connection is blocked and traffic is being relayed instead, adding a network hop. Corporate firewalls, hotel Wi-Fi and some conference venues are the most common cause. This is a routing issue, not a video quality issue, though lowering resolution or bitrate still helps mask it.
No. Match resolution to the connection's actual sustainable bandwidth. A 4K share over a connection that can only reliably carry 1080p causes more stutter than a clean 1080p or even 720p stream.
They are separate systems: slide control runs over a low-latency data channel, while screen sharing is a video stream, so a laggy video feed does not necessarily mean slide clicks are delayed. If clicks specifically feel slow, that is a different issue; see clicker latency in milliseconds.
Try lowering resolution and bitrate first. If that fixes it, the connection was the bottleneck. If stutter persists at the lowest settings, it is more likely a CPU or hardware encoding limitation on the presenting machine.
Diagnose it on your own setup
Start with Cliqer's free plan to test screen sharing on your actual network before an event depends on it, and check the video encoding options in the docs for the full settings reference. For persistent latency on locked-down networks, pricing plans all include the same relay fallback, so upgrading is about capacity, not about fixing latency on its own.
Co-Presenting Without Chaos: Smooth Handoffs Between Speakers
Co-presenting tips for clean handoffs: agree cues in advance and pass slide control without dead air or fumbling.
Stream Deck for Presentations: Build a One-Button Show Controller
Turn an Elgato Stream Deck into a one-button show controller for slides, timers and callers, over USB or the plugin.
Run your next show with Cliqer
Keep reading
More hybrid events for your next show


Bringing Remote Guests On Stage with Live Callers

Multi-Host Presentations: One Deck, Several Locations
Get the next guide before your next show
Practical guides for presenters, AV crews and event teams, plus the Cliqer releases that matter. No spam, one click to leave.
