How We Made Screen Sharing Four Times Faster

Screen sharing latency is one of those problems you only notice when it is bad. A presenter clicks to the next slide, and the room watching the shared screen sees it a beat and a half later. Not broken, exactly, just off. Over a few releases, we took a hard look at where that delay was coming from in Cliqer's screen sharing and brought standing latency down from over two seconds to around half a second, a roughly four times improvement. This is the plain-language version of how.

We are not going to hide code names or pretend there was one silver bullet. There were three separate fixes, each aimed at a different place the delay was hiding, and they stacked.

Why screen sharing lags in the first place

When you share a screen, three things have to happen before a viewer sees a frame: your machine has to capture it, encode it into video, and send it. Any one of those steps can quietly add delay, and the effect compounds. A slow encoder plus a cautious buffer plus a wait for the next full frame update can easily add up to two or three seconds, even on a fast connection.

The tricky part is that none of those individually look broken. Capture works. Encoding works. The stream arrives. It is just late, and "just late" is hard to diagnose without measuring each stage on its own.

Fix one: stop encoding the same picture twice

The first source of delay was wasted work. Screen and NDI shares were being encoded twice behind the scenes, once for each output path, and a still slide was being re-encoded continuously even though nothing on screen had changed. That doubled the load on the encoder for no visual benefit, and it meant the pipeline was always busier than it needed to be, which pushes every frame further back in the queue.

Removing the duplicate encoding pass, and skipping re-encoding when the picture has not changed, freed up meaningful CPU headroom immediately. Less contention on the encoder means every frame that does need encoding gets processed sooner.

Fix two: tighten the buffer without losing resilience

The second source was the buffer sitting between the encoder and the network, the part that exists to absorb brief network hiccups so a stutter on the wire does not turn into a stutter on screen. Buffers like this are a trade-off by nature: too small and a minor blip causes visible glitching, too generous and you are adding delay to every single frame just in case something goes wrong later.

The buffer had been sized generously, which meant it was adding delay on every frame in the common case to protect against a rare case. Tightening it cut the worst-case lag from a few seconds down to well under one, while still riding out brief network hiccups without visible glitching. This is the kind of fix that looks like a small number change in a diff and is really a judgment call about which failure mode you would rather have.

Fix three: stop making new viewers wait for the next keyframe

The third fix targeted a specific, painful moment: what happens when someone joins a share that is already running. Video compression works by sending full frames, called keyframes, only occasionally, with cheaper "what changed since last time" frames in between. A viewer who joins mid-stream cannot make sense of those in-between frames until they receive a keyframe to anchor on, and previously that meant waiting for the next scheduled one, up to three seconds away.

The fix was to keep the most recent keyframe cached and hand it to a new subscriber the moment they join, instead of making them wait for the next one on the schedule. Combined with the interval-based frame timing described in our screen sharing documentation, new viewers now see video within milliseconds of joining a share instead of waiting up to three seconds for the next keyframe.

Stack all three fixes together, and the two-plus second standing latency most people never quite trusted became about half a second, roughly a four times improvement, while using less CPU and less bandwidth than before. Full frame rate matters here too: program video had quietly been capped at around 31 frames per second regardless of source, so a 60fps share now looks as smooth on the receiving end as it does on the presenter's own screen.

What this means if you are presenting right now

None of this requires you to change a setting. It ships in the desktop app's screen sharing pipeline, and it applies whether you are sharing a single monitor to a small room or running a full Studio production with multiple sources, including vMix workflows that lean on a fast, predictable feed. If you want to tune quality against bandwidth on top of the latency work, the screen sharing settings cover codec choice, resolution and bitrate, and desktop 2.2.0 added the option to include system or microphone audio in a share directly.

For hybrid setups where the delay was most visible, especially a remote speaker watching a shared screen and reacting live, this pairs with our guide on fixing screen sharing latency in hybrid meetings and our explainer on why clicker latency in milliseconds matters just as much on the control side as it does on the video side.

Where the rest of the latency goes

Screen sharing is one leg of the journey. The other is the network path itself: whether the connection between presenter and viewer is direct or relayed, and what happens on networks that block direct peer-to-peer traffic. We cover that side, including why it can never be fully eliminated on some networks, in TURN servers explained and is WebRTC secure.

FAQ

Try it yourself

The fastest way to feel the difference is to share a screen and watch someone else's face when they see it. Download Cliqer free and try a screen share on your own setup, or see the full feature set on screen sharing and compare plans on pricing.