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

[tonypizzicato]

Verify canary release

• [X] 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

https://user-images.githubusercontent.com/640122/204661070-b9409f71-3814-45e6-bf56-923cdf4e2fc6.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]

And I have a loading.tsx at the same level. But when I click on this Link (if I have not clicked on it before). There is nothing happening for 1s, then the loading state of the loading.tsx is displayed. I tried it out on the latest next stable release and on canary. It is the same on both versions. I can try to convert all of the things using Link to client side and try the workaround with useTransition mentioned above.

@DoctorManhattan123 is the delay also happening in production ? also, is the delay faster in local (production) or just on your host ?

If this is the case, is there any task happening that takes 1s on your /login page (like a slow fetch or something) ?

[nachthammer]

@Fredkiss3 So I after I read the Link docs again. And after I build it in production the delay was not happening anymore. But I have to look at it again when we deploy on vercel, but it should work now.

[janprasil]

I challenged the same problem. Thanks to useTransition I was able to add a loader before redirect to requested page. As you can see on the attached video with simulated fast 3G connection - when loading.tsx is being fetched it shows a loader instead of the link, then it shows loader from loading.tsx until it's fully loaded.

https://github.com/vercel/next.js/assets/8022830/d9044b48-ce74-4e4e-9d00-9db123ee0b4f

[mhesham32]

@rusted-love i also thought this was a bug, but this is expected, the solution is to use a different key to Suspense to force React to consider the Suspense as a different component each time and show the fallback, i've done something like that here : https://github.com/Fredkiss3/todo-app-beautiful-ux/blob/main/src/app/(routes)/(app)/%40todo_app/page.tsx#L49-L54

You could either encore the search params to string to set a unique key per search, or use Math.random() to have a random key each time and always show the fallback. Encoding the searchParams for the key could be interesting if the user refetch the same page, since the key is the same React won't show the fallback and the user will still see the old content, while when navigating to another page, it will show them a fallback.

I think this behavior is related to how Suspense work with transitions. the thing is that when using Suspense if the fallback have already been shown once, if you use a transition, React will hold the old data until the Suspense boundary has resolved, and Next uses transitions for all the navigations. Using a different key forces React to consider the Suspense as a different component.

This is from the React documentation here : https://react.dev/reference/react/Suspense#preventing-already-revealed-content-from-hiding

hey, thank you for putting this here but when I tried to do the same it didn't work at all the page is frozen till the request is done and then it shows the new results right after that

async function SearchPage(props: Props) {
  ...code 

  if (products === null) return notFound();
  const keyString = `searchMode=${props.params.searchMode}&searchText=${props.searchParams.searchText}&scanId=${props.searchParams.scanId}`;

  return isSSR() ? (
    <main className={styles.search_page}>
      <Products products={products} />
    </main>
  ) : (
    <Suspense fallback={<LoadingSkeleton />} key={keyString}>
      <main className={styles.search_page}>
        <Products products={products} />
      </main>
    </Suspense>
  );
}

the layout of this page contains a search form that should update the search params with the user entered data on submit

[mhesham32]

right now I think it is a good solution to use useTransition so the user knows that there is something happening in the background and the app is responsive to his actions. but also I think it will be great if Next added a prop for the page.tsx/layout.tsx components that has the pending state of the useTransition so the developer can be free to show a loading state based on that

something similar to this code from react docs

function Router() {
  const [page, setPage] = useState('/');
  const [isPending, startTransition] = useTransition();

  function navigate(url) {
    startTransition(() => {
      setPage(url);
    });
  }

  let content;
  if (page === '/') {
    content = (
      <IndexPage navigate={navigate} />
    );
  } else if (page === '/the-beatles') {
    content = (
      <ArtistPage
        artist={{
          id: 'the-beatles',
          name: 'The Beatles',
        }}
      />
    );
  }
  return (
    <Layout isPending={isPending}>
      {content}
    </Layout>
  );
}

[Fredkiss3]

@mhesham32 @rusted-love

After a little bit of time, i found out the problem with Suspense not showing 👉🏾 The culprit is vercel.

