How to prefetchQuery on the server only on the first load in Nextjs App Router?

[longprao]

Expected:

• Initial/first load when we enter the app, the data should be loaded on the server (SSR for SEO purpose etc...).
• Subsequence client navigation (via Next Link or router.push), data should be loaded on the client (useQuery), it should not wait for server trip.
• Navigating back (via Next Link or router.push, NOT browser back), data should be available instantly (since it was loaded before), it should not wait for server trip.

Previously in Pages Router, it was achieved using getInitialProps, like so:

Index.getInitialProps = async (ctx) => {
  const queryClient = new QueryClient()

  // this is to query only on first load
  const isFirstServerCall = ctx.req?.url?.indexOf('/_next/data/') === -1

  if (isFirstServerCall) {
    await Promise.all([
      queryClient.prefetchQuery({
        queryKey: [QK_KEY],
        queryFn: fetchData()...,
      }),
    ])
  }

  return {
    dehydratedState: dehydrate(queryClient),
  }
}

In App Router, based on the docs, this is the only way to query data on the server:

https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr

export default async function Page() {
  const queryClient = getQueryClient()

  await queryClient.prefetchQuery({
      queryKey: [QK_KEY],
      queryFn: fetchData()...,
  })

  return (
    <HydrationBoundary state={dehydrate(queryClient)}>
      <LandingPage />
    </HydrationBoundary>
  )
}

With this setup it will hit the server and wait for data fetching all the time, which is a slow navigation experience. How to detect whether it's the first load? Or return cached data instantly?

[TkDodo]

you can not await the prefetching and stream the promise to the client cache. That’s kinda the best of both worlds. or you can persist the queryCache on the server, in which case prefetchQuery would give you data back immediately if its not stale.

[leosilberg]

Hi , I've also followed the above docs to setup ssr in nextjs app router

export const dynamic = "force-dynamic";

export default function Page() {
  console.log("dashboard page.tsx: ");
  const queryClient = getQueryClient();

  queryClient.prefetchQuery(getAllDevicesOptions);

  return (
    <HydrationBoundary state={dehydrate(queryClient)}>
      <DeviceDashboardPage />
    </HydrationBoundary>
  );
}

Currently every time a user clicks a link to this page it will trigger a prefetch and request from the server. If a new queryClient is returned for each request how would it know if the data is stale? Is there any way to force Nextjs not to call the server when a link is clicked so that the client queryClient will handle data fetching?

[TkDodo]

the QueryClient only caches on the client. On the server, there is no caching as each request is getting its own, new, empty QueryClient.

you can look into persisting the QueryClient on the server between requests but it’s not easy to get right and not share data between users.

[leosilberg]

My difficulty in understanding is more regarding the subsequent requests to this page after the first ssr. It seems Nextjs will always call the server and that will cause the server to stream the external request every time back to the client. This process could be optimised by just using the client as a SPA that makes the request directly from the client. My question is would there be a way to stop Nextjs calling the server after first render or a check for prefretch if it's a first render or not?

[TkDodo]

You'd have to ask that in a nextjs discussion please. I guess there's some sort of caching you can set

[longprao]

I have asked my same question on nextjs discussion. No answers. We have decided to keep using pages router for existing apps and also new apps. One team even migrated from app router to pages router with great performance boost as a result. React-query + pages-router = heaven!

[MarioMS90]

Hello,

I've encountered another issue related to this. If the data is already stale, even though server components perform a prefetch on subsequent visits to the same page, the client doesn’t actually use that prefetch. Instead, it makes its own query to the server, resulting in two consecutive requests to the API, even though only one is actually used. This only happens when revisiting the same route—on the initial load, everything works fine, and React Query correctly utilizes the serialized promise.

On the other hand, I’ve been researching possible solutions, and so far, I’ve found a way to prevent Next.js from re-rendering server components on subsequent visits to the same route. This can be achieved using the experimental staleTimes option, which caches pages on the client:

🔗 Next.js staleTimes documentation

The downside is that this setting applies to all routes globally. However, in my case, it solves the issue since I only need server components to execute on the first visit during a browsing session.

Another possible solution, without having to persist the entire queryCache on the server, is to implement a cookie-based system to track which components have already performed a prefetch and prevent them from doing it again. However, it would be necessary to ensure these cookies are invalidated between sessions.

[leosilberg]

I've encountered another issue related to this. If the data is already stale, even though server components perform a refetch on subsequent visits to the same page, the client doesn’t actually use that refetch. Instead, it makes its own query to the server, resulting in two consecutive requests to the API, even though only one is actually used. This only happens when revisiting the same route—on the initial load, everything works fine, and React Query correctly utilizes the serialized promise.

Now that you have mentioned it, I may also have encountered this issue seeing two requests in the logs but couldn't understand the cause.

On the other hand, I’ve been researching possible solutions, and so far, I’ve found a way to prevent Next.js from re-rendering server components on subsequent visits to the same route. This can be achieved using the experimental staleTimes option, which caches pages on the client:

Thanks for the suggestion, I will try it out next week to see if it solves my problem.

I would have thought more people would be using this combination of app router and prefetching but there's hardly any information available for this use case

[leosilberg]

I've encountered another issue related to this. If the data is already stale, even though server components perform a refetch on subsequent visits to the same page, the client doesn’t actually use that refetch. Instead, it makes its own query to the server, resulting in two consecutive requests to the API, even though only one is actually used. This only happens when revisiting the same route—on the initial load, everything works fine, and React Query correctly utilizes the serialized promise.

Now that you have mentioned it, I may also have encountered this issue seeing two requests in the logs but couldn't understand the cause.

I can confirm seeing the double fetch, one from the server prefetch and one from the client refresh stale data

On the other hand, I’ve been researching possible solutions, and so far, I’ve found a way to prevent Next.js from re-rendering server components on subsequent visits to the same route. This can be achieved using the experimental staleTimes option, which caches pages on the client:

Thanks for the suggestion, I will try it out next week to see if it solves my problem.

Setting the staleTimes does solve this behavior except in one case:

Open Page A -> Navigate with Link B -> Page B -> Navigate with Link A (fetches server component) -> Page A

The client will still fetch the Page A server component and prefetch data.

The staleTime can only cache pages when navigating to them through a Link and won't cache when opening from browser

UPDATE:

It seems in the production build that Page A is cached correctly from opening