Proposal: Deduplicate import paths in mode: "initial" manifest

[kjanoudi]

Problem

When using routeDiscovery: { mode: "initial" }, the browser manifest (manifest-*.js) grows dramatically with route count because each route's imports array contains the full asset path strings. With ~1,000 routes sharing ~500
unique import paths, the same strings are repeated hundreds of times.

Our app (1,002 routes) produces a 5.9 MB raw manifest. The dedupe() in getReactRouterManifestBuildAssets deduplicates within a single route, but not across routes — so /assets/chunk-ABC-xyz123.js appears verbatim in every
route that depends on it.

Why not Fog of War?

We switched from mode: "lazy" to mode: "initial" because /__manifest requests were causing severe production issues:

• 20.9% of all production traffic was /__manifest requests
• p99 latency: 89.4s, max: 26+ minutes
• Pages with many <Link> elements triggered 40–58 concurrent manifest fetches, saturating browser connections and freezing the UI

mode: "initial" eliminated this entirely — one static, cacheable file instead of thousands of dynamic requests. But the file is large.

Proposed Solution

Deduplicate the repeated import path strings using a lookup table at manifest generation time. Instead of:

window.__reactRouterManifest={"entry":{"imports":["/assets/chunk-A.js","/assets/chunk-B.js"]},"routes":{"route-1":{"imports":["/assets/chunk-A.js","/assets/chunk-B.js","/assets/chunk-C.js"]},"route-2":{"imports":["/assets/chunk-A.js"
,"/assets/chunk-B.js","/assets/chunk-D.js"]}},...};

Emit:

(function(){
var _p=["/assets/chunk-A.js","/assets/chunk-B.js","/assets/chunk-C.js","/assets/chunk-D.js"];
var _m=JSON.parse('{"entry":{"imports":[]},"routes":{"route-1":{},"route-2":{}},…}');
var _ri=[[0,1,2],[0,1,3]];
var _ei=[0,1];
function _d(a){for(var r=[],i=0;i<a.length;i++)r.push(_p[a[i]]);return r}
_m.entry.imports=_d(_ei);
var _k=Object.keys(_m.routes);
for(var j=0;j<_k.length;j++){var v=_ri[j];if(v!==null)_m.routes[_k[j]].imports=_d(v)}
window.__reactRouterManifest=_m;
})()

The IIFE expands indices back to full paths before assigning to window.__reactRouterManifest, so the runtime contract is unchanged — React Router sees the exact same object it always would.

Why JSON.parse wrapping?

V8 parses JSON.parse('...') significantly faster than equivalent JS object literals for large data payloads (no AST construction needed). This is a well-known optimization for
data-heavy scripts.

Measured Results (1,002 routes, ~510 unique import paths)

Metric	Before	After	Improvement
Raw size	5.9 MB	2.0 MB	66.8% smaller
Gzip	294 KB	75 KB	74.4% smaller
Brotli	49 KB	39 KB	19.8% smaller

The raw size reduction is the most impactful metric — it directly reduces JS parse time on the client, which matters for low-end devices:

• Mid-range phones (Pixel 4a, Galaxy A53): ~600–1400ms parse → ~200–470ms
• Low-end phones (Moto G series): ~1–2.5s parse → ~350–850ms

Implementation Complexity

As a userland Vite plugin (post-processing the built file), this requires ~300 lines including JSON extraction, safety guards, and error handling. If done natively in @react-router/dev, it would be ~30 lines inside
generateReactRouterManifestsForBuild — just build the lookup table before JSON.stringify and emit the IIFE format. No file parsing, no key-ordering concerns, no SRI complications (hashes would be computed after optimization).

This would also benefit /__manifest responses in mode: "lazy" when many routes are returned in a single patch.

Workaround

We're currently using a Vite closeBundle plugin that post-processes the manifest file. Happy to share the full implementation if helpful — but a native solution would be simpler, safer, and benefit the entire ecosystem.

(cc @binchik)

[brophdawg11]

Pages with many elements triggered 40–58 concurrent manifest fetches, saturating browser connections and freezing the UI

