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

Question

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?

Wasi · Answer

Direct AnswerRemix does not serialize or coordinate parallel loader executions for the same route. Each incoming request receives its own independent loader invocation. The framework adds negligible per-request overhead; the "fine alone, slow together" pattern is almost certainly downstream contention amplified by higher request volume.Confirmed Facts vs Likely ExplanationConfirmed: Remix 2.x runs each request's loaders independently, with no framework-level queue for the same route. shouldRevalidate controls client-side revalidation after actions/navigation, not server-side request scheduling.Likely explanation: Enabling shouldRevalidate: true forces revalidation on every navigation/action, multiplying server requests. Under concurrency, fixed downstream limits surface: Node HTTP agent socket limits, HTTP client pool limits, database connection pool limits, upstream rate limiting, or CPU-bound work blocking the event loop.Instrumentation Steps for This CaseAdd per-request timing with a request ID inside the loader:export async function loader({ request }) {
  const reqId = crypto.randomUUID();
  const start = performance.now();
  const timings = {};

const fetchStart = performance.now();
  const data = await fetchDownstream();
  timings.downstream = performance.now() - fetchStart;

timings.total = performance.now() - start;
  console.log(JSON.stringify({ reqId, ...timings }));
  return data;
}Run controlled concurrency with autocannon/k6/artillery against the route.Compare total vs downstream. If they match, bottleneck is downstream I/O. If total is significantly higher, investigate event-loop blocking.Repeat with downstream mocked. If latency disappears, the issue is downstream, not Remix.One Diagnostic Detail NeededCheck server access logs: did the request rate per second increase after enabling shouldRevalidate? If request rate rose proportionally, the fix is downstream capacity, not Remix configuration.

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

1 answer

Direct Answer

Confirmed Facts vs Likely Explanation

Instrumentation Steps for This Case

One Diagnostic Detail Needed

Your perspective belongs here.

0 question comments