I tested on different providers to validate my hypothesis :

• on local : the Suspense fallback is always shown
• on vercel : the Suspense fallback is shown if it hadn't been shown before but after it is never shown again, even if the request is slowed down (fake 2s delay)
• on cloudfare (with their new @cloudfare/next-on-pages package) : the Suspense fallback is always shown
• on railway : the Suspense fallback is always shown

You can inspect the code here : https://github.com/Fredkiss3/parallel-routes-modal-next/blob/main/src/app/pokedex/page.tsx link for vercel deployment : https://parallel-routes-modal-next.vercel.app/pokedex link for cloudfare deployment : https://next-on-cf.fredkiss.dev/pokedex link for railway deployment : https://parallel-routes-modal-next-production.up.railway.app/pokedex

i don't have any idea as to why the fallback is not shown right away on vercel, i even tried to inspect the network tab on chrome to see if maybe the response from vercel wasn't streaming, but i did not see anything unusual, the response seemed to be streaming normally and the network tab seems to be the same between vercel, cloudfare and railway.

[mhesham32]

yeah Vercel also didn't allow me to send stream from a route.tsx file as a response it worked locally but on Vercel it didn't work so we deployed our app on cloud run and it worked there. thanks for your example it really helped a lot

[markkkkas]

Will there be any response from the Vercel team? Should we wait for a fix, or can we start migrating to another hosting provider?

[Fredkiss3]

I created an issue for the Suspense case : #51033

[feedthejim]

Hey, I think we identified the issue and will be rolling out a fix.

[andrewbarnesweb]

I challenged the same problem. Thanks to useTransition I was able to add a loader before redirect to requested page. As you can see on the attached video with simulated fast 3G connection - when loading.tsx is being fetched it shows a loader instead of the link, then it shows loader from loading.tsx until it's fully loaded.

https://github.com/vercel/next.js/assets/8022830/d9044b48-ce74-4e4e-9d00-9db123ee0b4f

That's a fair solution to the delay. But then to keep the good user experience of instant feedback, you need two "loading" implementations every time, which is a pain when coming from a SPA mindset.

[pabloat81]

Hi, i have a question.

I am using nextjs@latest

I have a page with a table (SSR) and a pagination compnent (client component, only this component) with Next Links that changes the query string in xxxxx/list?page=yy

I have the loading.tsx thats is showed the first time the page loads, but i cant make it apear when i click on a pagination Link. Is the same issue here?

Also i have a search form that uses server action, the action does a router.redirect(xxxx/list?page=1&text=yyy).

Thanks.

[timneutkens]

Suspense doesn't trigger again when key matches the second time, so if you push searchParams into the url you'll want to add a key that changes. For example:

<Suspense key={`page-${pageNumber}`} fallback={<>my loading...</>}>

[pabloat81]

Suspense doesn't trigger again when key matches the second time, so if you push searchParams into the url you'll want to add a key that changes. For example <Suspense key={page-${pageNumber}} fallback={<>my loading...</>}>

Hi, i done that but isnt working: In the page component:

 const keyString = `text=${searchParams?.text}&page=${searchParams?.page}`;
 <Suspense fallback={<Loading />} key={keyString}>

The pagination link: <Link key={keyString} scroll={false} href={{ query: q }} >1</Link>

What it es working is when i make a search in a form with a server action:

<form className="flex-none gap-2" action={search}>
                    <div className="form-control">
                        <input type="search" placeholder="Nombre / email"
                            defaultValue={searchParams?.text}
                            name="text" className="input input-bordered w-24 md:w-auto" />
                    </div>
                    <button className="btn">Buscar</button></form>

 async function search(data: FormData) {
        'use server'
        redirect(`${URL_ADMIN_PAGE_DEALERS}?text=${data.get('text')}&page=1`);
    }

[huozhi]

The original reproduction is fixed when I tried with the new canary version with nextjs. The issue mentioned here about edge runtime streaming is fixed on vercel platform now.

Let me know if you still have any further problem, or if there's new issue encountered, please file a new issue with reproduction. Thanks y'all for the information and investigation.

