Hello. We’re hitting the following issue. On bigger dashboards, GD sdk sends a ton of requests that might take a while to service. Since browsers usually have a limit of 6 concurrent requests per domain, the requests start queuing and other (non gd sdk) requests are caught up in the queue. This is a problem, because it essentially freezes client side navigation in the app (navigation makes a requests to fetch data for the page the user is navigating to). Sometimes, the dashboards may take 30+ seconds to load and the user is unable to navigate away until it does (or do any other action in the app, that requires sending a request). Any advice how to handle this problem?

Hello Tomas, My name is Jakub and I will assist you with your query as L2 engineer. Indeed internet browsers have a limit set to prevent a single site from monopolizing all the network resources and to ensure fair usage across different sites. When the limit is reached, any additional requests to the same domain are queued until one of the ongoing requests completes. On large web applications or dashboards, this can lead to delays in loading resources, such as API calls, scripts, etc causing parts of the page to load slowly or be unresponsive. These limits apply to both HTTP/1.1 and HTTP/2 protocols, although HTTP/2 can handle requests more efficiently by multiplexing multiple streams over a single connection. Would you be so kind and tell me which exactly dashboard was performing slow so I can have a deep dive in our logs to see what took so long to load?

Thank you, Jakub. This is a generic problem. We have our own customers that can create their own dashboards and we do not really want them to care that while their dashboard is loading they cannot click elsewhere in the application. This would not scale and we cannot focus on optimizing every single custom piece of content just to make the rest of the application usable.

Hello Vaclav, Unfortunately I don't have short answer to that, I'll have to discuss it internally and come back to you with answers later.

just fyi, we solved it by adding cloudfront in front of our app and enabling http3 to leverage multiplexing. thanks!

Hello Tomas, thank you for coming back to me with this information. I would like to understand better how HTTP3 multiplexing is handled on your side. Reason why I am asking is that multiplexing was implemented already in HTTP2 and 6 concurrent connections per domain should not be a road blocker here. HTTP3 is build on top of Quick UDP internet connections which uses independent streams within a connection to the domain - yes, this is one way to achieve your goal. However HTTP2 should provide us way to handle more connections using it's older multiplexing. I would like to better understand why it did not work for you, therefore I will come again with my question if you could provide more details on which dashboard was performing slow, what is the time frame of occurring slowness - this way we can make sure our service is configured correctly and our documentation has complete information about it.

Hi Jakub. The app was deployed on AWS Apprunner and it turns out, it runs on and supports http1 only. So we ended up adding CF in front to get around that. Http2 would work as well of course, it’s just http3 is default on CF now, so we went with that.