[NEXT-1187] Link navigation with loading.tsx is not instant for dynamic pages

[tonypizzicato]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.1.0: Sun Oct  9 20:14:30 PDT 2022; root:xnu-8792.41.9~2/RELEASE_ARM64_T8103
Binaries:
  Node: 18.12.1
  npm: 8.19.2
  Yarn: 1.22.19
  pnpm: N/A
Relevant packages:
  next: 13.0.6-canary.2
  eslint-config-next: 13.0.5
  react: 18.2.0
  react-dom: 18.2.0

Which area of Next.js is affected? (leave empty if unsure)

App directory (appDir: true), Routing (next/router, next/navigation, next/link)

Link to reproduction - Issues with a link to complete (but minimal) reproduction code will be addressed faster

https://github.com/tonypizzicato/next-13-loading

To Reproduce

• pull the repo
• run yarn install && yarn dev
• open localhost:3000 in the browser
• go to the "Careers" page
• reload the page
• set some throttling in devtools
• click different pages in the menu
• notice that "Careers" page loading state and route change are done instantly but with some delay for other pages

Describe the Bug

When you have a dynamic page with loading.tsx the route change and showing the loading animation are instant only for the page, which was freshly loaded. For other dynamic pages it hits the server first, then shows the loading state

next-13-loading.mov

Expected Behavior

Instantly navigate to the desired dynamic page and show loading component

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

No response

_NEXT-1187

[Fredkiss3]

That is how it works, in order to do the loading state, your browser has to first make the request to nextjs server, then nextjs will first return the loading state, and after resolves your page.

The thing is that in need, it is even slower that in production, because nextjs do a bigger amount of work. You could try to run it in production with yarn build && yarn start, but you'll find that it is not really instant, the slowness comes from the speed of your internet connection but also the distance between you and the server. If a normal request from you to the server is about 1s for example, then you'll see the loading state after 1s. But what is cool about the loading state if for example you make a request in your page.tsx which takes more that 5s (for example), you'll always see the loading state after 1s.

All of this is part of streaming rendering : https://beta.nextjs.org/docs/data-fetching/streaming-and-suspense#concepts

[tonypizzicato]

at is how it works, in order to do the loading state, your browser has to first make the request to nextjs server, then nextjs will first return the loading state, and after resolves your page.

that totally makes sense, that's why i've added throttling for testing on the client and delay on the api side. but isn't it a job of page prefetch feature to get the loading state before navigating to it?
and if that's an intended behaviour, why does the first page loaded work differently (instant loading state on client every time)?
and what is the reason to use streaming api with loading.ts feature in next.js if it is only useful (after 1s in your example) for API endpoints that take some significant time? for the most applications with simple db access endpoints its seems useless and client loading state would be preferred.

More than that Next.js docs say that loading.tsx should be instant compared to custom Suspense boundaries

Unlike loading.js, where navigation happens immediately and loading UI is displayed before the request to the server is complete. When manually defining Suspense Boundaries, navigation will happen after the new segment loads.
https://beta.nextjs.org/docs/routing/loading-ui#manually-defining-suspense-boundaries

I mean, I understand why it works the way you described for custom suspense boundaries, but it's not obvious from the docs that the loading.tsx should work the same way

[Fredkiss3]

But what is cool about the loading state if for example you make a request in your page.tsx which takes more that 5s (for example), you'll always see the loading state after 1s.

As i said, for api endpoints that take some time to fetch (for example 5s) it would always take the same amount of time to show you the loading UI, the time it would take you to show the loading state is the time your browser to connect to the server. So if your browser takes 1s to connect to the server, the loading ui would show after 1s and not after 5s, so instead of waiting 5s to show your page, you get a loading state sooner. This is better for when you reload the page for ex.

And you're right, with prefetching it should be instant, since it has already the data... but it seems that when you have a loading state it prefetches twice ? 🤔
In the example below it does two requests to prefetch data (see by the next-router-prefetch header). I don't know if this is a bug or not :