[adarsh-drishya]

i am still facing this issue, my page is getting loaded after five clicks, using app router Link from 'next/navigation' pls do something, suggest me fix.

[gudvinga]

i am still facing this issue, my page is getting loaded after five clicks, using app router Link from 'next/navigation' pls do something, suggest me fix.

Hi, just like an idea

We can navigate in two ways: router and next/link Create some state with a loading flag, when clicking a link or navigating a router, set it to true, then when the pathname and searchParams change set it to false and use it to display the loading state in the UI.

useAppRouter.ts

import { useRouter as useNextRouter } from "next/navigation";

export function useAppRouter() {
  const router = useNextRouter();

  return Object.keys(router).reduce((acc, key) => {
    acc[key] = (...args) => {
      setIsLoading(true)
      router[key](...args);
    };
    return acc;
  }, {} as typeof router);
}

appLink.tsx

"use client"
import NextLink from "next/link";

export function AppLink(props) {
  return (
    <NextLink {...props} onClick={() => setIsLoading(true)}>
      {props.children}
    </NextLink>
  );
}

Next.js router event example

'use client'

import { useEffect } from 'react'
import { usePathname, useSearchParams } from 'next/navigation'

export function NavigationEvents() {
  const pathname = usePathname()
  const searchParams = useSearchParams()

  useEffect(() => {
    setIsLoading(false)
  }, [pathname, searchParams])

  return null
}

A terrible decision, but so far nothing better comes to mind

[leandronorcio]

It looks like it's hitting the server before showing the loading.tsx, this feels very sluggish, would've been better if the loading.tsx is shown instantly upon user navigation. Tested on the latest canary 13.4.20-canary.27.

https://github.com/vercel/next.js/assets/32889996/487b9973-74f0-4dfa-9211-0296e4182ae9

[louisthomaspro]

I noticed that after the 30s prefetch cache for dynamic routes, the loading.tsx is not showing up.

[arackaf]

@huozhi @timneutkens

Can we re-open this issue? I'm on latest Next and this does definitely still appear to be an issue. The "instant" loading pages do appear to require a network roundtrip to display, and so would appear to be anything but "instant"

For a page without Suspense streaming, the loading component seems to show after a network roundtrip. For a page with Suspense streaming, it doesn't seem to show at all, since the actual page is ready once that network roundtrip is complete, so the page with the Suspense fallback shows instead.

Am I wrong to assume these loading.tsx components will be loaded client-side, to show instantly on navigation?

Here's a demo

The related repo is here: https://github.com/arackaf/next-instant-loading

which is deployed here: https://next-instant-loading.vercel.app/stream

[feedthejim]

Hello @arackaf thanks for reporting the issue, I attached a PR and fixed the issue. Tested here with your repro https://next-instant-loading-8nv6psqod-feedthejim.vercel.app , thanks a lot :)

[timneutkens]

Landed in https://github.com/vercel/next.js/pull/55950

[arackaf]

@timneutkens Was this released with the recent 13.5.4 version that dropped 3 days ago? I'm still seeing the same behavior.

Repo / branch are here https://github.com/arackaf/next-instant-loading/tree/feature/instant-loading

[jvandenaardweg]

It landed in 13.5.3: https://github.com/vercel/next.js/releases/tag/v13.5.3 , see last item in "Core changes"

But I'm also experiencing the same as @arackaf shows. Showing the loading indicator is not instant because of a RSC fetch to the server that apparently needs to resolve first. As already stated in this issue.

I'm on 13.5.4

[feedthejim]

So, there was a slight mix-up here: I misread @arackaf original message and I hadn't realised what I fixed was slightly different from what @arackaf was asking about.

To clarify: to show the loading state, Next.js will always need to make a pre-emptive prefetch request to the page that you want to navigate to. In the scenario in which you haven't made that request yet, yes, Next.js won't show a loading state until that prefetch resolves. However, the payload that contains the loading state is most often static so this would only be a round trip to the CDN, 32ms for me locally, and so you wouldn't see this happen in the wild often I think, unless the user clicks on a link really quickly.

