If you have more than 40,000 data items, such an issue is expected. In order to solve this issue to some extend, you could use virtual scrolling and not return the entire set of data. The main purpose of this approach is to let you load portions of the combobox items in each ItemsRequested event handler to achieve a faster loading speed. You can read this
help article on virtual scrolling to get the general idea.
I would say that what you are seeing it's quite normal. In a scenario with such a huge set of data, say 45,000 items would have approximately the following footprint:
25 bytes just for the items,
5 bytes for the base text
Near about 3 to 5 bytes for the counter text.
As well as some JSON data.
Multiply by 45000 and you are close more than 1575000 bytes, that is more than 1.5 MegaBytes of postback content. Browsers, especially old browsers such as IE8 are notoriously slow with that much content. Apart from that, these huge set of contents need to be parsed to HTML elements and all JS things set. Even a postback content of 100 KB can cause a delay of about 10 seconds in browsers such as IE8. So you can imagine how it will be with 1.5 MB of data. But I found Chrome on the other side is a bit more fast and 100KB of postback content will not slow it down that much.