Enregistrement.de.l.ecran.2022-11-30.a.12.13.09.mov

But prefetching isn't also a silver bullet. Take the case when your page hasn't finished prefetching the page, it would still take 1s before showing you the loading state and i think even if your page where static it would take the same amount of time : the time it takes for your browser to connect to your server and your server to serve you the static page.

Showing a loading state on the client would definitely make it faster, but only if you don't issue a navigation : like you fetch on the client without navigating to another page i think... 🤔

[dumbravaandrei22]

Still happening in 13.1.3-canary.0

[dumbravaandrei22]

I think that the loading.tsx should be instant without any network calls.
I know that the loading.tsx will be under a page request, but like @tonypizzicato said the website should prefetch the Links that are on the page.
That's the idea, from a user's POV, the user should receive instant feedback from the app.
If the loading.tsx will take some time to load (even a small one) it will be useless.

[eug-vs]

Absolutely agree with all problems raised in this issue, this is the only thing stopping our project from migrating to App Router - navigation creates just horrible experience with sometimes up to 300ms wait time before even the loading streams in (I know this can be solved by moving the server closer e.g. on edge, but that's a different story). Other side of the problem is that there's no way to display any other loading state on the UI while loading hasn't streamed in yet - you are forced into this UX.

I truly don't understand the reason behind this: if loading.tsx doesn't accept any props and is essentially static (usually just a bunch of skeletons), why can't we include it in client-side bundle (or at least opt-in to that)? Or event better - do not include it into a bundle, but fetch it and cache properly on the client - so that subsequent visits of the same page immediately show the fetch UI from client-side cache. That is probably how prefetch should work, but currently my experience is that it's working in a very random fashion (even in NextJS playground: https://app-dir.vercel.app/streaming/edge/product/2)

With Suspense it's a bit different because it allows for granular control, but even then the initial state where Suspense is showing fallback could be used with the same approach.

[hc0503]

@tonypizzicato , I've resolved same issue with group route.
https://beta.nextjs.org/docs/routing/defining-routes#route-groups
Look at my app route structure.

Dynamic page uses the nearest parent loading.tsx, but announcements must has another loading.tsx.
To resolve this problem, I used group route.
I hope this solution works well for you.

[mhesham32]

for me when I added a root loading.tsx file it was picked immediately after I started the navigation to another page while the loading.tsx file inside the other page's folder wasn't picked and I was getting the same behavior as @tonypizzicato before adding the root loading.tsx file.
also the other SSR page is a search page and it gets the search query from URL search params I was expecting the loading.tsx to appear when I change the params within the page to fetch new data but instead, it was displaying the old results after clicking on search and then suddenly the new results replace them which is not good for UX it was like the site was unresponsive

[mhesham32]

it's worth mentioning the above behavior was happening with next@13.2.4 but when I upgraded to 13.3 it was no longer happening

[hc0503]

@mhesham32 , did you use client component in 13.3?
that has error in my end.
#43930 (comment)

[mhesham32]

Yes the navigation is triggered from a client component to a server page

[sourcecodes2]

We are also experiencing this issue, and it is still present on v13.3.

The concept of "loading" for the end user means anything that is delaying their request, whether it's due to server processing or network latency.

There should be no distinction to the end user on technical merit. This is purely a UX issue.

End users need immediate feedback, whether that's the data they've requested or feedback to say their request is being handled.

Currently, this implementation fails to do this.

This is a core part of the age-old business arguement for retaining impatient users that we work ever so hard to get, that cannot be overlooked.

The fact that the on-request loading feedback needs loading on-request makes this implementation feel like one step forward and two steps back.

We are very grateful for NextJS and we do appreciate that the AppDir is still in beta, but please make sure this UX issue is fixed before release.

[Fredkiss3]

It seems that to make loading instant you have to define it on the parent folder of the dynamic route like they do in App dir playground repository.

You can also use route groups like in @devdreamsolution comment : #43548 (comment)