WebSocket vs Polling Visualizer — Free HTML CSS JS Snippet

"WebSockets are more efficient than polling" is a sentence almost every frontend developer has repeated without necessarily having watched the two approaches run side by side long enough to see why. This snippet runs both simultaneously, on the same clock, so the difference in wasted round trips and delivery latency is something you count rather than something you take on faith.

Polling: a real fixed-interval loop, not a one-off animation

The left panel runs startPolling(), which fires an initial runPollCycle() immediately and then repeats it every POLL_INTERVAL (2000ms) using a genuine setInterval — this is not a scripted five-step animation, it keeps running for as long as the page is open, exactly like a real polling client would. Each cycle spawns a request packet that animates from the Client node to the Server node over 700ms using a CSS keyframe animation (travelRight), and the moment it "arrives," a response packet animates back (travelLeft). Whether that response carries new data is decided by Math.random() < 0.28 — a roughly 28% chance per poll — which mimics the real-world situation of polling for updates that do not arrive on every single check.

Why most polling round trips are wasted, made countable

Every completed poll cycle increments the Round Trips counter unconditionally, but only the cycles where hasNewData was false increment the separate Wasted counter, rendered in the response packet as a dim grey dot instead of a green one. Over any reasonably long run, the Wasted count climbs steadily even while nothing meaningful is happening on the server — because the fixed-interval loop has no way to know whether new data exists without asking, so it has to ask on a timer regardless. This is the concrete, countable version of the standard "polling wastes bandwidth and server load on empty checks" claim: watch the Wasted number and the Round Trips number converge toward the same value during a quiet period, meaning nearly every request in that stretch accomplished nothing.

WebSocket: one handshake, animated once, never repeated

The right panel's connectWebSocket() runs exactly once on load. It animates a single green line growing across the client-server track over 600ms — representing the one-time HTTP Upgrade handshake that turns a normal HTTP connection into a persistent WebSocket connection — and then sets wsConnected = true. After that, no more connection-establishing work happens for the rest of the session; the panel tag switches to "connected, idle" and stays that way until an event fires. There is no interval running in the WebSocket panel at all, which is the structural point: a persistent connection means the client is not periodically doing anything just to check in.

Server push: latency measured against polling's worst case, not its best

Clicking "Simulate new event on server" calls simulateServerEvent(), which spawns a single green push packet that travels directly from Server to Client over 700ms with no preceding request packet — the server-initiated push has no round trip to complete, only a one-way delivery. Compare this to polling's worst case: if new data becomes available the instant after a poll just checked and found nothing, that update sits undelivered for up to the full 2000ms interval before the next poll happens to catch it. The WebSocket push in this snippet always delivers within one packet's travel time regardless of when the underlying event occurred, because there is no polling clock gating when the client finds out.

Reading the two Wasted counters together

The WebSocket panel's Wasted stat stays at zero for the entire simulation, and it is not decorative — there is genuinely no code path in simulateServerEvent() or connectWebSocket() that can produce an empty round trip, because the architecture has no round trips at all after the initial handshake. Placed next to polling's climbing Wasted counter over the same simulated time period, the two numbers make the efficiency argument concrete: polling pays a fixed cost on a timer whether or not it has anything to report, while a WebSocket pays a one-time connection cost and then only moves data when there is actually data to move.