Dynamic routes always server rendered and ?_rsc call each time on view

[TimNZ]

Summary

I know this has been asked a million times but I can't find a solid answer via google or GPT.
My dynamic routes e.g. /items/[id]/page.tsx that are pure 'use client' components always get rendered as dynamic pages,
resulting in _rsc calls on every view of the page - this kills the UX with an un-necessary [often slow call - 300-400ms], the page data is managed via client side Tanstack Query.

I am not clear if there is a way to prevent the _rsc calls or not.
I've also tried moving the component to a separate component with 'use client' to force static render, and still _rsc request every time.
Non-dynamic routes do not have _rsc calls.

The Pages router was so much easier.

Additional information

Next 16.1.4

Example

No response

[ezsouza]

This is a really common frustration with the App Router.

The issue is that in the App Router, any route with a dynamic segment ([id]) is automatically marked as dynamic unless Next.js can statically determine the route at build time. When you navigate to a dynamic route, Next.js needs to re-execute the server component tree to check if there's any dynamic data, which triggers that _rsc request you're seeing.

use client only tells Next.js where the component boundary is for client-side hydration — it doesn't change the route's rendering strategy. Even if the whole page is a client component, the router still treats it as dynamic.

Here are a couple things you can try:

1. Use generateStaticParams in your [id]/page.tsx to pre-generate the static routes at build time. This tells Next.js the exact set of id values, so it can render them as static pages without _rsc calls.

2. Use export const dynamic = 'force-static' in your page to force static generation (only works with generateStaticParams).

3. Switch to a query param approach instead of dynamic segments, like /items?id=123. This keeps the route static.

The Pages Router handled this more intuitively because it didn't mix server/client boundaries the same way. Hope this helps!

[sefin23]

The ?_rsc calls on dynamic routes are by design in App Router — but there are concrete ways to eliminate or reduce them for your use case.

Why dynamic routes always fire ?_rsc

When you client-side navigate to a dynamic route (/items/[id]), Next.js fires a ?_rsc=... fetch to re-run the server component tree for that route. This happens even if your page.tsx is 'use client' — because:

1. Next.js still needs to resolve the layout tree server-side (layouts are always Server Components unless explicitly marked 'use client')
2. The App Router uses RSC for all navigations to dynamic segments to support server-side data, middleware, and layout nesting
3. 'use client' only marks where client components start — the route itself is still "dynamic" because the segment is unknown at build time

Solution 1: Add generateStaticParams (if IDs are known)

If your items have known IDs (or a known set), pre-generate them:

// app/items/[id]/page.tsx
export async function generateStaticParams() {
  const items = await fetchAllItems(); // or use a static list
  return items.map((item) => ({ id: item.id.toString() }));
}

export const dynamicParams = false; // 404 for unknown IDs (optional)
// or
export const dynamicParams = true;  // still SSR for unknown IDs

With generateStaticParams, known IDs become static — no _rsc call on navigation to pre-rendered pages.

Solution 2: Force your layouts to be lightweight (the real fix for Tanstack Query)

Since you're using Tanstack Query client-side, the _rsc call is likely coming from a Server Component layout that does something (e.g., auth check, data fetch). Make all parent layouts minimal:

// app/items/layout.tsx  — keep this a simple pass-through
export default function ItemsLayout({ children }: { children: React.ReactNode }) {
  return <>{children}</>;
}

Avoid any async operations in layouts above your dynamic route. The _rsc request cost is directly tied to how much work your server component tree does — if layouts are trivial pass-throughs, the 300-400ms drops dramatically.

Solution 3: Use loading.tsx to mask the latency

If you can't eliminate the _rsc call, you can make it invisible:

// app/items/[id]/loading.tsx
export default function Loading() {
  return <YourSkeletonComponent />; // shown immediately during _rsc fetch
}

This renders instantly while the _rsc request completes in the background — users see a skeleton, not a blank page or a 300-400ms freeze.

Solution 4: prefetch on hover

If you're using <Link> to navigate to items, Next.js prefetches the _rsc payload before the user clicks:

<Link href={`/items/${id}`} prefetch={true}>
  View Item
</Link>

With prefetching, the _rsc payload is already cached by the time the user navigates — zero perceived latency.

Summary

Approach	Eliminates _rsc?	Works with unknown IDs?
generateStaticParams	✅ Yes	❌ No (only known IDs)
Lightweight layouts	❌ No, but much faster	✅ Yes
loading.tsx skeleton	❌ No, but invisible	✅ Yes
<Link prefetch>	❌ No, but pre-fetched	✅ Yes
Query params (?id=)	✅ Yes	✅ Yes (but changes URL structure)

For a Tanstack Query app with unknown IDs at build time, the best combination is lightweight layouts + loading.tsx + <Link prefetch>. This makes the _rsc call fast and invisible without restructuring your routes.

[Ajay1628Kumar]

I am using the Link tag but my url has query params so even after the _rsc call if fired everytime i am navigating to that page it still fires the _rsc call. is there any way to fix that. my url is something like "/product/1?somequerparams="somequeryparams"