As the loading states are defined at the layout level, the sole alternative to that would be for Next.js to bundle all loading states into every page or for Next.js to be able to scan every links on a page to pre-emptively attach the loading states for it.

[jvandenaardweg]

However, the payload that contains the loading state is most often static so this would only be a round trip to the CDN, 32ms for me locally, and so you wouldn't see this happen in the wild often I think, unless the user clicks on a link really quickly.

It depends on your connection. Slow connections makes the whole app feel sluggish and not instant on route changes due to that extra roundtrip. Even on fast connections you'll notice a delay. Its missing instant feedback something is loading.

I'm currently in the process of switching over to the App directory, coming from the pages directory. And altough I see the benefits the new App dir offers, this issue is what really makes me consider moving everything back. Because the overall UX just feels slower 😞

The slowness comes down to this extra fetch that needs to resolve before routing to a different page.

As the loading states are defined at the layout level, the sole alternative to that would be for Next.js to bundle all loading states into every page or for Next.js to be able to scan every links on a page to pre-emptively attach the loading states for it.

I don't know enough about the NextJS and React internals of this. But it seems like the only logical fix is to have that in the client bundle in order for it to be instant.

edit: can you re-open this issue?

[murilo1008]

@jvandenaardweg Pleasee!

I really need to solve this problem in my project. Iam using app folder and the navigation isnt immediately.

If someone solved this problem please tell us.

[l-you]

@murilo1008 We have decided not to use RSC at all. Additionally, we have been using NextJS version 13.4.19 for the past two months, as it provides the best navigation speed for us.

Please note that our generateMetadata function contains fetch queries, which are cached.generateMetadata currently blocks NextJs navigation, and its execution speed adds overhead to route transition time. I would recommend avoiding any queries in generateMetadata until the 'app router' becomes stable enough.

Yes, SEO will hurt, but UX is more important.

[arackaf]

I’m still a fan of app directory, but honestly the “instant” loading feature feels misnamed, and I’m more or less convinced it shouldn’t be used at all if it’s not actually instant.

CDN request or not it cannot ever be considered “instant” if a network request is required in order to load and show it.

I’d love to just see these loading states be automatically included in all client bundles, with devs being responsible for understanding that bundles can grow if they build too many of them, with too much content.

[arackaf]

As an alternative, if Vercel absolutely, does not want to include all loading components in client bundles, can I suggest Vercel add an ability to do something like

export const include = true

to a loading file to force it to be included in client bundles, to enable them to be actually instant?

[unleashit]

But it seems like the only logical fix is to have that in the client bundle in order for it to be instant.

Yes and

but honestly the “instant” loading feature feels misnamed, and I’m more or less convinced it shouldn’t be used at all if it’s not actually instant.

Both of these are the bottom line, and what I (and some others) tried to argue months ago.

export const include = true

This would be the opt-out method, which be a big improvement since it would fix more than this issue and give the dev a choice on how they want to balance performance (faster initial load vs faster transitions without relying on prefetch). Personally I prefer the (traditional) opt-in approach to code splitting, which is really as simple as a dynamic import per component (or page) you want to code split/lazy load.

[jvandenaardweg]

Why would you want this to be configurable? Loading states should be instant, not after a fetch to whatever server. Its just bad UX.

[feedthejim]

I wanted to clarify a bit: the fetch happens pre-emptively when the page loads, not when you navigate.

Can anybody send me a repro where their navigation is slow? I would love to investigate. Any datapoints would help us evaluate or not if we should change that part of the architecture.

[unleashit]

@jvandenaardweg Configurable in some way (either as opt-in or opt-out of bundling) I think is important. If you automatically bundle every possible fallback/loading.js in an initial load, it could get bloated in some cases. But in my comment above, I was thinking about the bigger picture of having more control over bundling in general.

I wanted to clarify a bit: the fetch happens pre-emptively when the page loads

@feedthejim I think you're referring to prefetching. Prefetching is unreliable because it can either be turned off or the user can click a link before the response(s) resolve.

[jvandenaardweg]

