A WebSocket starts as an ordinary HTTP request and then upgrades into a persistent connection. That suits work where both sides talk often, such as chat, collaborative editing, multiplayer tools and live market data, because neither side has to keep asking whether anything is new.
The cost is state. Each open connection holds resources on a server, load balancers and proxies must be configured to allow long-lived connections, and the application has to handle reconnecting and catching up on whatever it missed. If the browser mostly listens, server-sent events are simpler, and many teams reach for a WebSocket when they do not need one.