WebSockets Explained: When Real-Time Beats Polling, SSE and Webhooks

Chat, live dashboards, collaborative editing, trading screens and task notifications all need the same thing: the server must tell the client about a change the moment it happens. Ordinary HTTP only answers when the client asks, so teams fill the gap with polling, which wastes requests and still arrives late. WebSockets solve the problem, and they bring their own: thousands of open connections to scale, mobile devices that drop them, and security checks that browsers do not do for you.

WebSockets are the right choice when both the client and the server need to send frequent updates with low delay, while server-sent events suit one-way streams to browsers, and webhooks suit notifications between servers.

This article explains how WebSockets work, how they compare with polling, server-sent events and webhooks, what it takes to run them in production, how to secure them and what a real migration looked like. It does not cover WebRTC or video streaming.

Key takeaways

• A WebSocket connection starts as an HTTP request that is upgraded, then stays open for two-way messages in both directions.
• Use WebSockets for frequent, two-way, low-latency updates. Use server-sent events for one-way updates to browsers, and webhooks for server-to-server events.
• Every open connection holds server memory, so scaling means planning connection counts, load balancer timeouts and message fan-out across servers.
• Clients must reconnect automatically and recover messages they missed while disconnected.
• Browsers do not apply the same-origin policy to WebSockets, so the server must check the Origin header and authenticate during the handshake.
• In a delivered project, replacing a PHP WebSocket server with a Node.js layer removed a bottleneck for a franchise task platform, and task completion rose about 17%.

How a WebSocket connection works

1. The client sends an HTTP request with an upgrade header. It asks the server to switch the connection to the WebSocket protocol, using a ws:// or, in production, a wss:// address.
2. The server agrees. It replies with status 101 Switching Protocols, and the connection is no longer ordinary HTTP.
3. Both sides send messages freely. Messages travel as small frames in either direction, without new headers or new connections.
4. Either side can close the connection with a close code, such as 1000 for a normal closure.

The protocol is defined in RFC 6455, published in 2011, and every modern browser, mobile platform and server language supports it.

WebSockets compared with polling, SSE and webhooks

When to choose which

• Choose WebSockets when clients send frequent messages as well as receiving them, such as chat, collaborative editing, live cursors or mobile apps that confirm tasks in real time.
• Choose server-sent events when only the server sends updates to the browser. SSE runs over normal HTTP and reconnects on its own. Under HTTP/1.1, browsers allow only six SSE connections per domain across all tabs, according to MDN, while HTTP/2 raises the limit to about 100 streams by default.
• Choose webhooks when one server needs to tell another server about an event. Browsers and mobile apps cannot receive webhooks. Our guide to webhooks covers that side.
• Keep polling when updates are rare, a delay of a minute is acceptable and simplicity matters most.

Running WebSockets in production

Plan for open connections

Each connected client holds a connection, memory and a file handle on the server, even when nothing is happening. Event-driven runtimes such as Node.js, Go and Elixir handle many thousands of idle connections per server well. Runtimes built around one process or thread per request struggle, which is often the first bottleneck teams hit.

Fan out messages across servers

With several servers, a message for a user may arrive at a server that does not hold that user's connection. A publish-and-subscribe layer, such as Redis, NATS or a managed service, passes each message to every server, and each server delivers it to its own connected clients.

Configure load balancers and proxies

• Forward the Upgrade and Connection headers, which many proxies drop by default.
• Raise idle timeouts. AWS Application Load Balancers close idle connections after 60 seconds by default, and nginx closes proxied connections after 60 seconds without data.
• Send heartbeats, ping and pong frames every 20–30 seconds, so idle connections stay open and dead ones are detected.

Reconnect and recover

Connections drop when phones change networks, laptops sleep or servers restart. Clients should reconnect automatically with exponential backoff and random jitter, so thousands of clients do not reconnect in the same second after a deployment. On reconnect, the client sends the ID of the last message it received, and the server sends what it missed, or the client reloads current state through a normal API call.

Remember mobile limits

Mobile operating systems suspend apps in the background and close their connections. Use WebSockets while the app is open, and push notifications through Apple Push Notification service and Firebase Cloud Messaging for anything the user must see while the app is closed.

Deploy without dropping everyone

A deployment that restarts servers disconnects every client at once. Drain servers gradually, tell clients to reconnect elsewhere before shutting down and keep message formats backward compatible, since old clients stay connected after new servers go live.

WebSocket security

The OWASP WebSocket Security Cheat Sheet covers the details. The essentials:

• Always use wss://. Encrypted connections protect messages and avoid mixed-content errors on HTTPS pages.
• Check the Origin header. Browsers send cookies with WebSocket handshakes to any site, and they do not apply the same-origin policy. Without an Origin check, a malicious page can open a connection in a logged-in user's name, an attack known as cross-site WebSocket hijacking.
• Authenticate at the handshake. Use a short-lived token, check permissions when the connection opens and again for sensitive messages, and close connections when a session ends or permissions change.
• Validate every message. Treat incoming messages as untrusted input, with a schema, size limits and rate limits per connection.
• Never trust a connection address from a URL parameter. In early 2026, the OpenClaw AI assistant was found to accept a WebSocket gateway address from a link without validation. As SonicWall's analysis describes, a victim who clicked a crafted link sent their authentication token to the attacker's server during the handshake, which could lead to remote code execution. The flaw, CVE-2026-25253, rated 8.8 out of 10, was fixed in version 2026.1.29, and later versions added origin validation.

A real migration: real-time tasks for a franchise network

A US quick-service restaurant franchise network, working with .wrk under NDA, runs its daily operations on a task platform. Administrators create task templates, network managers adapt and assign them, and staff complete tasks on mobile with notifications in real time, alongside shift scheduling and inventory.

The real-time layer had become the bottleneck. A PHP WebSocket server struggled under mobile load, and synchronization depended on Simperium, a third-party sync service.

• New real-time layer. .wrk replaced the PHP WebSocket server with a Node.js layer that makes fewer database round trips and holds more connections.
• In-house sync. Synchronization moved to the team's own WebSocket server, removing the dependency on the third-party service.
• Mobile and templates. The Swift app received real-time task notifications, in-app purchases and a flexible template hierarchy that matches how franchises run shifts.

The work was delivered in a four-month window. Task completion across the network improved by about 17%, and the gains held over time. Read the franchise operations case study.

Common WebSocket errors and what they mean