Browser limits on concurrent HTTP requests vs. parallel signaling

Browsers limit the number of simultaneous HTTP requests you can make to a given domain. In Chrome, we observe that the limit is 6. This means that your widget can only open 6 concurrent HTTP requests to Freddie.

So when we set widget concurrency N > 6, the widget cannot advertise all N connections in parallel -- instead, it will advertise and signal its first 6 connections, then it will advertise and signal the next 6, and repeat as necessary.

The browser limit is applied at the level of the browser (not the tab), so users who have opened multiple widgets will see this serialized behavior roll over across all widgets in each tab: the first widget will advertise and signal until it no longer needs to create HTTP requests, then the second widget, then the third...

The behavior is self-correcting, but it is suboptimal. Is there a workaround?

No files, tests, or entry points are identified in the issue. Start by locating the widget's HTTP signaling flow and checking how concurrent requests are created; a suitable workaround should avoid or mitigate browser per-domain request serialization and be verified for widget concurrency above six.