Request-response is a one-way street
HTTP is built around a strict request-response contract. The client asks; the server answers; the connection closes; everybody goes home. The server cannot speak first, even when it knows something the client desperately needs. Imagine a restaurant where the waiter is forbidden from approaching your table — your food has been ready for ten minutes, but until you flag him down, you do not know.
That model is fine for documents. It is structurally hostile to events. Every "real-time" feature on the modern web — chat, presence, live prices, collaborative cursors, streaming AI tokens — is the same problem in disguise: the server has news, the client has not asked, and waiting for the next request is unacceptable.
The cost of HTTP overhead
Every HTTP request hauls a payload of headers — cookies, auth tokens, user-agent strings, accept-encoding negotiations, content-type, origin. Hundreds of bytes of metadata to ask a question whose answer might be a single integer. For one request a minute, this is invisible. For ten requests a second across a million users, this is millions of dollars in transit and CPU.
Where this quest goes
Track 1 places WebSocket on a map alongside polling, long polling, and Server-Sent Events. By the end of the track you will pick the right approach without ceremony. WebSocket is one tool. It is sometimes the right one. Often it is not.