whats your current setup? Is your route alr static? Do you have loading.tsx? Are you using cacheComponents? What nextjs version are you on?

Do you have any data fetching in that route? If so you can wrap the data fetching part in <Suspense>. It will allow the route to instantly switch and display the fallback UI until the data fetching is done. https://nextjs.org/docs/app/getting-started/fetching-data#streaming

export default function Page() {
  return (
    <div>
      <h1>My Page</h1>
      <Suspense fallback={<FallbackUI />}>
        <SlowDataFetchingComponent />
      </Suspense>
    </div>
}

Edit: Sorry didn't see someone else has already replied since I was typing.

It's just a pagemtsx with data being fetched in useEffect hooks. Yes there is a loading.tsx. Looking up about cache component not sure what those are. Nextjs 14. Thanks!

I find also, if you're running in Dev it can feel real slow on navigation

Like cache components in prod on Vercel is like a cheetah

ok bro so this is what is happening. Nextjs does something called code splitting which means the whole JavaScript bundle isn't sent to the browser on at once. only chunks of what's needed is sent to browser on request .

so when you're on /routeA and route to /routeB, Nextjs request for that page chunk which causes that little delay. if you route back to a page you've visited before, you'll notice the routing feels instant

in SPA, the routing feels instant because the browser downloads the whole JavaScript bundles at once but in Nextjs its different

one way to have a bit of a performance boost is to use the Link component. it helps preload pages so routing to them feels more faster than before


hope this helps

@Brown bear hope you see this

Is there any reason why you are fetching data inside an useEffct instead of fetching directly inside RSC’s?

you don't need cache components for now

exactly

Thanks for the help and explanations! Now its much better I'm using Link component instead of useRouter hook and I've moved to fetching data within page.tsx as server component and passing it to its respective client component, while loading.tsx handles loading perfectly.

Sounds great. Please mark solution[:](https://cdn.discordapp.com/attachments/1043615796787683408/1117191182133501962/image.png?ex=699b695e&is=699a17de&hm=34823bf4d436afcdce02a62d9e6e0af33f1f444449ecf289975dd02acfdf64c4&)

Just to add a bit more to this, I would prefer wrapping the async component in Suspense, instead of having a loading.tsx file.

Assume you had 10 components in a page. And only one component was doing some slow data fetching and other 9 components weren’t using that data.

With loading.tsx file you would be displaying a fall back UI for the entire page while that single component is loading.

If you instead only wrapped that single component in a Suspense boundary, all other 9 components will load instantly while the fallback will only be displayed for that single slow component.

If somehow all 10 components were depending on that fetched data, then it won’t make any difference and a ‘loading.tsx` file would be easier, but thought it was worth noting in a case where you want to isolate the fallback behavior to a component level.

Thanks! will def use suspense that way

funny how I've been reading on react Fibre and concurrent rendering lately