Initial Render Delay with TanStack Router Compared to React Router

[vishal-tiwari]

I’m experiencing an initial delay in rendering routes along with the basic app layout when using TanStack Router, even though my application does not involve any data loading. In contrast, when I use React Router, the initial render is significantly faster.

Here are the steps I've already taken to optimize performance:

1. Ensured that my initial layout is simple and lightweight
2. Implemented lazy loading for non-essential components.

Any insights or recommendations would be greatly appreciated as I’d prefer to use TanStack Router for its advanced features, but the performance difference is currently a blocker.

[nuschk]

I have the same problem. I'm building a hybrid application, where some parts are rendered server side (django in my case), and some widgets are rendered client side (ex: Navbar). The navbar takes about half a second to display, even if all JS resources have been loaded already. There's nothing async going on in my part of the code.

There are also full-screen SPA pages, where the behaviour is ok.

[ViewableGravy]

I'm encountering the same issue. It's really bad in our companies app which has routes that are 8 layers deep and aren't trivial pages either. A full page rerender takes roughly 500ms so obviously this is noticeable, even as I've only converted less than half our app.

Note, this isn't just the first render, whenever you change route, all parent routes will rerender their components (defeating the purpose of the <Outlet />)

From what I can tell, none of the route components are getting Memoized which is the problem. So while this bug exists, a workaround is as follows

export const MyRoute = createRoute({ /* implementation */ })

const MyRouteComponent = () => {
  /* implementation */
}

const MyMemoizedRouteComponent =  React.memo(MyRouteComponent)

MyRoute.update({
  component: MyMemoizedRouteComponent 
})

I'm not as confident at the moment to implement a PR but I do have some time over the weekend so I'll take a look if I can make out how to fix this from tanstacks end, because this is pretty much the point of using an Outlet

[ProTip]

This workaround resolved the issue for me: #1929 (comment)

defaultPendingMinMs: 0

[ViewableGravy]

Just for reference, it looks like this issue has been happening at least since April - #1460.

I imagine it always functioned this way but hasn't had any real performance impact on smaller applications.

[jjmaturino]

@vishal-tiwari make sure you're using the <Link> component provided by tanstack-router, instead of the native <a> hyperlink html tag or any other routing html tag.

[vishal-tiwari]

I tried the snippet below, as many developers suggested removing the initial delay, but it didn’t work for me.

const router = createRouter({
    routeTree, defaultPendingMinMs: 0
})

[MGSimard]

This is especially noticeable in situations where you have a column-based flex layout with nav/header/main/footer. Generally you'd flex-grow the <main> so that footer is always at the bottom and main fills the app's 100dvh min height. I like my pages' root elements to be <main>, but due to Outlet's delayed rendering you get a flash of <main> not being there 100% of the time on site entry and refreshes while nav and footer are visible immediately since they're in __root.tsx layout.

This is forcing me to instead write <main><Outlet /></main> in my __root.tsx instead, which while not being that big of a deal, it's still weird that there's any arbitrary render delay to begin with, let alone when you're accessing what should be the core index landing page.

[ViewableGravy]

I've been using tanstack router a lot since my initial post, and have sort of worked out that there are two reasons that the router tends "delay" the render, which is a bit of a misnomer.

1. There is some loader that is running which needs to finish before the component can mount
2. The component is currently rendering

In the loader case, by default, the pendingMs represents how long your page is essentially frozen (during the loader running) before it shows your pending component for that route level. This is because swapping the current page with a loader is often more disruptive than a short delay in changing routes.

It's important to also note that react takes some time to run your component. All those hooks and createElements aren't free, so in the same way, if it takes 100ms for this code to run, your page is going to behave the same way as if your loader was running (a delay).

So with this in mind, and based on how it "feels" to use the code (since I have not read the source code for this), my assumption is that tanstack router runs the code for your route in the order of route components. This would mean if you have some layout code in your _root route, and then some main elements in your /whatever route, you may see a delay in these rendering, because your root might render instantly, or at least first, and then your /whatever route might take 50ms or 100ms to render, so you are getting content shifting because of your design.

