Yes, it can, and by default be through SignalR. The problem is both SignalR has its own limitations as well as web-sockets in general.
I have never seen a SignalR (and recently Blazor) implementation without significant and characteristic issues the moment you actually star to observe end-user errors/issue/anatomies. Either through automated reporting or user feedback. And this is because SignalR is built on .NET and .NET has many different threading issues when you need those thread to be stable and robust (not talking about transit B2B apps)
That version of SignalR you are referring to is from .NET framework and really bolted on. That version of the framework had async/await in ASP.NET also bolted on, and the threads itself use a synchronisation context and locks.
This is mostly no longer the case in modern .NET. SignalR is a core part of the framework and completely rewritten.
In our case, Blazor Server has been very stable for us, also for multiple users.
I have never seen a SignalR (and recently Blazor) implementation without significant and characteristic issues the moment you actually star to observe end-user errors/issue/anatomies. Either through automated reporting or user feedback. And this is because SignalR is built on .NET and .NET has many different threading issues when you need those thread to be stable and robust (not talking about transit B2B apps)
It always happens. Without exception.
You do not have to take my word for it, look at the active, open, and historical issues here: https://github.com/SignalR/SignalR/issues
The issues are plainly fundamental.
It's absurd. And it only survives because it's Microsoft.