SSR responses stall under concurrent load in a Qwik app using routeLoader$

I'm designing the data-loading layer for a Qwik 1.x application and trying to understand one behavior before committing to an architecture: when many requests hit the server at once, streamed SSR responses appear to stall until async work in routeLoader$ or server$ functions completes, delaying the flushed HTML chunks for every waiting request.

My understanding is that Qwik streams HTML and serializes application state progressively so the client can resume without hydration. What I can't resolve from the documentation is how this interacts with concurrency: whether a slow loader blocks only its own request's stream or can degrade other in-flight requests on a saturated Node server, and whether large serialized state inflates time-to-first-byte enough to matter under load.

There is also the client side: event handlers are lazy-loaded per chunk, so a burst of users triggering uncached chunks without prefetching could spike latency against the origin. I am unsure whether to treat that as a framework concern or purely a CDN caching concern.

Is the concurrency-related stall in streamed SSR a documented, expected behavior of Qwik's streaming model, or strictly an infrastructure saturation problem? Does Qwik provide any documented mechanism to bound or isolate slow routeLoader$ work per request? And is there a documented way to verify that prefetching has actually populated chunk caches before first interaction?