There is no proper answer per se: browser vendors have different rationales for why certain activities would and would not show "loading" states: A good rundown here.
In general, ajax-like requests (things asynchronous to actual full page loads) should probably NOT show loading indicators by default, as busy states indicate to users that the browser is slow/busy, and we use ajax requests for all sorts of background tasks. There are, of course, times when a developer would want to show these indicators (form submission, single page apps that download subsequent pages via ajax: times when we want to convey to the user that something major is happening and that they SHOULD wait for it to complete) but we don't have a lot of control over forcing that to happen when it comes to async requests. The only real way to "fake" it on some browsers is to load content in an iframe: some modern browsers do trigger the "busy" state in that case.
With Websockets, most vendors have, probably quite reasonably, applied the same logic as ajax requests: there are a lot of operations you'd want to do with websockets that can happen without a user actually initiating them directly, so they shouldn't trigger that "browser is seriously busy, hold on a second" feel. And, like with ajax, there's sadly no api I know of for countermanding that design decision.
The iframe solution is limited: it works in some browsers but not all (notably, it's ignored in all major mobile browsers). And doing it crudely (i.e. creating a hidden iframe for when you want it to trigger the load indicators and removing it when you want to cancel them) has costs: you basically need to hit a resource that is designed to "stall" (like a php page that just runs sleep(10000) and so keeps the connection open). That's both weighty (extra http request just to trigger an effect) and also ties up some server with keeping open connections that are essentially not doing anything. That probably won't scale, particularly if that server is the same one hosting your app.
You're probably instead stuck with coding a custom loading indicator (spinner, fake progress bar fixed at the top of the screen). It's not satisfying, but it's the only thing guaranteed to communicate some of what you want to users. I have a solution for jQuery's ajax that exploits the iframe approach (Noisy JSON) that you could potentially reproduce as a plugin for socket.io, but if you're using websockets, that basically means falling back to ajax-style communication for requests. And you're still out of luck on Safari, mobile, and newer IEs.
