About WebSockets Basics

Lifecycle, browser API, when to use, production gotchas. Part of the DevTools Surf developer suite. Browse more tools in the Info / Guides collection.

Use Cases

• Frontend devs building real-time chat or notification features
• Game developers implementing low-latency multiplayer communication
• FinTech engineers streaming live price feeds to trading dashboards
• IoT developers pushing sensor data to web dashboards in real time

Tips

• Study the connection lifecycle before implementing reconnection logic
• Check the production gotchas for load balancer and proxy pitfalls
• Use the 'when to use' decision chart vs SSE and polling

Fun Facts

• The WebSocket protocol (RFC 6455) was standardized in December 2011, ending years of hacky workarounds like long-polling and hidden iframes.
• A WebSocket connection starts as an HTTP request with an Upgrade header — the server responds with status 101 (Switching Protocols) to complete the handshake.
• WebSocket frames have only 2-14 bytes of overhead per message, compared to hundreds of bytes for HTTP headers, making them ideal for high-frequency data.

FAQ

When should I use WebSockets?

Real-time bidirectional communication — chat, multiplayer games, live dashboards, collaborative editing. Not for request-response (use HTTP/2 with keep-alive).

How does the lifecycle work?

HTTP request with Upgrade header. Server accepts with 101 Switching Protocols. Now it's a raw TCP-like duplex channel. Messages can flow either direction anytime.

What breaks in production?

Load balancer misconfigured for long-lived connections, firewalls idling out connections, and scale: each WS connection holds a process/thread/memory. Plan capacity per connection.

Alternatives?

Server-Sent Events for server→client only (simpler). WebTransport (HTTP/3 based) for modern use. MQTT for IoT. Pick the simplest that fits the use case.