Dev server performance issues with [email protected] in Vite – eager loading of all routes

[bk-mja]

Hi everyone,

I'm running into a performance bottleneck during development with [email protected] (framework mode) and [email protected]. Every time we restart the dev server, it's painfully slow—Vite appears to be transforming every single file in our /app directory on startup.

After digging in with Vite debug flags and vite-plugin-inspect, I found the cause: the virtual:react-router/server-build module is importing all routes eagerly. In our app, that's over 300 routes, each importing many components, so this adds significant overhead.

My understanding was that Vite transforms files on-demand during dev, not all at once. But in this case, due to the way routes are imported, it looks like everything is being pulled in up front on server start. That seems to defeat the purpose of Vite’s fast dev experience.

My questions:

Is there a way to make route imports on the server lazy, to avoid eagerly loading everything at dev startup?

Are there known patterns or workarounds for optimizing this in a large app using React Router’s framework mode?

Or is my understanding of how Vite dev server works in this context flawed?

Environment:

[email protected] (framework mode)

[email protected]

Custom Node server

~300 routes, each importing multiple components. Configured in the routes.ts file as per the framerwork docs

I'm happy to share more details about our setup if helpful.

Thanks in advance!

[pcattori]

Great question @bk-mja !

We definitely strive for a near-zero startup time. Unfortunately, a core part of what React Router does is the routing part and that relies on having knowledge of all routes. Otherwise we wouldn't what route would match a particular URL.

We did ship a way for the client to lazily discover routes in Remix and React Router ("lazy route discovery" or "fog of war").
However, the server (whose entrypoint is virtual:react-router/server-build) still needs full knowledge of the routes.

That said, we haven't tried to optimize how the server build gets all of those routes. We can definitely look into that.

Also, we have some prototypes of what RSC in React Router might look like and are hopeful that RSC can provide a way to actually solve this problem once and for all (i.e. making server-side route access truly lazy/on-demand). So stay tuned for that!

---

Every time we restart the dev server, it's painfully slow—Vite appears to be transforming every single file in our /app directory on startup.

Out of curiosity, could you share some additional stats?

• number of files = ~300
• number of routes = ?
• rough average time it takes for dev server to startup = ?

Ideally, if you had a reproduction you could share that would be immensely helpful so we can test it out on different machines to account for speed differences in hardware.

[bk-tho]

Thanks for looking into this! bk-mja is my colleague, so I can provide this info as well :)

• number of files = ~2000 + dependencies
• number of routes = ~300
• rough average time it takes for dev server to startup = ~1min
  • ~15s until it logs that it's ready and listening on port 3000
  • ~40s until the app is interactive on top of that after visiting http://localhost:3000 for the first time
  • this gets significantly worse when there are changes in package-lock.json because vite needs to optimize deps again. When switching between branches, this does happen every now and then. RR probably can't do anything in this regard of course.

This is on a 2023 MacBook Pro, M3 Pro, 18GB RAM. My colleagues all have Dell Windows machines which typically perform noticeably worse.

That said, we haven't tried to optimize how the server build gets all of those routes. We can definitely look into that.

If there's anything that can be optimized, we'd really appreciate it!

Regardless of this, we're also excited for vite-rolldown full bundle mode in dev, to say the least. Hopefully this will provide a better baseline performance.

Ideally, if you had a reproduction you could share that would be immensely helpful so we can test it out on different machines to account for speed differences in hardware.

Unfortunately this is closed source and we cannot publicly share it.

---

We did ship a way for the client to lazily discover routes in Remix and React Router ("lazy route discovery" or "fog of war").

This is a bit off topic but since you mentioned "lazy route discovery", a note on this: We only just upgraded from Remix 2 to React Router 7 ~1 week ago and this feature broke production for a couple of our users. We were able to deploy a quick fix by adding discover="none" to a couple of our <Link />s. We've noticed that others ran into this problem as well (cf. #12656) and that in the upcoming release, there will be an option to opt out of this feature (cf. #13451). That's cool and we will be using this opt-out. However, it's our understanding that this will result in a deoptimization. One person in the original issue proposed to provide an option to opt into Remix's former behavior:

We also have very few routes (but a lot of links with different params), so the strategy in the old Remix where it would get manifest of all routes in one request at startup would be much better for performance (and number of request to the server).

I believe that for us, this would be the case as well. Or, alternatively, there might be a smarter implementation, I'm not sure. Since an RSC "server" can run at build time, this might prove as a helpful mechanism for lazy route discovery on the client as well. Haven't thought about this a lot, just spitballing here.

Just to give a real-life example of how the current lazy-route discovery implementation plays out for one of our routes: Our software features a scheduling view where you can assign jobs to service engineers (see image below). Those jobs are rendered as tiles. Each tile renders a couple of links (hidden in context menus, popovers, or, as seen here, appearing on hover). All of those links all lead to the same couple of routes which all have dynamic segments. The manifest is requested for all of those links though. There can be many service engineers. Each one can have many jobs which results in many links. This was highlighted by another person in the original issue:

We need more control over Fog of War. I noticed the same issue, we have a search results page where each result is a different link. React Router fetches a manifest for all the links, but it's just a single route with parameters.

Now, those links are sent as search params when requesting the manifest file. When there are many links, this exceeds the max allowed characters for URLs, which in our case simply crashes our app. Unfortunately we don't have HTTP QUERY yet I guess 🤷‍♂️ Of course it'd be even better if React Router was somehow smart enough to know that it does not need to fetch a mainfest again.

What makes things worse, in a way, is that we do not render all tiles at once. We implemented our own virtual vertical + horizontal scrolling so that we basically only render the tiles that are in our current viewport and nothing more. For lazy route discovery, this results in endless requests for route manifests on scroll 🫠. I'm not sure what a robust solution could look like but as for now, this is unusable for us.

Again, thanks for taking the time to look into this!

[pcattori]

Are you using the unstable_optimizeDeps future flag?

[bk-tho]

Not yet. I just turned it on. We'll monitor if this makes things better, thanks.

Shouldn't all of the flags be documented here? 😅
https://reactrouter.com/upgrading/future