Does this happeb on local dev?

yes. but hard to reproduce. is there a way to turn off caching, and test?

@Mugger Crocodile In your case, are you sure the links aren't working? I'm having a similar issue, and in my case, links with <Link> on first load take over a minute to navigate, though directly accessing a route via the URL bar, or using a link with <a> instead, works in less than a second on the first time. In Firefox's debugger, my browser is just waiting for the server(I'm running on localhost.), no apparent logs in the server's debugging console(Visual Studio Code) while this is going on.
That may offer a potential workaround if you're having the same issue where it's more extreme delay than outright not working.

Yes. You seem to have the same issue I am having. Were you able to find the root cause?

Afraid not. I'm still learning Next and Node, so while I'm generally experienced, it's still a lot of foreign concepts and trying to beat understanding in my head while badgering ChatGPT and documentation for info. Still looking into it though.

In my case(and I'm doing a bunch of stuff beyond basics, working on a company intranet site):

<Link href={route.path}>{route.title}</Link> // Massively slow on first load (> 1 minute)
<Link prefetch={false} href={route.path}>{route.title}</Link> // Massively slow on first load (> 1 minute) (Mainly trying a shot in the dark with that.)
<a href={route.path}>{route.title}</a> // Fast on first load, other than compiling delay. (< 100ms)
All are quick and responsive on navigations after the first.

In my case, I've got a main dashboard page that's generating links dynamically from whatever routes exist, and using some json metadata in each route to specify security access controls for nextauth and ldap.js. (The general idea is to avoid maintenance issues down the road by multiple people with varying levels of ability by isolating as much as possible within its own route. There may be a better way to accomplish that, but for context.)

Using next 14.2.5 and the app router, for reference.

My only guess(am guessing you are fetching data inside server component if not feel free to not read) is since you are using app router, do you have a loading.tsx files for each route segment? If not, the navigation to that link will be blocked until all the contents of the page is ready to be served/loaded. Let's say you have 3 components on a page. The first component takes 5s to load(fetching data) and other two takes less time. If you are not using any loading.tsx or suspense, then the page will be visible to users only after 5s(slowest component) that's why it is so important to wrap server components that fetches data in a Suspense (if you haven't done) with a fallback so that the fallback will be shown while the data is fetched and it won't block the rendering of whole page because we have the fallback to show to the user while the data fetching is in process. The logic applies up to the route segment/page level. App router is very fast if you get all those correct but can be very slow on navigations if you get those wrong. All those things can be simulated locally as well by running the production server with yarn start, of course you need to simulate api calls that takes long time as well. While we are still at it have a visit here to see what I mean, https://next-app-gamma-lovat.vercel.app/features/parallel-routing. Each page(parallel route) takes different time to load(simulated by making each page async and fetching faked promise), the highest being 8s. I have added loading.tsx for each parallel route segment and hence I don't have to wait for 8s to view the other sections of the route/page. If not for loading file, then I would have to wait atleast 8s to view the entire page even if other pages/sections are ready for the user to see.