Remix 2.x loader latency only under concurrent requests after enabling shouldRevalidate

After switching a route module to shouldRevalidate: true in a Remix 2.x app, I want to understand why loader response time degrades only when multiple requests arrive at the same time. Single requests complete normally; the slowdown appears strictly under concurrency.

My understanding is that each incoming request gets its own loader invocation with no shared data between requests, so parallelism alone should not cause contention at the framework level. That leaves uncertainty about whether the bottleneck is in my loader's downstream fetch calls, connection pooling, or something about how Remix schedules parallel loader execution for matched routes.

The relevant constraint: the loader must always return fresh data, so caching or reverting shouldRevalidate is not an option. I also need to distinguish framework behavior from my own data-fetching code before changing anything.

Does Remix serialize or otherwise coordinate parallel loader executions for the same route, or are they fully independent? What is the recommended way to instrument loader timing per request to isolate where the added latency comes from? Are there documented concurrency limits or queueing behaviors in Remix 2.x that apply here?