-
Notifications
You must be signed in to change notification settings - Fork 29.1k
Description
Link to the code that reproduces this issue
https://github.com/dannytlake/next-14-link-prefetch-bug
To Reproduce
- Start the application in production mode,
pnpm build && pnpm start
- Navigate to http://localhost:3000 with Firefox Developer Edition.
- Open dev tools and go to the Network tab
- Reload the page, see the responses of each prefetch of each
<Link>
. The responses that are ~450 bytes in transfter size contain an invalid prefetch. The responses that are ~860 bytes contain the expected response with theloading.js
fallback. See the screenshot in the README for reference.
Current vs. Expected behavior
The current behavior of prefetching (using the default setting prefetch
of next/link
) dynamically rendered pages is not correctly returning the loading.js
fallback in the streamed response. This occurs for the majority of routing cases. There are some cases where it does function as expected, but only on top level route segments or a top level dynamic segment.
The expected behavior of prefetching (using the default setting prefetch
of next/link
) dynamically rendered pages is to include the loading.js
fallback of the prefetched route.
Provide environment information
Operating System:
Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 23.6.0: Mon Jul 29 21:14:30 PDT 2024; root:xnu-10063.141.2~1/RELEASE_ARM64_T6000
Available memory (MB): 32768
Available CPU cores: 10
Binaries:
Node: 20.16.0
npm: 10.8.2
Yarn: 1.22.22
pnpm: 8.15.9
Relevant Packages:
next: 14.2.13 // Latest available version is detected (14.2.13).
eslint-config-next: 14.2.7
react: 18.3.1
react-dom: 18.3.1
typescript: 5.5.4
Next.js Config:
output: N/A
Which area(s) are affected? (Select all that apply)
Navigation, Performance
Which stage(s) are affected? (Select all that apply)
next start (local), Vercel (Deployed)
Additional context
This bug is not present in next@canary. I am opening this issue to hopefully have the fix for this bug backported to v14, or at least be migrated to next@rc.
The possible fix for this prefetch bug was implemented via #67358