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. Here is where that time goes.
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 “Share screen”. 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, enter a nickname, 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 | Time | What’s happening |
|---|---|---|
| Load the create page | ~1-3 s | Browser page loads; no auth flow or dashboard |
| Click Create room | ~1 s | One request to the signaling service, then the session page opens |
| Send the invite link | ~5–15 s | This is the human step. Texting beats email beats reading numbers aloud |
| Other person clicks the link | parallel | They’re already in their browser; no install |
| Click Share, pick a surface | ~3–8 s | Browser picker, you choose tab/window/screen |
| WebRTC handshake | ~1–3 s | The two browsers find each other (STUN); media starts flowing |
Total on a good desktop network, with the link going through a chat app: about 25-30 seconds. The exact number depends on the browser, the guest’s device, the network, and how quickly you pick the surface to share.
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, the host can add a password before sharing the link. 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, but expect an extra second or two for that path to negotiate.
- 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. The whole loop should fit comfortably inside the ad break of a YouTube video.