I wanted to clarify a bit: the fetch happens pre-emptively when the page loads, not when you navigate.

Can anybody send me a repro where their navigation is slow? I would love to investigate. Any datapoints would help us evaluate or not if we should change that part of the architecture.

It happens when you navigate, so clicking a link to a different page where that page is expected to show a loading indicator. So with a loading.tsx or a Suspense fallback. The above gif of @arackaf shows exactly what happens. He also has a reproduction repo.

To be more precise on where to look in that gif; its about the delay between the click and until the loading indicator is shown. Thát delay shouldn't be there.

[IGassmann]

@arackaf In your reproduction, it seems that you're running the app in development mode (next dev), and not in production mode (next build; next start). As per the docs, prefetching is disabled in development. If you run your app in production mode, the navigation is indeed instant after the prefetch has completed:

https://github.com/vercel/next.js/assets/4291707/de68db97-2d08-4b15-ac13-a3dc594dea15

In production, routes are automatically prefetched as they become visible in the user's viewport. Prefetching happens when the page first loads or when it comes into view through scrolling.

[IGassmann]

The fact that prefetching is not enabled in development is a common source of confusion on how this works. @feedthejim why is it disabled in development?

[unleashit]

So I guess people in the Next.js community feel that prefetching is a good solution. But a) it can be turned off in a Link and b) the user can act faster than the response comes in. This is in production. Lastly, it costs $ especially when serverless.

[feedthejim]

@unleashit I'm asking for a real repro where I don't have to simulate 3G conditions to notice a delay

@IGassmann we disable prefetching in dev because it would force the compilation of all the pages that you're linking to from your page. Please do note that if you do click a link in dev, we simulate the prefetching behaviour however by fetching the loading state first and then the rest.

[IGassmann]

@unleashit I'm asking for a real repro where I don't have to simulate 3G conditions to notice a delay

@feedthejim, this is a challenging request. Users may encounter poor internet connections, such as when using the app in the subway. For example, a user might load a page right before entering a tunnel and then, while in the tunnel, click a navigation link, which could result in no loading indicator. How do you provide a reproduction for this situation?

[unleashit]

@feedthejim sorry, I don't have time at the moment. I do have a non-minimal statically exported repo I could show you that never shows the loaders: https://github.com/unleashit/portfolio-v4/tree/master/app/portfolio. They were actually working at some point during the early app directory development, but the behavior changed several times and now nothing.

I think most people here are talking about SSR, where the loader can sometimes be delayed like in @arackaf s demo. Again, I used to get this behavior during the 13 beta for my static site, but now nothing. But I've also seen it in SSR sites.... just don't have any at hand to post. You'll need to throttle it though to see, unless you want to take your laptop maybe a block from the house/office until the connection is bad ;)

[jvandenaardweg]

The issue also happens in production environments. The same RSC background fetch/prefetch call delays rendering of a loading indicator.

In production, routes are automatically prefetched as they become visible in the user's viewport. Prefetching happens when the page first loads or when it comes into view through scrolling.

I see the prefetching happen for the pages that are linked to. But the same fetch happens when a user clicks the link to that page.

1. Hard refresh the current page you are in
2. You'll notice the prefetching happening.
3. On the current page, click a link to a different page, let's say it links to /page/whatever
4. When clicked, a fetch happens in the background to /page/whatever?_rsc=17rda. It's the same fetch that already happened on page load.

Now, nothing happens on the screen until that fetch resolves. Not even a loading indicator. Nothing. And this is exactly the point we try to make by throttling your connection. Not everyone has sub 50ms connections to the server at all times to get a server respond if we should even show a loading indicator...

5. When it resolved, the loading indicator of the page is shown
6. After the RSC is done fetching some external/database data, the component is show

I tried making a demo video of the issue. But it's giving too much away of my environment, including url's that I don't want to be publicly available. But it's the same issue as posted in the GIF a few days ago in this thread.

So I guess people in the Next.js community feel that prefetching is a good solution. But a) it can be turned off in a Link and b) the user can act faster than the response comes in. This is in production. Lastly, it costs $ especially when serverless.

