Default <Link /> behaviour (discover="render") causes performance issues in large lists

[richardscarrott]

Reproduction

https://stackblitz.com/edit/github-xjqtafn4-nkhw9euc?file=app%2Froutes%2Fhome.tsx

System Info

System:
    OS: macOS 15.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 204.08 MB / 32.00 GB
    Shell: 3.7.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 20.19.2 - ~/.nvm/versions/node/v20.19.2/bin/node
    npm: 10.8.2 - ~/.nvm/versions/node/v20.19.2/bin/npm
    pnpm: 10.11.0 - /opt/homebrew/bin/pnpm
    Watchman: 2025.05.26.00 - /opt/homebrew/bin/watchman
  Browsers:
    Chrome: 138.0.7204.169
    Edge: 138.0.3351.55
    Safari: 18.5
  npmPackages:
    @react-router/dev: ^7.7.0 => 7.7.0
    @react-router/node: ^7.7.0 => 7.7.0
    @react-router/serve: ^7.7.0 => 7.7.0
    react-router: ^7.7.0 => 7.7.0
    vite: ^6.3.3 => 6.3.5

Used Package Manager

npm

Expected Behavior

When rendering a large list (e.g. 1000+ items), each with a <Link /> pointing to a unique path, I expected performance during both initial and subsequent renders to be comparable to rendering plain elements (e.g. <span>) instead of links.

Actual Behavior

Rendering a large list where each <Link /> points to a unique path results in noticeable slowness during both initial and subsequent renders. Profiling suggests that the default discover="render" behaviour introduces non-trivial overhead per link. Switching to discover="none" significantly improves performance.

[brophdawg11]

This looks like it's a slowdown in sorting the paths on this line in the code in fetchAndApplyManifestPatches:

paths.sort().forEach((path) => url.searchParams.append("p", path));

We sort the paths so that manifest request search param strings are deterministic for better caching, but thos sorting looks to be overly expensive on very large lists.

A couple things we could do off the top of my head if anyone wants to take a stab at this:

• Set a limit on the # of paths that would allow us to short circuit prior to sorting
• When we find we have too many paths, instead of short circuiting, still perform the manifest request but only for the first N paths, leaving the rest paths for the next request
  • By fetching those paths we make sure they make it into discoveredPaths and are never considered again

[brophdawg11]

As noted in #14084 this is actually not an issue with sorting but a perf issue with URL.searchParams.append

[brophdawg11]

I added a comment on the linked chromium issue but past comments don't indicate much appetite for a fix so we'll move ahead with changing our approach

[brophdawg11]

#14084 is merged and will be available in the next release.

Thanks again for the PR @richardscarrott!

[github-actions]

🤖 Hello there,

We just published version 7.8.0-pre.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!

[github-actions]

🤖 Hello there,

We just published version 7.8.0 which involves this issue. If you'd like to take it for a test run please try it out and let us know what you think!

Thanks!