loading.tsx never renders on client nav but works on hard refresh, 3s of nothing Streaming

loading.tsx only covers the segments below it. If the 2.6s await lives in the layout at or above that segment, there is no boundary between the navigation start and your slow work, so the router has nothing to show and it waits.

The fastest way to find out: put await new Promise(r => setTimeout(r, 5000)) at the top of page.tsx and click the link. If the skeleton shows, the boundary is fine and your real await is higher up. If it still hangs, the await is in the layout.

Either way the fix is the same shape - stop awaiting in the layout, move the slow component into the page and wrap it yourself:

<Suspense fallback={<ReportsSkeleton />}>
  <SlowChart range={range} />
</Suspense>

Before you change anything, look at the network tab and find the request with ?_rsc= in it during the click. Time it. If that request takes 2.8s and returns one payload, nothing is streaming and you are debugging the wrong layer. If it takes 200ms and streams chunks, your fallback is rendering somewhere you cannot see and it is a CSS/layout problem instead.

Half the "streaming does not work" threads I read are people who never checked whether the response was chunked.

Also check generateMetadata on that route. If it awaits the same slow query, the render can sit behind it, and because the hard navigation path and the client navigation path do not treat it identically you get exactly this asymmetry. Comment it out for one test run - it costs you thirty seconds and rules out a whole branch.

This is prefetch. <Link> prefetches the route, so by the time you click it has a payload and skips the loading state deliberately. Set prefetch={false} and you will see your skeleton.

Unrelated to the bug but 2.6s for a chart nobody asked for yet - can you render the page shell with the last cached numbers and let the fresh ones land when they land? I stopped fighting boundaries once I accepted that most dashboards are fine slightly stale.