Also, this is worrysome yes. I already see a huge increase in calls that count up to my usage in Vercel, just by using the App Router.

[jvandenaardweg]

I checked @arackaf 's repo and environment. This shows the same issue i'm also seeing:

Demo: https://next-instant-loading.vercel.app/ Repo: https://github.com/arackaf/next-instant-loading/tree/feature/instant-loading

[IGassmann]

@jvandenaardweg something is weird; I'm able to reproduce the issue on the app deployed on Vercel (next-instant-loading.vercel.app), but not when it's running locally in production mode (arackaf/next-instant-loading@feature/instant-loading)

On Vercel https://github.com/vercel/next.js/assets/4291707/1fcc9092-352e-4db1-aaed-9f64e1713cff

Locally https://github.com/vercel/next.js/assets/4291707/68c7f5bd-12ca-4bbb-a67a-d9cd1f2ed9ba

Edit: The app on Vercel is actually still pointing to an old commit (https://github.com/arackaf/next-instant-loading/commit/f7de8a25a25e12852e63d3f62c8b484c37572854), which still uses Next.js 13.5.2. That explains the discrepancy.

[jvandenaardweg]

Edit: The app on Vercel is actually still pointing to an old commit (https://github.com/arackaf/next-instant-loading/commit/f7de8a25a25e12852e63d3f62c8b484c37572854), which still uses Next.js 13.5.2. That explains the discrepancy.

You sure @IGassmann ? The Preview environment on GitHub shows a succesful deploy of "Update Next" as the last succeeded deployment: https://github.com/arackaf/next-instant-loading/deployments/Preview , which points to 13.5.4: https://github.com/arackaf/next-instant-loading/commit/2c90fcad26ae81fc5a387b7a54a218a5509263b5

"Update Next" is the last commit on the feature/instant-loading branch he was pointing to: https://github.com/arackaf/next-instant-loading/tree/feature/instant-loading

[IGassmann]

@jvandenaardweg that successful deployment in the Preview environment is hosted at https://next-instant-loading-o7zx8tsok-adam-rackis.vercel.app/, not at https://next-instant-loading.vercel.app/

On that deployment, we can see the issue fixed:

https://github.com/vercel/next.js/assets/4291707/5c75599b-b9c0-49bc-8a58-9eeb409e46c7

[arackaf]

Hey all - sorry, yeah the original prod repro may not be on the latest commit. I’ll take a look later and update.

I’m glad to hear it’s instant with a prefetch, but I would still feel much much much better if it was just included in the JS bundles for a number of reasons articulated above by others.

Instant loading state should not depend on a prefetch.

[jvandenaardweg]

Thanks for clearing that up @IGassmann ! I'll have to take another look at my code then. Because i'm on the same latest Next version but dó see the delay. I'm just totally lost now what's causing it.

[jvandenaardweg]

I guess my issue lies in the use of <Suspense> on a page to have fine grained control over what component is loading, instead of a page wide loading indicator.

Using Vercel's app router demo to demonstrate:

No issue here when using a generic loading.tsx file: https://app-router.vercel.app/loading

But the issue is here "Streaming with Suspense": https://app-router.vercel.app/streaming

When you throttle the connection, using loading.tsx instantly shows a indicator. Which is good. But using the same throttled connection on the Streaming With Suspense demo prevents anything from being shown until a certain point. Not really clear when that exactly is.

Both also tested with the latest NextJS version locally and with a deploy on Vercel.

So the issue lies in the use of <Suspense> with a fallback on a page.tsx. When I switch over to using the loading.tsx the issue dissapears in my project. But that's not what I hoped, I really want to use the Suspense fallback on a per component basis and not have a loading.tsx on the page level.

edit: issue about this: https://github.com/vercel/next.js/issues/54667

[arackaf]

Ok I've updated my original repro with the latest Next version, and the instant loading state does show instantly, given the prefetch.

I do still think loading into client bundles would be better, but it does look like this is essentially fixed and working as designed.

https://next-instant-loading.vercel.app/no-suspense