I have a Blazor Server application running on an IIS server. I didn't realize that I needed to enable WebSockets in IIS, so my application had been running using Long Polling instead of WebSockets for its SignalR connection.
The application runs fine for the most part, but if I rapidly open a lot of links in new tabs, the first several tabs load the page without a problem, but then the rest of the tabs partially load the page and the tab's "spinning" icon stays forever. It doesn't seem like each subsequent tab loads slower; instead the first several tabs load quickly, and then the remaining tabs never finish loading.
Once I enabled WebSockets, I don't seem to have that problem anymore (or at least the problem doesn't happen with 20 or so tabs).
What would have caused the last several tabs to never fully load when I was using Long Polling, and how did using WebSockets apparently fix that problem? I understand that WebSockets is more efficient, but I would think that Long Polling would just be slower as opposed to never finishing loading the page, or that each subsequent tab would load progressively slower than the last but would eventually finish loading.
I found this repo, it can keep single SignalR connection for all browser tabs of the same application.
Hope it can be a good idea for solving this issue.
Long polling is based on HTTP connections and is therefore susceptible to browser throttling on concurrent HTTP connections.
WebSocket creates a persistent, full-duplex connection that enables multiple pages to be opened at the same time without experiencing performance issues due to the browser's concurrent connection limit.
Related link
Cannot open more than 5 browser tabs when using Long Polling / Atmosphere and Firefox or Chrome
Workaround for long polling
Sharing connection between Browser's windows and tabs
In Signalr, using WebSocket is the best practice.