Can you explain your setup a bit more so we can figure out what was causing this? Links rendered together should batch into the same manifest fetch. We have looked into and POC'd shrinking/compressing/deduping the full manifest before but those gains will always be a fraction of just not shipping the whole manifest.

[kjanoudi]

MutationObserver batching works. The issue on our end is the interaction between our specific setup and how the batched requests perform.

Our setup:

• ~1,000 routes total (we've been users of react router since v4 and it had leading wildcard paths working – enabling us to have "global" routes – routes that are accessible from a certain subtree – e.g. "*/global-route", to achieve that in v7 we have to do "/first-route/global-route", "/another-route/global-route")
• SSR on Cloudflare Workers
• The /collections page renders an unbounded (no pagination) list of collections fetched via TanStack Query
• Each collection item renders 2 s with unique dynamic IDs: /collections/{id}/manage and /collections/{id}/build/details
• Our custom Link component defaults to discover='render'
• A user with 20-27 collections = 46-58 unique pathnames to discover

What we observed:

The batching does collapse these into fewer requests, but we still saw significant issues:

1. Slow server-side resolution. A single batched /__manifest?paths=... request with 40-58 dynamic paths took 42s–2min on our Cloudflare Workers SSR endpoint. During that time the user is waiting for route discovery to complete before
   navigating.
2. Multiple batch cycles from async rendering. Collections load via TanStack Query (async), and we use a virtualized list (react-viewport-list, overscan=10) that renders items incrementally via requestAnimationFrame. This means links
   appear across multiple render cycles, and if gaps between DOM mutations exceed the 100ms debounce window, multiple batches fire.
3. Effect re-runs after each patch. After a successful fetchAndApplyManifestPatches → patchRoutes, the manifest/routeModules references change, which are in the useFogOFWarDiscovery useEffect deps. The effect re-runs and calls
   fetchPatches() immediately (non-debounced), potentially triggering another batch before the DOM has stabilized.
4. Navigation-triggered fetches on top. patchRoutesOnNavigation fires an unbatched, undebounced single-path fetch per navigation. Clicking into a collection and back adds 2 more requests each time.

Net result across all users: /__manifest accounted for 20.9% of all production traffic (171K requests in 17 hours), with p99 latency of 89.4s.

Why we switched to mode: 'initial':

Fog of War was causing worse UX than shipping the full manifest. The repeated slow /__manifest requests were freezing navigation. Users couldn't click into collections without multi-second delays. mode: 'initial' replaced all of
that with one static, cacheable file.

The manifest dedup proposal is about reducing the cost of that tradeoff — we accept that shipping the full manifest is more bytes than lazy discovery, but we'd like that cost to be as small as possible. The 5.9MB → 2.0MB raw
reduction (and 294KB → 75KB gzip) helps parse time on low-end devices.

[rossipedia]

A single batched /__manifest?paths=... request with 40-58 dynamic paths took 42s–2min on our Cloudflare Workers SSR endpoint.

This is what grabbed my attention. Given the size of your application, and the size of your manifest, it feels like you may be running into cold start issues (or similar, I'm not super familiar with CF workers) here, because the /__manifest route doesn't do much tbh¹, but it does assume that the entire server-side manifest is available, and if the worker has to load up the server build every time, that could slow things down considerably.

¹: Ok scratch that, I'm digging more into handleManifestRequest and there might be unexpected algorithmic time complexity in there. Still digging.

[brophdawg11]

I agree that sounds excessive - is there any way you could do some profiling of one of the larger calls on the server? I'm not sure how it would be possible for a /__manifest request to take >= 1 second per path.

[kjanoudi]

The __manifest route isn't as urgent anymore for us as we've solved the issue by reducing the number of routes and utilizing the import deduplication plugin. We've seen a much better user experience this way, but if we do switch back to lazy loading the manifest i will add profiling around it.

This proposal is mostly centered around optimizing the mode: initial payload. If there's openness to the approach, we can submit a PR for the suggested generateReactRouterManifestsForBuild modification?

[brophdawg11]

Since this is no longer a pressing issue for you I think we should hold off on a PR. Our RFC process relies on community upvotes, so I think we need to see more community members express interest in something like this (and/or run into issues with mode:initial) before we move this along the governance process.