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? We've done a ton of experiments to isolate the cause (and I've read all of @TkDodo great essays on RQ), and are stuck here.

Spent many hours, any help is super appreciated. Thanks ahead of time :)

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

Observed Behaviour

We have an application with a list of emails, and the user can click up and down to select an email. When the user selects a new email, we set an associated conversationId that gives them some important context with for it.

To populate this data, we have a Sync component that subscribes to the "activeConversationId", and below we have how we instantiate the useQuery hooks. Here is the behaviour, with detailed performance logging:

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,
      },
  ),
);

When navigating to a new thread (which creates queries with new conversationId values):

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?