The first time a key is put into useQuery, experiencing a ~500ms-1000ms thread blocking

[jeseed]

Description

We're experiencing a consistent 500-1000ms delay the first time we call useQuery() for a specific query key (and only the first time for each new query key), even before any network request is initiated.

Is setting up the observer and cache for an individual query supposed to be this expensive?

Observed Behaviour
We have an app that changes an "activeConversationId". Every time this conversationId changes, a 500ms block occurs on react query.

1. The first time and only the first time a new conversationId is passed in, there's a ~500-1000ms blocker.
2. So if I select a conversationId, and select a different one, and come back, this won't happen. This means it's not the rendering itself.
3. Not the network call or downstream result of data changing Even if I set enabled to "false" permanently, this still happens.
   3a. The 500ms occurs BEFORE the network request starts
4. • NOT tRPC overhead: Even if I don't use TRPC (we suspected trpc runtime compilation) and use direct queryFn, this still happens.
5. • NOT query key complexity: Tested with simple flat keys like ['simple', id] - still slow Bypassed tRPC's queryOptions() - still slow
6. • NOT cache lookup: Direct getQueryData() calls are instant (~1ms)

const getConversationQuery = useQuery(
    trpc.crm.getConversation.queryOptions(
      {
        id: conversationId!,
       },
      {
        enabled: !!conversationId && !shouldLoad,
        staleTime: 2 _ 60 _ 1000,
        gcTime: 24 _ 60 _ 60 \* 1000,
        notifyOnChangeProps: ['data', 'error'],
        placeholderData: (previousData) => previousData,
        initialDataUpdatedAt: 0,
      },
    ),
    );
    
    const loadConversationQuery = useQuery(
      trpc.crm.loadConversation.queryOptions(
      {
        threadId: threadId!,
        conversationId: conversationId || undefined,
      },
      {
        enabled: !!shouldLoad,
        staleTime: 2 _ 60 _ 1000,
        gcTime: 24 _ 60 _ 60 \* 1000,
        notifyOnChangeProps: ['data', 'error'],
        placeholderData: (previousData) => previousData,
        initialDataUpdatedAt: 0,
      },
  ),
);

Environment

• React Query version: v5.74.4 (latest)
• React version: 19.0.0
• Cache size: 465+ queries
• Active queries: 30+ concurrent fetches
• Use case: Navigation between different conversation threads

Question

Is this 500ms delay expected behavior when creating queries with new keys in a cache of this size? What am I doing wrong here?

[tt-a1i]

500ms-1000ms for observer creation is definitely not expected. With 465+ queries and 30+ active fetches, here are some things to investigate:

1. Profile the exact operation

const start = performance.now();
const result = useQuery(...);
console.log("useQuery took:", performance.now() - start);

2. Check if it's React DevTools
React DevTools can significantly slow down initial renders. Try disabling it temporarily.

3. Subscription overhead
With 465+ queries, the QueryCache might be doing expensive work when adding observers. Try:

// Check how many observers exist
console.log(queryClient.getQueryCache().getAll().reduce(
  (sum, q) => sum + q.observers.length, 0
));

4. Possible culprits

• placeholderData: (prev) => prev - this runs a function on every render
• notifyOnChangeProps filtering logic
• Large data structures being compared for equality

5. Try isolating

// Minimal reproduction
const testQuery = useQuery({
  queryKey: ["test", Date.now()],
  queryFn: () => Promise.resolve(null),
  enabled: false,
});

If this minimal query is also slow, it's likely cache size related. If fast, then something in your options is expensive.

6. Consider query client config

new QueryClient({
  defaultOptions: {
    queries: {
      structuralSharing: false, // Try disabling if you have large data
    },
  },
});

A cache with 465+ entries shouldn't cause 500ms delays, so something else is likely at play.