A familiar conversation: “Can you take a look at this for me?” “Sure, Zoom?” Then come the small delays: “Do you have it installed?”, “I need to sign in”, “is your mic working?”, and the original question starts to drift.
The whole point of showing someone your screen is to skip the typing. So a fair test for any screen-share tool is: how long between the decision to share and the other person actually seeing your screen?
Linkside is built around that test. On desktop Chrome or Edge, with a normal connection and a chat app already open, the target is about 30 seconds. This is a design target, not a measured benchmark or a guaranteed connection time. Here is what the flow involves.
The flow in four steps
- Open linkside.io/app/create. The page loads in your browser. There is no signup, no email field, no dashboard to get through.
- Click “Create room”. Linkside creates the room through the signaling service and sends you straight to the session page. There is no intermediate setup page.
- Copy the invite link. It is already in the room header. Send it however you talk to the other person: text, chat, email, or a voice call if that is all you have.
- Click “Start sharing”. Your browser shows its own picker for which tab, window, or screen you want to share. Pick one. Done.
The guest’s path is short too: open the link, keep or change the generated nickname, select Join room, and wait for you to start sharing. If the room has a password or waiting room enabled, they handle that before joining.
Where the time actually goes
The 30-second target depends less on server time than on human time: finding the link, sending it, clicking the right window in the browser picker. Linkside keeps the product-controlled steps small:
| Step | What affects the time |
|---|---|
| Load the create page | Browser startup, page delivery, and the network |
| Select Create room | A request to the signaling service |
| Send the invite link | Finding the trusted conversation and pasting the link |
| Guest selects Join room | Opening the invite and any password or waiting-room step |
| Select Start sharing and a surface | Browser picker and any operating-system permission |
| Wait for the first frame | ICE checks, encryption setup, and possibly relay fallback |
We have not measured a representative end-to-end timing distribution. Time from opening the create page to the first frame on the guest’s device if you want to test the target on your own setup.
Why it stays private
“Fast” and “private” can pull against each other. A signup wall slows people down. A link is fast, but anyone with the URL can try to join. Linkside keeps the fast path simple while still avoiding the heavy parts of meeting software:
- The link is the default access control. A room link is enough to reach the join flow unless you enable a password or waiting room. Treat the link the way you’d treat a credit card number: send it through a channel you trust.
- Rooms do not persist. Rooms disappear when the session ends. Inactive rooms move through a short cleanup lifecycle and are then deleted.
- The stream is peer-to-peer first. Linkside prefers a direct WebRTC connection between the browsers. The signaling service helps them find each other; it does not receive your screen content.
- Media is encrypted in transit. WebRTC uses DTLS-SRTP for media. When a direct connection is not possible, such as on some restrictive networks or double-NAT setups, Linkside can fall back to an encrypted TURN relay. The relay forwards encrypted media packets; it does not decrypt the screen share.
If you want a stronger gate, a licensed host can set a room password before creating the room. The free waiting room is another option for approving each guest. That costs a few extra seconds, but it is the right choice when the invite might pass through a noisy channel.
What slows people down (and what to do about it)
The 30-second target assumes a desktop browser, a current device, and a working network. The honest list of things that push it higher:
- First-time guests. They click the link, see an unfamiliar page, and pause for a second before entering a nickname. If they unmute, the browser may also ask for microphone permission.
- Mobile browsers. Linkside’s recommended host experience is desktop Chrome or Edge. Mobile browsers are typically guest-only because screen sharing from the browser depends on
getDisplayMedia, and support is more limited than desktop. MDN keeps a current compatibility table. - Restrictive networks. Hotel Wi-Fi, corporate VPNs, and double-NATs sometimes block direct peer-to-peer connections. Linkside falls back to the encrypted relay automatically, after a connection failure and a four-second recovery delay, subject to trial eligibility and relay availability. This can take longer than the target.
- OS permission delays. On macOS, the first screen share may trigger a system Screen Recording permission prompt for the browser, which sends you into System Settings. That is outside Linkside’s control and can turn a 30-second setup into a minute or more the first time.
The practical fix is simple: host from desktop Chrome or Edge, send the room link through the fastest channel you both already use, and expect the first screen-share permission on a new computer to take longer.
When 30 seconds matters
The useful part is not claiming a stopwatch record. It is that the fast path is the default path. There is no signup wall, no download, and no meeting dashboard before the room exists. The slowest part is usually deciding where to send the link.
If you want to time it yourself, create a room, text the URL to your own phone, and click it from there. Measure through the first frame on the guest device, including any permission or relay delay.