This is served out of the West Europe region. As others have pointed out, it is using the least efficient mode possible (HTTP 1.1 polling instead of WebSockets

This is served out of the West Europe region. As others have pointed out, it is using the least efficient mode possible (HTTP 1.1 polling instead of WebSockets or WASM), so it is maximally sensitive to network latency. Unless you're physically near that particular Azure region, you'll have a bad experience. Real-world usage of Blazor for Internet apps would typically use client-side WASM. Similarly, corporations might opt to use WebSockets over their private LAN, which is likely to provide very low latency and high bandwidth. This demo app was accidentally deployed with the incorrect/default settings. It doesn't even have HTTP/2 enabled, let alone WebSockets, which are off by default: https://learn.microsoft.com/en-us/aspnet/core/signalr/publish-to-azure-web-app?view=aspnetcore-7.0#configure-the-app-in-azure-app-service https://learn.microsoft.com/en-us/aspnet/core/signalr/publis... Microsoft themselves mention that performance is expected to be bad with WebSockets off: https://learn.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/server?view=aspnetcore-7.0#azure-signalr-service https://learn.microsoft.com/en-us/aspnet/core/blazor/host-an... When WebSockets are disabled, Azure App Service simulates a real-time connection using HTTP Long Polling. HTTP Long Polling is noticeably slower than running with WebSockets enabled, which doesn't use polling to simulate a client-server connection.