App Router in Next v14.1.0 slower than v13.4.6

[amavisse]

Link to the code that reproduces this issue

https://github.com/amavisse/next14-test

To Reproduce

I reproduced the issue here:
https://next13-test-teal.vercel.app/ - repo: https://github.com/amavisse/next13-test
https://next14-test-delta.vercel.app/ - repo: https://github.com/amavisse/next14-test

1. Visit both links
2. Click on any of the top links to change route and notice the difference in loading page

Current vs. Expected behavior

Current: page loading is very slow on next v14.1.0

Expected: fast loading as in https://next13-test-teal.vercel.app/

Provide environment information

Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Home
Binaries:
  Node: 20.2.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant packages:
  next: 13.4.6
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3

-------------------------------------
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 10 Home  
Binaries:
  Node: 20.2.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.1.0
  eslint-config-next: 14.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

App Router, Routing (next/router, next/navigation, next/link)

Which stage(s) are affected? (Select all that apply)

next dev (local), Vercel (Deployed)

Additional context

In the next v13.4.6, everything is going smoothly, while the v14.1.0 one is very slow when changing routes
Inspecting the dev console, inside the network tab, you can see the routes are correctly pre-fetched but when moving to the route, it's fetching it again, making it extremely slower.

Am I doing something wrong? bad practices? is it a bug?

[OlegLustenko]

Could be related #61203

[repcolding]

14.1.0

2024-01-29.15.04.38.mp4

---

14.0.3.canarey-7:

2024-01-29.15.03.44.mp4

---

A bug with caching routes, when hovering over next/link, the route is loaded again. Slow 3g is selected in the video, but even with fast Internet, the behavior is exactly the same.

Prefetch also does not load css.

It took a lot of time to figure out what the problem was.

The biggest mistake is to believe that the new versions are stable.

[Yhozen]

Related to #48748 and I believe it it related to optimizePackageImports not working properly (I'm compiling 10k+ modules per route aprox)

[ztanner]

Hi @amavisse -- thanks for raising this issue. Referencing the Prefetching Docs here, it seems like this is working as intended (in the latest version) and was actually a bug in the older version.

Specifically, note the following section of docs:

The Link's prefetching behavior is different for static and dynamic routes:
Static Routes: prefetch defaults to true. The entire route is prefetched and cached.
Dynamic Routes: prefetch default to automatic. Only the shared layout, down the rendered "tree" of components until the first loading.js file, is prefetched and cached for 30s. This reduces the cost of fetching an entire dynamic route, and it means you can show an instant loading state for better visual feedback to users.

In other words, if the prefetch argument to the Link tag is left unspecified, it will default to a partial prefetch (essentially up to the nearest loading boundary, if there is one). This is happening in your case, because each [...slug] page is considered a dynamic route.

Fortunately there's a way to opt-in to the behavior you're describing: if you pass prefetch={true} to your Link components, it will tell the router to perform a full prefetch of each of the pages (including the dynamic page data), and will instantly navigate without triggering a follow-up fetch.

In other words, update your Navigation component to look like this:

function Navigation() {
  const links = [
    { href: '/', name: 'Home' },
    { href: '/page1', name: 'Page1' },
    { href: '/page2', name: 'Page2' },
    { href: '/page3', name: 'Page3' },
  ]
  return (
    <nav className="flex flex-row justify-center gap-5 py-20">
      {links.map((link, i) => (
        <Link
          className="hover:underline"
          key={link.name + i}
          href={link.href}
          prefetch={true} // note the prefetch prop here
        >
          {link.name}
        </Link>
      ))}
    </nav>
  )
}

I'm going to close this as it seems to be working as designed, but if you have any questions about it, please don't hesitate to reply to this or raise in our Discussions forum.

[repcolding]

@ztanner Hi, if everything works as it should, that's suck

I checked the version next@14.1.0 and 14.0.3-canary.7. Specifying prefetch={true}. And the result is terrible:

next@14.1.0: No preloading of css
next@14.0.3-canary.7: css is preloaded

const Folder: FC<IFolder> = ({ children, label, className, href = '#' }) => {
  return (
    <Link
      prefetch={true} // next@14.1.0 and next@14.0.3-canary.7
      scroll={false}
      href={href}
      className={cn(styles.folder, className)}
    >
      {children}

      <div className={styles.label}>{label}</div>
    </Link>
  )
}

next@14.0.3-canary.7

prefetch={true} preload css is working

---

next@14.1.0

prefetch={true} preload css doesn't working

[ztanner]

Hi @repcolding -- I didn't state that everything is working as expected, just that prefetching semantics in the version you mentioned were not the intended behavior. If there's a separate bug with CSS loading, we can look into that.

[jinowac]

I am facing the same issue , Next js 14 version Link component is terribly slow , navigating between pages takes hell out of you . @ztanner Please make sure higher versions are stable .

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.