I think when using react router, you probably don't notice this, since a lot of the time, you actually create your elements before passing them to react-router, instead of letting the router create them when needed. i.e. the difference between<MyComponent /> and () => <MyComponent /> and this is why it tends to work in those cases (since there is 0 js delay when it comes time to render, just a matter of putting it in the dom).

Anyway, This probably looks weird because you have an empty space in the middle of your page, unfortunately I'm not sure on the best fix for you in this case but just wanted to put out what I assume is happening in case this can help you find an appropriate way to move forward

[MGSimard]

Nah, this was happening with the most barebones setup. I actually went through TSR and RR to compare, and the TSR app had a ~500ms(?) mismatch between the __root.tsx layout render and <Outlet /> (index.tsx rendering <main>main</main>)

Turns out it's because pnpx create-tsrouter-app@latest my-app --template file-router setup sneakily defaults you to { autoCodeSplitting: true } in vite.config.js, which causes the render timing mismatch (forces it to lazy-load, + TSR has a default pending MS of 500ms, which explains it). Turning it off restores the perfect render timing between layout and its outlet.

[Meess]

TanStack/router has a 500ms pending delay on routes if you use a loader, to prevent layout shift i guess, I always remove it. did you try setting setting the following options on the root route:
pendingMs: 0

That solves most issues with the 500ms / slow initial load on a page

[MGSimard]

There's still going to be a render delay by default with { autoCodeSplitting: true }. I've talked with Tanner on twitter regarding this today. He said he's definitely thinking about making some adjustments here and there since the 500ms was an arbitrary choice he's coming to second-guess, said he might consider a more fluid/dynamic version of it where the 500ms only gets applied past a certain ms threshold.

You can see an example of the effect here: https://test-tsr.pages.dev/

For the record, setting defaultPendingMinMs={0} on the RouterProvider would still give you a ~250-300ms render delay in that very barebones presentation.

Regardless, I didn't end up needing the code splitting, so once I realized it was the culprit which got enabled automatically by the CLI setup I turned it off and got back to instant loads.

[schiller-manuel]

how did you measure the 250-300 ms?
When I measure like this: https://github.com/MGSimard/test-tsr/pull/1/files

I get ~13 ms between entry point and rendering the index route component.

this is not measuring the visual delay, just trying to understand your setup.

chrome performance tracing gives me 283 ms, so this is close to your number

with react 18, this does not happen:

turns out, react 19 adds an artificial delay of 300 ms!

there is a hacky workaround for that , which we will implement to fix this.

[ProTip]

When I made my comment last year I had to avoid lazy loading components(maybe code splitting period, I'd have to double check) and set defaultPendingMinMs={0}.

might consider a more fluid/dynamic version of it where the 500ms only gets applied past a certain ms threshold

I don't think these sort of decisions should be forced on projects. At a minimum there should be an escape hatch that works to opt out, as different projects are going to have wildly different takes on the best way to mitigate the issues it's meant to address..

[MGSimard]

how did you measure the 250-300 ms? [...] this is not measuring the visual delay, just trying to understand your setup. [...]

chrome performance tracing gives me 283 ms, so this is close to your number

[...] turns out, react 19 adds an artificial delay of 300 ms!

Yeah visual rendering, don't tell the HTMX guy React 19 causes this I can already see him spamming that one gif

there is a hacky workaround for that , which we will implement to fix this.

Leggo baby

[ryanstaniforth]

Issue created: #3880

[EliasGit117]

Having same issue, footer and header renders first, and it looks not really nice. As a solution I could use SSR but this will lead to more complexity

[nicognaW]

r u using file-based or config-based router? if you use file-based, try disabling the auto code splitting in vite

[EliasGit117]

@nicognaW yes, this helped, but I don't understand why

[nicognaW]

https://x.com/nicongdev/status/1905085878881661243 checkout this thread, i had the question too and Tanner answered me here, inspired me to figure out what happened, and also comments in this issue are helpful for understanding

[EliasGit117]

https://x.com/nicongdev/status/1905085878881661243 checkout this thread, i had the question too and Tanner answered me here, inspired me to figure out what happened, and also comments in this issue are helpful for understanding

Yeah, as a solution I found to place base layout under _app, so it would render together with the pages, otherwise you will have header, empty space and footer for 300 ms