Thank you for getting back to me, Rob.

It's after working hours here, so we'll have to wait a bit longer until we can review and fix our server.

With the information so far, I am closing this issue as it did not stem from our components, but from environmental configuration. If you do experience problems with our components, feel free to open a support ticket.

Regards,
Marin Bratanov
Progress Telerik

Hi Rob,

You could open a private support ticket.

I've just reviewed this further (it so happened that we had this investigation scheduled for 25 minutes ago) and it looks like our hosting server has had a hiccup - WebSockets are no longer enabled on it, so SignalR falls back to XHR requests, which are waaay too slow for Blazor (and they also carry cookies which makes them huge, in addition to the heavier request pipeline they trigger). It had seemed that the issue comes from a certain script, but this is not the case, it's our server.

In summary, make sure your server has WebSockets enabled :) For example, Azure hosting does not have them enabled by default.

Regards,
Marin Bratanov
Progress Telerik

Hi Rob,

To each point:

• local vs internet sites - indeed, that's how the different models are designed. Until the WebAssembly flavor becomes official, we can't consider moving to it, so we're stuck with the server-side flavor for now. For a more realistic experience, you should, indeed, run things locally.
• animations - at the moment, you can't disable the animation. It shouldn't be an issue when latency is low, however. When latency is large the animation feels two times slower, which is too slow. With low latency, the animation is crisp and quick, and helps the user track that something is changing on the screen - having one is a general UX best practice.
• the demo site script issue - I am not sure I am in a position to comment on that because it might be considered harmful to the vendor's reputation. What I can say is that the issue is that it replays the SignalR binary packets as XHR requests which you can see yourself in the browser console.

Regards,
Marin Bratanov
Progress Telerik

Hello Rob,

To begin with the good news, we are working on improving this the performance of the dropdowns.

That said, in the general case, things should be fine even as it is. I am aware of two cases where issues can manifest:

• on our live demos - they are a server-side app, and as such are not actually suitable for a public facing site where many people have a large latency to it.  There is also an issue with one of the scripts our marketing team uses that interferes with Blazor and we're working on resolving it, and that slows our demos down too.
       So, do you observe such a behavior on localhost or on an intranet hosting? You can also run our demos locally, they are available in your installation folder.
• when there are too many items in the dropdown - this is an inherently problematic scenario and for such cases I would recommend implementing custom filtering like here: https://docs.telerik.com/blazor-ui/components/combobox/events#onread. You may also find interesting this feature request that would also improve rendering performance: https://feedback.telerik.com/blazor/1457808-combobox-virtualization

Do you have a different case?

Regards,
Marin Bratanov
Progress Telerik